Registros Verifactu: huella y encadenamiento

Respuesta rápida

Un SIF genera registros de facturación de alta y, cuando corresponde, de anulación. Cada registro lleva una huella calculada según la especificación y, salvo que sea el primero, referencia datos del registro inmediatamente anterior, incluida su huella. Ese mecanismo aporta trazabilidad y permite detectar cambios; no convierte el registro en una factura electrónica ni el encadenamiento en una cadena de bloques. La AEAT describe el contenido del registro de alta.

Tres piezas que no deben confundirse

Pieza	Función	Ejemplo de uso
Factura	Documento que se expide al cliente	PDF, papel o factura electrónica estructurada.
Registro de facturación	Datos fiscales estructurados que produce el SIF	Alta de una factura o registro de anulación.
Huella/hash	Resultado del algoritmo aplicado a datos definidos del registro	Campo que se guarda y se referencia en el siguiente registro.

El contenido que resume la AEAT incluye la identificación del emisor y, cuando procede, del destinatario, número y serie, fechas, tipo de factura, importes y desglose. La lista completa depende del diseño de registro y de la versión técnica.

Cómo se forma el encadenamiento

Imagina tres registros generados por el mismo obligado y SIF:

Registro A (alta)  -> huella A
                         |
Registro B (alta)  -> referencia a A + huella B
                         |
Registro C (anulación) -> referencia a B + huella C

La FAQ de trazabilidad de la AEAT explica que el registro posterior incluye datos que permiten identificar el anterior. La cadena no elimina la necesidad de conservar cada registro: la referencia solo tiene sentido si el registro anterior sigue disponible y legible.

Qué algoritmo se usa

La FAQ de huella de la AEAT indica SHA-256 para los tipos de registro contemplados. No se aplica necesariamente a cada byte de un PDF: se calcula sobre los datos relevantes definidos para el tipo de registro en la especificación técnica.

La huella se almacena como un campo del registro y se incorpora al contenido del registro siguiente. Por eso el sistema debe:

• serializar los campos en el orden y formato exigidos;
• distinguir valores vacíos, nulos, fechas y decimales conforme al diseño;
• utilizar la misma codificación en generación, verificación y exportación;
• evitar normalizaciones posteriores que cambien el dato que fue huellado;
• probar el algoritmo con los ejemplos oficiales de la AEAT.

Un SHA-256 calculado sobre una cadena “parecida” no sirve si la serialización no es la de la especificación.

Alta y anulación no son lo mismo

El alta representa la factura emitida. La anulación es otro registro vinculado al alta cuando existe un supuesto que exige anularla. El alta original no se borra ni se reescribe para “corregir” el hash; la respuesta correcta puede ser generar el registro que corresponda y mantener ambos en la trazabilidad.

La FAQ de anulaciones exige conservar el registro de alta incluso si contiene un error y generar un registro de anulación vinculado. Para una modificación de importes o una devolución, el camino puede ser una factura rectificativa, como se explica en anulaciones y rectificativas.

Qué debe conservar una integración

Una integración con eCommerce o API debería conservar, por registro:

1. payload estructurado enviado o producido;
2. huella propia y referencia al anterior;
3. fecha de generación y entorno;
4. identificación externa del pedido o cobro;
5. solicitud y respuesta de la AEAT cuando exista remisión;
6. versión del esquema y del SIF;
7. relación entre alta, anulación y rectificativa.

No mezcles la clave idempotente del webhook con el número de factura. La primera evita procesar dos veces un evento; el segundo pertenece a la serie y numeración fiscal.

Comprobaciones antes de producción

• Genera dos altas consecutivas y verifica la referencia.
• Genera una anulación y comprueba que apunta al alta correcto.
• Cambia un campo huellado en una copia y verifica que el resultado ya no coincide.
• Repite el mismo evento de plataforma y confirma que no consumes otra numeración.
• Revisa que sandbox y producción tengan cadenas, credenciales y respuestas separadas.

La información técnica de la AEAT publica diseños, esquemas y algoritmo; una prueba local no sustituye esa fuente.

Estado de VeriFactu Fácil

La web pública de VeriFactu Fácil está en prelanzamiento. La API prevista contempla conservar la relación entre evento, registro y respuesta, pero no hay una API pública contratable que este artículo pueda presentar como disponible.

Ver los estados y errores de una remisión →