Verifactu · integración técnica
Esta página es para quien ya tiene un ERP, un programa de gestión propio o un sistema heredado que factura todos los días y no quiere tirarlo. No hablamos de comprar un programa nuevo: hablamos de qué hay que escribir dentro del tuyo.
Respuesta corta
Uno. Tu software tiene que generar un registro de facturación por cada factura y por cada anulación, encadenarlos con una huella SHA-256 y no permitir que nadie los modifique después.
Dos. Si eliges operar como VERI*FACTU y enviar los registros a la Agencia, te quitas la firma electrónica y el registro de eventos, que son las dos piezas más caras de construir.
Tres. Si el software lo desarrollas tú, el productor eres tú, y la declaración responsable de cada versión la firmas tú.
Piezas a implementar
7
Cinco si operas como VERI*FACTU.
Algoritmo de huella
SHA-256
Lista L12 de la Orden, valor 01, el único admitido.
Espera inicial entre envíos
60 s
Valor de partida, actualizable en cada respuesta de la AEAT.
Todo lo que hay en esta página sale del Real Decreto 1007/2023, de la Orden HAC/1177/2024 o de la sede electrónica de la AEAT, con su artículo citado en cada bloque.
Qué hay que escribir
Estas son las siete piezas que el reglamento y su orden técnica exigen. Dos de ellas solo aplican si decides no operar como VERI*FACTU, y por eso esa decisión es lo primero que hay que tomar en el proyecto.
Por cada factura expedida hay que generar un registro de facturación de alta. No es un log ni una copia de la factura: es un objeto de datos con estructura propia, el que después se encadena, se firma cuando toca y se remite cuando toca.
Para el desarrollador eso es una tabla que no comparte ciclo de vida con la de facturas: el registro nace cerrado y no se vuelve a tocar.
Anular no es borrar. Cualquier corrección o anulación se hace mediante al menos un registro de facturación adicional posterior, conservando inalterables los datos originalmente registrados.
Si tu ERP resuelve hoy los errores de facturación con un UPDATE o un borrado lógico, esa parte se reescribe entera.
Cada registro incorpora la huella del anterior: así puede verificarse el rastro siguiendo la secuencia de creación desde el primero al último, y todos los datos quedan correctamente fechados.
El algoritmo es SHA-256, la lista L12 de la Orden, cuyo único valor admitido es el 01. Los campos que entran en el cálculo están tasados en el artículo 13.1 y los tienes más abajo uno a uno.
Se basa en el estándar ETSI EN 319 132 y usa XAdES Enveloped Signature, con una clave privada asociada a un certificado electrónico cualificado de firma en vigor, emitido por un prestador cualificado conforme al Reglamento (UE) 910/2014 e incluido en la lista de confianza de la Unión Europea. La firma se guarda en el propio registro.
Esta pieza desaparece en modo VERI*FACTU: el artículo 16.3 del RRSIF dice que esos sistemas no tienen obligación de firmar y que basta con calcular la huella.
Un segundo diario, también encadenado, de lo que le pasa al sistema: arranques y paradas del modo no VERI*FACTU, procesos de detección de anomalías y sus resultados, restauraciones de copia de seguridad y exportaciones de registros.
Además, un registro resumen por cada 6 horas operativo aunque no haya pasado nada, y otro antes de apagarse. Todo en XML con codificación UTF-8. Es la pieza más cara de las siete, y también desaparece en modo VERI*FACTU.
El matiz que cuesta dinero cuando aparece tarde: el párrafo segundo del artículo 8.1 exige que el sistema TENGA CAPACIDAD de remitir todos los registros a la Agencia, también si no operas como VERI*FACTU. No enviar no te libra de poder enviar.
El artículo 4 de la Orden detalla esa capacidad: conexión a la sede, gestión de certificados electrónicos, remisión con la estructura, formato y codificación requeridos por protocolos seguros, y procesamiento de las respuestas.
Toda factura en papel o imagen digital lleva un QR de entre 30 por 30 y 40 por 40 milímetros, norma ISO/IEC 18004, nivel M de corrección de errores, con la URL del servicio de cotejo más cuatro datos: NIF del obligado, número de serie y número de factura, fecha de expedición e importe total.
Si la expide un sistema VERI*FACTU se añade la frase "Factura verificable en la sede electrónica de la AEAT" o "VERI*FACTU", en letra y tamaño bien visibles. En factura electrónica estructurada basta la URL como campo independiente, sin QR.
La decisión que más pesa
Mucha gente da por hecho que enviar a Hacienda es la opción incómoda. Para quien programa es justo al revés: enviar quita trabajo, y bastante. Esta tabla es la conversación entera resumida en siete filas.
| Requisito | VERI*FACTU | No VERI*FACTU | Artículo |
|---|---|---|---|
| Envío a la AEAT | Sí, y es lo que define el modo: remisión continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente de todos los registros generados | No hay envío sistemático, pero el sistema tiene que conservar la capacidad técnica de remitir | Artículos 16.1 y 8.1 del RRSIF |
| Firma electrónica de los registros | No es obligatoria. Basta con calcular la huella | Obligatoria: XAdES Enveloped sobre ETSI EN 319 132, con certificado cualificado de firma en vigor | Artículos 16.3 del RRSIF y 14 de la Orden |
| Registro de eventos | No aplica. El artículo 3 de la Orden excluye expresamente su artículo 9 | Obligatorio: nueve tipos de evento, encadenados, más un resumen cada 6 horas de funcionamiento y otro antes de apagarse | Artículos 3 y 9 de la Orden |
| Presunción de cumplimiento del artículo 8 | Sí. Se presume que los sistemas VERI*FACTU cumplen por diseño los requisitos del artículo 8 del RRSIF | No hay presunción: el cumplimiento hay que sostenerlo pieza a pieza | Artículo 16.2 del RRSIF |
| Frase obligatoria en la factura | Sí: "Factura verificable en la sede electrónica de la AEAT" o "VERI*FACTU", en letra y tamaño bien visibles | No. El QR sí, la frase no | Artículo 21 de la Orden |
| Permanencia mínima en el modo | Se entiende que optas por VERI*FACTU al iniciar sistemáticamente la remisión, y la opción dura al menos hasta que acabe el año natural del primer envío efectivo | Sin permanencia asociada a una opción | Artículo 16.5 del RRSIF |
| Coste relativo de construcción | Menor. Te quitas dos de las siete piezas, y son las dos que más código y más mantenimiento traen | Mayor. Firma con certificado cualificado y su gestión de caducidades, más el diario de eventos completo con sus resúmenes periódicos | Consecuencia directa de los artículos 16.3 del RRSIF y 3 de la Orden |
Léelo una vez más: operar como VERI*FACTU sale más barato de construir. No hay que firmar electrónicamente los registros (artículo 16.3 del RRSIF) y no hay registro de eventos (artículo 3 de la Orden, que excluye su artículo 9). Son las dos piezas que más horas se llevan y las dos que más mantenimiento arrastran después.
A cambio asumes la frase visible en la factura y la permanencia del artículo 16.5 del RRSIF.
Artículo 13.1 de la Orden
La huella no se calcula sobre la factura entera, sino sobre un subconjunto tasado de campos. El último de la lista es siempre la huella del registro anterior: ahí está el encadenamiento.
Registro de alta
Registro de anulación
El registro de evento tiene su propia lista de ocho campos (identificador del productor, del sistema informático y de su versión, número de instalación, NIF del obligado, tipo de evento, huella del evento anterior y fecha, hora y huso horario), y solo existe si no operas como VERI*FACTU.
Dato importante antes de programar
El formato exacto de concatenación de esos campos y la codificación concreta del hash no están en el texto de la Orden, sino en un documento técnico que la Agencia Tributaria publica en su sede, al que remite el artículo 13.2. Ese documento es el que manda para el detalle. Aquí no reproducimos ninguna cadena de ejemplo a propósito: si te la encuentras en un blog, contrástala contra la sede antes de escribir una línea.
Algoritmo de cálculo y codificación de la huella o hash, en la sede de la AEATLímites duros
Tres prácticas habituales en sistemas que llevaban años funcionando bien. Ninguna sobrevive al reglamento.
El artículo 8.2.a) del RRSIF exige que, una vez generados y registrados, los registros no puedan alterarse sin que el sistema lo detecte y avise. No basta con no hacerlo: el sistema tiene que ser capaz de detectarlo y advertirlo.
La Agencia Tributaria lo responde con estas palabras: «cualquier operación sobre los registros de facturación, sea VERI*FACTU o no, debe ser registrada a través de un registro de facturación, por lo que el acceso desde el SIF a modificaciones directamente sobre la base de datos de registros ya emitidos no debe ser una operativa permitida». Esto afecta al panel de administración, a los scripts de mantenimiento y a la consola de soporte.
Preguntas frecuentes de la AEAT, cumplimiento y delegaciónEl artículo 8.2.b) obliga a que los registros estén encadenados de manera que pueda verificarse su rastro siguiendo su secuencia de creación desde el primero al último, y a que todos los datos registrados estén correctamente fechados. Una migración que reordene registros, un entorno de pruebas que escriba en la cadena de producción o un despliegue que reinicie la secuencia rompen precisamente eso.
La regla práctica: solo se añade. Toda corrección o anulación se hace mediante al menos un registro de facturación adicional posterior, conservando inalterables los datos originalmente registrados.
Artículo 13.1 del RRSIF
Es el punto que más sorprende a un jefe de sistemas. La certificación de que el software cumple no la emite un organismo externo: la emite quien produce el software, mediante declaración responsable. Y si el software lo has hecho en casa, ese eres tú.
Literal de la AEAT, desarrollo propio
«Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo».
Literal de la AEAT, código abierto
«La empresa que efectúe la programación del código o integre partes de otro software, ya sea o no de código abierto, debe realizar la declaración responsable, incorporar los datos obligatorios e indicar qué componentes utiliza. En el caso de que utilice código abierto, se hará responsable del funcionamiento del mismo».
Cada versión del sistema necesita su propia declaración responsable, por pequeña que sea la variación (artículo 13.2 del RRSIF y artículo 15.4 de la Orden). Para un equipo que despliega a menudo, esto significa meter la generación de la declaración dentro del proceso de release, no dejarla como un trámite anual.
El artículo 15 de la Orden fija lo que tiene que decir: nombre del sistema, código identificador, versión, componentes, si solo puede funcionar como VERI*FACTU, si admite varios obligados tributarios, tipos de firma usados cuando no es VERI*FACTU, nombre o razón social y NIF del productor, dirección postal y la declaración de cumplimiento.
Ejemplo de declaración responsable publicado por la AEATSistemas heredados
Un AS/400 que nadie mantiene, un desarrollo del que se fue su autor, un ERP cuyo proveedor ya no existe. Es el caso más común, y tiene cuatro salidas.
Vía 1
El sistema antiguo sigue haciendo lo suyo y la facturación sale por una pieza nueva
Es lo habitual cuando el núcleo antiguo funciona pero no se puede reescribir: el módulo nuevo genera los registros, calcula la huella, mantiene la cadena y habla con la Agencia, y el sistema viejo le pasa los datos de la operación. Ahora bien, dónde queda exactamente la frontera del sistema informático de facturación en una arquitectura concreta es una cuestión de encaje que hay que mirar caso por caso, y no está resuelta de forma general en el reglamento.
Ver el límite de honestidad más abajoVía 2
Otro expide por ti, pero la responsabilidad sigue siendo tuya
El artículo 6 del RRSIF admite que las obligaciones se cumplan materialmente por el destinatario de la operación o por un tercero con facultades otorgadas. La Agencia Tributaria lo confirma y añade, literal, que esta posibilidad no exime al obligado a expedir facturas de la responsabilidad sobre dicho cumplimiento. Puedes externalizar el trabajo, no el riesgo.
Artículo 6 del RRSIFVía 3
Vía extraordinaria, no una salida ordinaria
El artículo 5 del RRSIF permite solicitar la no aplicación total o parcial del reglamento cuando concurran circunstancias extraordinarias relacionadas con la actividad económica o de índole técnica, y la solicitud se presenta en la sede electrónica de la Agencia. Es una puerta excepcional que hay que justificar, no un plan de proyecto.
Artículo 5 del RRSIFVía 4
La opción cara, y a veces la barata a tres años vista
Si el sistema antiguo ya te bloquea otras cosas (no tiene API, nadie lo mantiene, el proveedor desapareció), Verifactu suele ser el empujón y no el problema. Aquí la conversación deja de ser de cumplimiento y pasa a ser de coste total.
Decisión de negocio, no una exigencia del reglamentoHasta aquí llegamos, y lo decimos
Cuando se pone un módulo de facturación nuevo por delante de un sistema antiguo, dónde queda exactamente la frontera del sistema informático de facturación en esa arquitectura concreta es una cuestión de encaje que hay que mirar caso por caso, y no está resuelta de forma general en el reglamento. No afirmamos que esa arquitectura cumpla automáticamente. Lo que sí puede hacerse es diseñarla de modo que todo lo que el reglamento exige ocurra dentro de la pieza nueva, y revisar el encaje con tu asesoría fiscal antes de dar el proyecto por bueno.
Adaptar o sustituir
Tres escenarios, tres horquillas. La diferencia entre el primero y el tercero no la marca Verifactu: la marca el estado en el que estaba tu sistema antes de que llegara el reglamento.
| Escenario | Horquilla | Cuándo encaja | De dónde sale la cifra |
|---|---|---|---|
| Módulo Verifactu sobre un sistema existente cuyo código controlamos | 5.000 a 12.000 € | Tienes el código fuente, hay quien lo entiende y la base de datos permite añadir las tablas de registros sin pelearse con el resto | Horquilla de herramienta interna que publicamos en nuestra página de precios |
| Módulo de facturación nuevo integrado por delante de un sistema antiguo que no se toca | 8.000 a 18.000 € | El sistema de siempre se queda como está y la facturación pasa a una pieza nueva que se integra con él | Horquilla de aplicación de complejidad media que publicamos en nuestra página de precios |
| Sustituir el sistema completo | 30.000 a 100.000 € o más | El sistema antiguo ya era un problema antes de Verifactu y la adaptación no arregla lo que de verdad duele | Horquilla de ERP o plataforma completa que publicamos en nuestra página de precios |
Estas horquillas son nuestras, de Speed Paradigm, no son cifras oficiales ni una media del mercado, y el alcance real solo se sabe viendo el sistema. Salen de la misma tabla que publicamos en precios de software a medida, donde están explicadas con lo que incluyen y lo que no.
Antes de pedir presupuesto, decide el modo: es lo que más mueve la cifra final.
No hay que esperar
La nota informativa de la Agencia Tributaria sobre la ampliación del plazo lo dice así: las entidades que presenten el Impuesto sobre Sociedades deben tener adaptados sus sistemas antes del 1 de enero de 2027, y el resto de obligados antes del 1 de julio de 2027. El periodo previo a esas fechas es un periodo de pruebas.
La Agencia mantiene un portal de pruebas externas en preportal.aeat.es. Para un equipo de desarrollo esto cambia la planificación: puedes construir la cadena de registros, validar el XML contra la estructura del anexo de la Orden y ajustar el control de flujo sin estrenar nada en producción la semana del corte.
El calendario real no lo marca la fecha del BOE, lo marca tu ciclo de releases: si facturas a diario, tocar el corazón de la facturación no se hace cualquier martes.
Las fechas, con el enlace al BOE de cada una y por qué las de 2026 quedaron superadas, están en nuestra página de plazos de Verifactu. La nota informativa de la AEAT y su información técnica para desarrolladores son las dos páginas que conviene tener abiertas durante el proyecto.
Honestidad
Preferimos una página más corta que una página con un requisito inventado. Estos tres puntos no los damos por cerrados.
01
El artículo 13.1 tasa los campos, pero el formato de concatenación y la codificación concreta viven en un documento técnico de la sede de la AEAT al que remite el artículo 13.2. Ese documento manda, y puede actualizarse sin que cambie la Orden. No publicamos aquí ninguna cadena de ejemplo.
02
En una arquitectura con un módulo satélite delante de un sistema antiguo, dónde queda la frontera del sistema informático de facturación es un encaje caso por caso. El reglamento no lo resuelve de forma general, y cualquiera que te diga lo contrario está simplificando.
03
Somos la empresa que escribe el software. Esta página recoge lo que dicen el reglamento, su orden técnica y la AEAT, con el enlace de cada punto, pero no sustituye a tu asesoría ni al criterio de tu abogado fiscalista. Lo normal es que el proyecto lo valide alguien de cada lado.
Descargable
Hemos convertido todo lo de esta página en una lista de comprobación con diez bloques, cada punto con el artículo que lo exige y con la marca de si aplica a VERI*FACTU, a no VERI*FACTU o a los dos. Sirve para revisar un sistema propio y también para apretar a un proveedor.
Preguntas frecuentes
¿Tu duda no está aquí? Cuéntanosla y te respondemos en 48 horas.
En dos piezas de código completas. Un sistema es VERI*FACTU cuando remite a la Agencia Tributaria, de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente, todos los registros generados (artículo 16.1 del RRSIF). A cambio, el artículo 16.3 dice que no tiene obligación de firmar electrónicamente los registros, y el artículo 3 de la Orden HAC/1177/2024 excluye la aplicación de sus artículos 6.b) a 6.f), 7.f), 7.h), 7.i), 7.j), 8 y 9 mientras se actúe como VERI*FACTU. El artículo 9 es el registro de eventos: en ese modo no existe. Además el artículo 16.2 presume que esos sistemas cumplen por diseño el artículo 8. Con el presupuesto delante, VERI*FACTU es el camino corto.
Tu empresa. El artículo 13.1 del RRSIF atribuye la certificación, mediante declaración responsable, a la persona o entidad productora del sistema. La Agencia Tributaria lo responde así: "Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo". No hay certificación externa ni registro previo, y cada versión necesita la suya por pequeña que sea la variación.
SHA-256: en la Orden es la lista L12, cuyo único valor admitido, el 01, es SHA-256. Los campos están tasados en el artículo 13.1. Lo importante: el formato exacto de concatenación y la codificación concreta del hash no están en el texto de la Orden, sino en un documento técnico que la AEAT publica en su sede, al que remite el artículo 13.2. Ese documento manda, y por eso aquí no reproducimos ninguna cadena de ejemplo.
Sí, por dos motivos. Si no operas como VERI*FACTU, el artículo 14 de la Orden te obliga a firmar los registros con un certificado cualificado de firma en vigor, de prestador cualificado conforme al Reglamento (UE) 910/2014 e incluido en la lista de confianza de la Unión Europea. Y el párrafo segundo del artículo 8.1 del RRSIF exige capacidad de remitir aunque no remitas, capacidad que según el artículo 4 de la Orden incluye la gestión de certificados electrónicos.
Hay control de flujo obligatorio. El artículo 16 de la Orden fija un tiempo de espera entre envíos que toma inicialmente el valor de 60 segundos, y la respuesta de la Agencia devuelve un valor actualizado que hay que respetar en el envío siguiente. También hay un máximo de registros por envío. Si una incidencia técnica impide remitir: remitir en cuanto sea posible respetando el orden temporal, avisarlo en el campo habilitado del mensaje, reintentar al menos una vez cada hora y mostrar un aviso visible al usuario mientras queden registros pendientes.
Corregir sí, modificar el registro no. El artículo 8.2.a) del RRSIF exige que los registros no puedan alterarse sin que el sistema lo detecte y avise, y que toda corrección o anulación se haga con al menos un registro adicional posterior. La Agencia lo lleva hasta la base de datos: "cualquier operación sobre los registros de facturación, sea VERI*FACTU o no, debe ser registrada a través de un registro de facturación, por lo que el acceso desde el SIF a modificaciones directamente sobre la base de datos de registros ya emitidos no debe ser una operativa permitida".
Cuatro vías: un módulo de facturación nuevo por delante, delegar el cumplimiento material en un tercero al amparo del artículo 6 del RRSIF (sabiendo que, según la propia Agencia, eso no exime al obligado de la responsabilidad), solicitar la no aplicación del reglamento por circunstancias extraordinarias del artículo 5, que es una vía excepcional, o sustituir el sistema. Lo que no funciona es esperar: la declaración responsable la firma el productor, y si el productor desapareció nadie la va a firmar por él.
Sigue por aquí
Guía principal
Qué obliga el reglamento, requisitos del artículo 8, declaración responsable, sanciones y qué hacer si tu programa no cumple.
Página hermana
La casuística caso por caso: sociedades, autónomos, SII, territorios forales, Canarias y quien factura solo a particulares.
Calendario
La línea de tiempo completa con el enlace al BOE de cada fecha, hasta el 1 de enero y el 1 de julio de 2027.
Auditoría gratuita de tu sistema
Sabemos cuál es tu miedo: que un desarrollo a medida se convierta en un pozo sin fondo sobre un sistema que nadie entiende del todo. Por eso primero miramos, y gratis: con qué está hecho, si hay código que podamos tocar y dónde nace hoy la factura. Te contestamos con una de las tres horquillas de esta página y el porqué.
Nos sale mejor y más barato que a otros porque usamos IA de vanguardia para acelerar el desarrollo y elevar la calidad del código: revisamos más, repetimos menos y ese ahorro de horas se te queda a ti en el presupuesto.
Si prefieres escribir, dinos en el formulario con qué está construido tu sistema y quién lo mantiene hoy. Con eso ya podemos decirte por dónde iría la cosa.