Cómo Probar un Adaptador Verifactu: Guía Definitiva de Demos, Sandbox y Simuladores
Integrar una nueva tecnología fiscal en el corazón de tu empresa siempre genera vértigo. El miedo a «romper algo» en tu facturación, interrumpir el servicio a tus clientes o, peor aún, enviar datos incorrectos a Hacienda y recibir una notificación de sanción, es completamente real y justificado. Por eso, la búsqueda de cómo probar adaptador verifactu es el paso más inteligente que puedes dar antes de comprometer tu presupuesto o firmar un contrato de permanencia.
Afortunadamente, el ecosistema Verifactu no es un salto al vacío. Tanto la Agencia Tributaria (a través de su área de desarrolladores) como las empresas de software privado han habilitado mecanismos seguros para simular el cumplimiento de la ley sin consecuencias legales reales. En esta guía técnica y práctica, te explicamos cómo acceder a estos entornos seguros, qué herramientas usar y qué checklist debes completar para dormir tranquilo antes de la fecha límite.
1. ¿Es posible probar la conexión con Hacienda sin riesgo?
La respuesta es un rotundo SÍ. De hecho, es un requisito técnico indispensable. La Agencia Tributaria dispone de un entorno de pruebas específico (Portal de Pruebas) que replica la funcionalidad de la sede electrónica real, pero donde los datos enviados no tienen efectos tributarios. Esto significa que puedes enviar facturas con importes ficticios, anularlas, provocar errores a propósito y rectificarlas tantas veces como necesites para asegurar que tu adaptador Verifactu funciona correctamente.
Si estás evaluando comprar una solución de terceros, lo normal es que el proveedor ya haya realizado estas pruebas de estrés contra los servidores de la AEAT y te ofrezca a ti una «Demo de Usuario». En esta demo, puedes ver la interfaz, comprobar la agilidad del sistema y verificar la generación del QR sin preocuparte por lo que ocurre en el «backend». Sin embargo, si estás desarrollando tu propia solución o integrando una API, el acceso al entorno de pruebas es crítico.
Para entender mejor el marco legal que permite y regula estas pruebas, puedes consultar la documentación técnica oficial en la Web de Desarrolladores de la AEAT.
🔧 Guía Esencial: Entiende la Tecnología Detrás
Para probar correctamente, primero debes entender cómo funciona el flujo de datos JSON/XML que viaja entre tu sistema y Hacienda. Si tienes un perfil técnico o desarrollas tu propio software, esta guía es tu mapa de ruta.
2. Los 3 Niveles de Pruebas para Verifactu
Dependiendo de tu perfil (usuario final vs. desarrollador) y de la fase en la que te encuentres, existen tres formas distintas de validar el sistema antes de gastar dinero.
2.1. El Entorno Sandbox (Caja de Arena) para Desarrolladores
Es un entorno aislado proporcionado por el proveedor de la API o por la propia AEAT. Es el «patio de recreo» donde se rompen cosas para que no se rompan en producción.
- Para quién es: Desarrolladores, CTOS e integradores de sistemas ERP.
- Qué permite: Enviar peticiones HTTP reales, recibir respuestas de «Aceptado» o «Rechazado con errores», validar la firma electrónica y simular caídas del servicio.
- Coste: Generalmente gratuito al registrarse como desarrollador en la plataforma del proveedor.
- Recurso Oficial: Puedes ver las especificaciones de envío en el BOE (Orden Ministerial de Verifactu).
2.2. Demos Comerciales y Trials para Usuarios
Son versiones del software final con funcionalidades limitadas por tiempo (ej: 14 días) o volumen (ej: 10 facturas). Son vitales para verificar la usabilidad.
- Para quién es: Dueños de negocios, autónomos y gerentes que quieren ver si el software es fácil de usar.
- Qué permite: Ver cómo se imprime el QR en el ticket, cómo se anula una factura, la velocidad del TPV y la facilidad de uso del panel de control.
- Dónde conseguirlas: Revisa nuestra comparativa sobre dónde comprar y descargar adaptadores para ver qué proveedores ofrecen demos activas.
2.3. Validadores de Sintaxis XML y QR
Son herramientas técnicas que analizan el fichero XML o la cadena del QR que genera tu software para asegurar que cumple con el esquema XSD publicado.
- Importancia: Un solo carácter mal colocado en el XML o un error en la codificación del QR provocará un rechazo inmediato por parte de Hacienda o que el cliente no pueda verificar su factura. Estas herramientas previenen ese fallo antes de intentar el envío.
🆓 ¿Buscas probar sin gastar un euro?
No siempre es necesario pagar una licencia cara para empezar a testear. Existen opciones en el mercado con planes gratuitos o periodos de prueba generosos que te permiten validar la tecnología.
👉 Descubre qué adaptadores gratuitos puedes probar hoy mismo
3. Guía Paso a Paso: Cómo ejecutar tu primera prueba técnica
Si vas a probar un adaptador Verifactu a nivel de integración (API), sigue este protocolo riguroso para garantizar el éxito y no contaminar tus datos reales:
- Obtén Credenciales de Sandbox: Regístrate en la web del proveedor del adaptador. Te facilitarán una API Key de pruebas que no tiene validez legal.
- Configura el Endpoint de Pruebas: Asegúrate de que tu software apunta a la URL de «Staging» o «Sandbox» y NO a la de Producción. Un error aquí podría enviar datos falsos a la AEAT real, lo cual es un problema serio.
- Prepara tu Certificado de Pruebas: Si pruebas directamente contra la AEAT, necesitarás un certificado de prueba. Si usas un adaptador, ellos suelen gestionar esto.
- Genera una Factura de Prueba: Crea una factura con datos ficticios pero formatos válidos (NIFs reales de prueba, importes coherentes, desglose de IVA correcto).
- Verifica la Respuesta: El adaptador debe devolverte un código de estado `200 OK`, un CSV (Código Seguro de Verificación simulado) y la cadena de texto del código QR.
- Simula un Error Controlado: Intenta enviar una factura con un NIF incorrecto o una fecha incoherente. El sistema debe devolver un error `400 Bad Request` explicativo. Si el sistema «traga» el error, el adaptador no es seguro.
4. Checklist de Verificación: ¿Qué debes validar exactamente?
No basta con que el software «funcione» y no de error. Para cumplir con la Ley Antifraude y pasar una posible auditoría, debes verificar durante la prueba que el adaptador cumple con los principios de integridad. Usa esta lista de verificación:
- ✅ Encadenamiento de Hashes: Emite la factura A y luego la B. Verifica en el log que el registro de la factura B contiene la huella digital (hash) de la factura A.
- ✅ Inalterabilidad: Intenta modificar la factura A después de haber emitido la B. El sistema debe prohibirlo o generar automáticamente un registro de evento de modificación. Si te deja editar sin dejar rastro, ese software es ilegal.
- ✅ Generación de QR: Escanea el QR generado con tu móvil. Debe llevarte a una URL de la AEAT (o del entorno de validación del proveedor) que muestre los datos de la factura.
- ✅ Gestión de Desconexión (Resiliencia): Desconecta internet y emite una factura. El sistema debe permitirlo, guardar el registro cifrado y encolar el envío para cuando vuelva la red.
5. Errores Comunes al Testear Adaptadores (y cómo evitarlos)
Incluso en fase de pruebas, es fácil cometer fallos que nos dan falsos positivos o negativos. Evita estos tropiezos habituales:
- Usar Certificados Digitales Caducados: El error más común en pruebas técnicas. Asegúrate de que el certificado usado para firmar es válido.
- Confundir Entornos: Mezclar datos de producción con pruebas. Limpia siempre la base de datos de pruebas antes de pasar a real para no romper la cadena de hashes inicial.
- Ignorar los «Warnings»: A veces la AEAT acepta una factura pero devuelve «Aceptada con errores» (ej: NIF no censado). En pruebas, debes tratar estos avisos como errores críticos a corregir, ya que en producción podrían causar problemas con tus clientes.
- No probar facturas rectificativas: El 90% de los errores ocurren al intentar anular una factura. Asegúrate de probar el flujo de abonos y rectificaciones.
⚠️ Advertencia: El coste de no probar bien
Implementar un adaptador sin haberlo testeado a fondo puede llevarte a enviar datos corruptos a Hacienda, lo que se considera una infracción tributaria grave. Las multas por software no conforme son devastadoras.
👉 Conoce las Sanciones de hasta 50.000€ que evitas al realizar pruebas correctas
6. Preguntas Frecuentes (FAQs)
1. ¿Cuánto tiempo tengo para probar un adaptador antes de la fecha límite?
La obligatoriedad comienza el 1 de julio de 2025 para desarrolladores y 2026 para usuarios. Te recomendamos empezar las pruebas al menos 3 meses antes de tu fecha límite para tener margen de maniobra si necesitas cambiar de proveedor o ajustar tu ERP.
2. ¿Necesito un certificado digital real para probar?
Para el entorno de pruebas oficial de la AEAT, a menudo se requieren certificados de prueba específicos. Sin embargo, muchos proveedores de API te permiten probar en su sandbox sin necesidad de aportar tu propio certificado inicialmente.
3. ¿Puedo usar datos reales de mis clientes en las pruebas?
No se recomienda por motivos de RGPD y seguridad. Utiliza datos anonimizados o ficticios. La estructura del NIF debe ser válida sintácticamente, pero no debe corresponder a una persona real sin su consentimiento.
4. ¿Qué pasa si durante las pruebas descubro que mi software no es compatible?
Es el mejor momento para saberlo. Tendrás que valorar contratar un «adaptador externo» que se conecte a tu base de datos o considerar cambiar de ERP. Revisa nuestra lista de mejores adaptadores del mercado.
5. ¿Las pruebas tienen algún coste?
El acceso al entorno de pruebas de la AEAT es gratuito. Los proveedores privados suelen ofrecer planes «Free Tier» o periodos de prueba (Trial) gratuitos para que verifiques la integración antes de pagar la licencia.
6. ¿Cómo sé si el QR generado en la prueba es válido?
Debes poder escanearlo con una app de lectura de QR estándar. El contenido debe ser una URL que apunte a la sede de la AEAT (o al entorno de validación del proveedor) con los parámetros de la factura codificados.
7. ¿Puedo borrar las facturas de prueba?
En tu base de datos de pruebas, sí. Pero recuerda que el objetivo de Verifactu es impedir el borrado en producción. Aprovecha para probar cómo funciona la anulación mediante factura rectificativa, que es el procedimiento legal correcto.
8. ¿El entorno de pruebas simula la respuesta de Hacienda en tiempo real?
Sí, los entornos Sandbox de calidad devuelven las mismas respuestas (XML de respuesta, códigos de error, CSV) que el sistema real, permitiéndote programar la lógica de tu software ante cada escenario.
9. ¿Qué es Postman y por qué lo mencionan para probar?
Postman es una herramienta técnica para desarrolladores que permite enviar peticiones manuales a una API. Es excelente para probar la conexión con el adaptador de forma aislada antes de integrarlo en el código de tu programa.
10. ¿Necesito estar dado de alta en el censo para hacer pruebas?
Para el entorno de producción sí. Para el entorno de pruebas de proveedores privados, normalmente solo necesitas registrarte con un email. Para el entorno de pruebas de la AEAT, necesitas un certificado reconocido.
11. ¿Existe un validador oficial de la AEAT?
Sí, la Agencia Tributaria proporciona servicios de validación de documentos XML para comprobar que la estructura es correcta antes del envío.
12. ¿Qué diferencia hay entre Sandbox y Producción?
En Sandbox, los datos no tienen validez legal ni fiscal, y puedes cometer errores sin miedo a multas. En Producción, cada envío es un registro oficial vinculante ante Hacienda.
13. ¿Puedo probar la anulación de facturas?
Sí, y es vital. Debes probar el flujo de «baja» o anulación mediante rectificativa para asegurarte de que tu software maneja correctamente el encadenamiento en estos casos.
14. ¿Las demos incluyen soporte técnico?
Depende del proveedor. Muchos ofrecen soporte básico durante el periodo de prueba para ayudarte con la integración inicial y asegurar que te conviertas en cliente.
15. ¿Si la prueba sale bien, qué hago después?
Una vez validada la integración, debes cambiar las credenciales de Sandbox por las de Producción (API Key real), limpiar los datos de prueba y comenzar a emitir facturas reales. Asegúrate de tener el contrato firmado con el proveedor.
