«¿Esto ya cumple Veri*factu?» es la pregunta que más se repite cuando una empresa se plantea cambiar de programa de facturación. La respuesta corta es que no se cumple marcando una casilla: se cumple si cada factura emitida deja un registro con huella, encadenado con el anterior, con su código QR de cotejo, y si ese registro se puede exportar sin que nadie lo haya editado por detrás.
El reglamento que lo desarrolla no regula cómo se ve tu factura en PDF. Regula el sistema informático que la produce. Esa diferencia explica por qué dos programas que imprimen facturas idénticas pueden estar en situaciones completamente distintas.
Qué pide el reglamento, en la práctica
Dejando a un lado el texto legal, un sistema de facturación conforme tiene que resolver cuatro cosas:
- Un registro por cada factura: no el PDF, sino un asiento con los datos identificativos, los importes, el tipo de factura y la huella calculada.
- Encadenamiento: cada registro incorpora la huella del anterior. La primera factura del sistema arranca la cadena y ahí ese campo va vacío.
- Código QR de cotejo: la factura impresa o en PDF lleva un QR que permite a la AEAT comprobar que esa factura existe en el registro.
- Registro de eventos: anulaciones y rectificaciones dejan su propio asiento. Nada se borra: se anula.
El calendario de entrada en vigor ha cambiado más de una vez desde que se aprobó la norma, así que el dato que importa no es el que circula en un titular de hace dos años: es la fecha aplicable a tu caso concreto, que conviene confirmar en la sede electrónica de la AEAT antes de planificar el desarrollo.
La huella no es un sello, es un hash de los datos
La huella es un SHA-256 calculado sobre una cadena de campos de la factura, en un orden concreto y con un formato concreto. No es una firma electrónica ni un sello de tiempo: es una función de resumen. Cambia un céntimo y la huella cambia por completo, sin que se pueda reconstruir la factura a partir de ella.
La cadena incluye, entre otros, el NIF del emisor, el número de serie, la fecha de expedición, el tipo de factura, la cuota total, el importe total y la huella del registro anterior:
IDEmisorFactura=...&NumSerieFactura=...&FechaExpedicionFactura=...&TipoFactura=...&CuotaTotal=...&ImporteTotal=...&HuellaAnterior=...
El nombre exacto de los campos y su formato van en la especificación técnica de la AEAT, que se revisa periódicamente. Una implementación seria contrasta contra la versión vigente del documento antes de desplegar y guarda con cada registro la versión con la que se calculó. Si dentro de dos años hay que demostrar cómo se generó una huella de 2026, ese detalle es la diferencia entre poder hacerlo y no poder.
El encadenamiento es lo que convierte el hash en prueba
Un hash suelto no sirve de mucho: quien tiene acceso a la base de datos puede recalcularlo después de tocar un importe. El encadenamiento lo impide, porque cada huella depende de la anterior. Alterar la factura 37 invalida la 38, la 39 y todas las que vienen detrás. Y como los registros no se borran, para maquillar la 37 habría que rehacer la cadena completa.
De ahí una consecuencia que sorprende a quien viene de otros sistemas: la numeración y la cadena son parte del diseño de datos, no un añadido. Si tu ERP permite borrar una factura emitida y reutilizar su número, no es que le falte un módulo: es que su modelo de datos no encaja con lo que se pide.
Los errores que aparecen en las primeras implantaciones
- Confundir el PDF con el registro. Se genera un PDF con un QR dibujado, pero no existe el asiento al que ese QR debería apuntar. La comprobación en la sede falla y el fallo no está en el QR.
- Calcular la huella sobre otro orden de campos. El resultado es un hash perfectamente válido y totalmente inservible: nadie puede verificarlo.
- Reiniciar la cadena con el año. La cadena no se reinicia por ejercicio; se reinicia si se migra el sistema, y esa migración hay que documentarla y conservar el histórico anterior.
- Recalcular huellas al reimprimir. La huella pertenece al registro original, no al documento que se imprime hoy.
- Tratar la anulación como un borrado lógico sin evento. Si no hay asiento de anulación, el registro no cuadra con la realidad de la empresa.
Cómo se comprueba en cinco minutos
La forma más rápida de entender qué se exige es verlo funcionar. En la demo de factura Veri*factu se emite una factura de prueba, se calcula su huella SHA-256 con la API criptográfica del navegador, se encadena con la factura anterior de la sesión y se genera el QR de cotejo junto con el PDF descargable.
Todo ocurre en tu equipo: la demo no envía la factura a ningún servidor, ni siquiera a los nuestros. Se detiene a las dos facturas por CIF, y es eso, una demostración: no sustituye al registro de facturación que debe conservar tu sistema.
Qué implica llevarlo a un ERP de verdad
En un proyecto real el trabajo no está en calcular el hash, que son veinte líneas de código. Está en tres sitios. En el modelo de datos: inmutabilidad, numeración, cadena y eventos. En las integraciones: el registro tiene que generarse en el mismo instante en que se emite la factura, no en un proceso nocturno que puede fallar en silencio. Y en la conservación: exportación y puesta a disposición del registro cuando la administración lo requiera, con el formato y la firma que correspondan.
Hay además una decisión que no es técnica: remitir cada factura a la AEAT o mantener el registro en tu propio sistema. La primera reduce la infraestructura que hay que mantener y aumenta la dependencia de un servicio externo; la segunda exige más control interno y más auditoría propia. Ninguna de las dos es gratis, y elegirla por coste sin mirar el resto suele salir caro.
Si tu programa actual factura bien pero no puede exportar el registro encadenado con la fecha y la versión de especificación con la que se generó cada huella, la pregunta ya no es si cumple: es qué hay que cambiar para que cumpla sin romper la facturación del día a día. Y si el cambio afecta al núcleo de tu aplicación, eso es desarrollo de software a medida, no una actualización de módulo.