01
Mapa de emisión
Series, numeración, rectificativas, anulaciones, reintentos, multiempresa y puntos donde hoy se crean o modifican datos fiscales.
Integración VERI*FACTU para software de facturación
Diseño e implementación del flujo técnico que conecta tu sistema de facturación con los requisitos del RRSIF y, cuando corresponda, con los servicios de la AEAT.
Última revisión normativa
- Ámbito
- SaaS, ERP, software propio y producto de facturación
- Hitos vigentes
- 01/01/2027 y 01/07/2027, según el obligado afectado
- Límite
- Implementación técnica, sin sustituir la validación fiscal
Contexto
La adaptación no termina al generar un XML. Hay que decidir modalidad, preservar la secuencia de facturación, producir registros trazables, resolver rechazos y dejar evidencia suficiente para declarar cada versión del software.
01
Empezar por el flujo real
La primera revisión identifica dónde nace una factura, quién puede alterarla y qué sistemas intervienen antes de decidir la integración.
02
Modalidad
Decisión documentada entre VERI*FACTU y NO VERI*FACTU con el asesor del cliente, sin mezclar los controles propios de cada alternativa.
03
Responsabilidades
Separación entre producto, integrador, titular de los certificados, responsable fiscal y persona que acepta la versión.
02
Piezas de implementación
El alcance se concreta contra las especificaciones publicadas, los casos de uso del producto y sus condiciones de operación.
01
Registros y validación
Modelo de alta y anulación, XML/XSD, campos fiscales, encadenamiento, huella, QR y validaciones previas al envío.
02
Transporte y certificados
Autenticación, custodia de certificados, envío seguro, idempotencia, timeouts y separación entre pruebas y producción.
03
Estados y recuperación
Aceptaciones, rechazos, subsanaciones, colas, reintentos controlados, conciliación y trazabilidad de cada respuesta.
03
Entrega que se puede revisar
La adaptación debe quedar ligada a una versión concreta del software. Cambiar el comportamiento fiscal exige volver a evaluar esa versión, actualizar la evidencia y revisar la declaración responsable que corresponda.
- Matriz de requisitos y decisiones de arquitectura.
- Implementación con pruebas unitarias, integración y casos negativos.
- Evidencia del entorno externo de pruebas sin datos comerciales reales.
- Runbook de operación, incidencias, reintentos y recuperación.
- Soporte técnico para preparar la declaración responsable por versión.
04
Calendario sin mensajes de alarma
La AEAT indica como fechas obligatorias el 1 de enero de 2027 para contribuyentes del Impuesto sobre Sociedades y el 1 de julio de 2027 para el resto de obligados incluidos en el ámbito correspondiente. Antes de convertir una fecha en requisito del proyecto hay que confirmar sujeto, territorio, régimen y exclusiones con el asesor fiscal.
El objetivo técnico es llegar con margen para probar una versión estable, corregir rechazos y ensayar la operación; no esperar a la fecha de aplicación para descubrir cómo factura realmente el producto.
Criterio de validación
Una prueba útil cubre el ciclo completo y conserva evidencia por versión. Un envío aceptado de forma aislada no demuestra que el sistema sea operable.
- 01Alta y anulación aceptadas en el entorno externo de pruebas.
- 02Rechazo reproducible y error presentado sin perder trazabilidad.
- 03Subsanación vinculada al registro previo y aceptada.
- 04Declaración responsable identificada con la versión evaluada.
Preguntas habituales
Respuestas breves sobre alcance, evidencia y límites de la implementación.
¿La AEAT homologa o certifica el software?+
No se presenta este servicio como una homologación de la AEAT. El productor del sistema emite una declaración responsable para cada versión y conserva la evidencia que sustenta lo declarado.
¿VERI*FACTU y NO VERI*FACTU usan el mismo flujo?+
Comparten requisitos del RRSIF, pero no son la misma modalidad operativa. La decisión afecta al envío, la custodia y otros controles, por lo que debe fijarse antes de cerrar la arquitectura.
¿Se puede probar sin usar facturas de clientes?+
Sí. El protocolo técnico debe usar identidades y documentos de prueba controlados, separar certificados y endpoints por entorno y evitar reutilizar datos comerciales en los artefactos de validación.
¿La integración incluye asesoramiento fiscal?+
No. Se implementan requisitos técnicos y se documentan decisiones. El ámbito subjetivo, el tratamiento tributario y la aceptación fiscal deben validarse con el asesor del cliente.
Fuentes oficiales
Base normativa y técnica consultada para esta página. Las especificaciones pueden cambiar y deben comprobarse de nuevo al iniciar el proyecto.
- Preguntas frecuentes sobre sistemas informáticos de facturación
AEAT · calendario, ámbito y criterios generales
- Información técnica y esquemas VERI*FACTU
AEAT · diseños, WSDL, XSD, validaciones y servicios
- Modalidades VERI*FACTU y NO VERI*FACTU
AEAT · diferencias operativas entre modalidades
- Declaración responsable del sistema informático
AEAT · responsabilidad del productor y declaración por versión
- Real Decreto 1007/2023, texto consolidado
BOE · requisitos del RRSIF y declaración responsable
- Orden HAC/1177/2024, texto consolidado
BOE · desarrollo técnico, QR y contenido
Revisión técnica inicial
Revisa el flujo antes de estimar la adaptación.
Con la versión del producto, tipos de factura, modalidad prevista y diagrama de emisión puedo identificar dependencias y proponer un primer alcance técnico.
- No envíes certificados, NIF, facturas ni secretos en este formulario.
- La aplicabilidad fiscal o jurídica se valida con tu asesor.
- Respuesta humana habitual en un día laborable.