Cómo funciona el encadenamiento de facturas en VeriFactu: hash SHA-256 y validación AEAT

El encadenamiento de facturas es el mecanismo que utiliza VeriFactu para garantizar la trazabilidad e inmutabilidad de los registros de facturación. Funciona enlazando cada factura con la anterior mediante una huella digital SHA-256, creando una cadena cronológica que impide modificaciones retroactivas.

Si estás integrando VeriFactu en tu software de facturación, entender este concepto te ayudará a comprender cómo fluye la información, aunque no tengas que implementar el algoritmo manualmente.

Qué es el encadenamiento y por qué existe

Cada factura enviada a la AEAT incluye un campo llamado Huella, que contiene un hash SHA-256 calculado a partir de los datos de la propia factura y de la huella de la factura anterior.

Este mecanismo garantiza que:

1. No se puede modificar una factura ya enviada sin que se detecte, porque al cambiar cualquier dato, su huella cambiaría.
2. No se puede eliminar una factura intermedia sin romper la cadena, porque la siguiente factura contiene la huella de la anterior.
3. No se puede alterar el orden temporal de emisión de facturas.

Es el mismo principio que utiliza blockchain: cada bloque (factura) contiene el hash del bloque anterior.

Estructura del hash SHA-256 en VeriFactu

La huella combina dos tipos de información: los datos identificativos y económicos de la factura (emisor, serie y número, fecha, tipo de factura, importes) y la huella de la factura anterior de la misma serie. El resultado se pasa por SHA-256 y se obtiene un string hexadecimal de 64 caracteres.

Lo que no es tan evidente a simple vista, es que la AEAT exige un orden de concatenación y un formato de cada campo (fechas, decimales, códigos de tipo) muy específicos y documentados en el reglamento técnico. Una desviación mínima: un separador de más, un formato de fecha distinto, un decimal con coma en vez de punto... produce un hash completamente diferente, y la AEAT rechaza el registro sin más explicación que un código de error genérico. Reproducir ese formato exacto de forma fiable, y mantenerlo si la especificación cambia, es donde está el verdadero trabajo.

Ejemplo real de una huella

Así es como se ve el campo Huella en un registro de facturación ya generado:

Huella:
3F8A1C9E2B7D4F6A0C5E8B3D9A2F7C1E4B6D8A3F9C2E7B1D5A8F4C6E9B3D2A7F

Un string hexadecimal de 64 caracteres, sin más información visible sobre cómo se ha construido. Esa opacidad es intencionada: el valor solo tiene sentido si se recalcula exactamente igual que lo hizo el emisor, y solo la AEAT (o quien conoce el algoritmo completo) puede verificarlo.

Gestión del encadenamiento: primera factura y cambios de sistema

Primera factura del sistema

La primera factura que se envía no tiene factura anterior, por lo que el campo de huella anterior se rellena con un literal reservado que indica el inicio de la cadena. Así, el sistema arranca sin necesidad de un hash previo.

Cambio de sistema de facturación

Si una empresa cambia de software o proveedor, la normativa permite "romper" la cadena de forma controlada, usando otro literal reservado para indicar que no hay registro previo disponible. Esto permite iniciar un nuevo encadenamiento sin invalidar los registros anteriores, pero exige coordinar bien el corte entre el sistema saliente y el entrante: si el sistema nuevo no sabe en qué estado quedó la cadena del anterior, el riesgo de generar un hash inconsistente es alto.

Errores comunes al implementar encadenamiento

Si implementas el encadenamiento manualmente (sin usar una API que lo gestione), estos son los fallos más frecuentes y, sobre todo, los más caros de depurar:

1. Orden incorrecto de campos en la concatenación

El orden de los campos en la concatenación importa, y no es intuitivo. Un cambio de orden produce un hash distinto sin ningún error explícito en tu propio código: todo compila, todo se ejecuta, y la factura se envía. El fallo solo aparece cuando la AEAT la rechaza, y el mensaje de error no te dice qué campo está mal colocado. Depurar esto a ciegas, factura a factura, es una de las causas más comunes de retrasos en la puesta en producción.

2. Formato de fecha incorrecto

La fecha debe representarse con un formato exacto dentro de la cadena a hashear. Si tu sistema usa internamente un formato distinto (como es habitual en la mayoría de bases de datos y lenguajes), necesitas una capa de normalización específica solo para este cálculo. Un desajuste aquí genera el mismo síntoma que el error anterior: rechazo sin pista clara del origen.

3. Uso de la huella de una factura no enviada o rechazada

Si intentas encadenar una factura a partir de una que fue rechazada por la AEAT, el encadenamiento se rompe. Solo se deben encadenar facturas cuyo envío fue confirmado con éxito, lo que obliga a tu sistema a distinguir con precisión entre "generada", "enviada" y "aceptada", y a no avanzar el puntero de la cadena hasta tener la confirmación.

4. Problemas de concurrencia

Si tu sistema permite facturar desde varios puntos de venta o terminales simultáneamente, necesitas gestionar qué factura es "la última" para cada serie. Dos facturas enviadas al mismo tiempo con el mismo hash anterior generan un conflicto que, si no se resuelve con un mecanismo de bloqueo o cola por serie, puede dejar la cadena inconsistente de forma silenciosa.

Cómo evitar gestionar el encadenamiento manualmente

Implementar correctamente el encadenamiento no es solo "calcular un hash": es sostener en el tiempo toda una capa de estado y cumplimiento normativo:

• Almacenar la última huella enviada de forma atómica para cada serie, incluso con escrituras concurrentes desde varios orígenes.
• Gestionar reintentos e idempotencia cuando una factura falla a mitad de envío, sin duplicar ni saltar registros de la cadena.
• Generar y enviar el registro en el formato (XML/SOAP) que exige la sede electrónica de la AEAT, y gestionar el ciclo de vida del certificado digital necesario para autenticar los envíos.
• Interpretar la taxonomía de códigos de error de la AEAT cuando un registro se rechaza, y decidir si se reintenta, se corrige o se escala.
• Mantener el sistema actualizado si la normativa cambia el formato del hash, los literales reservados o el esquema de envío, algo que ya ha ocurrido durante el desarrollo del reglamento VeriFactu.

Usar una API REST como VerifactuAPI delega toda esta responsabilidad. El flujo es:

1. Tu software envía los datos de la factura (número, fecha, emisor, líneas, importes).
2. La API calcula automáticamente el hash con el formato correcto y gestiona el encadenamiento con la factura anterior de la misma serie.
3. La API construye el envío en el formato que exige la AEAT, lo autentica y lo transmite.
4. Te devuelve el resultado y el registro completo con su huella generada.

Ejemplo de petición simplificada:

POST /api/v1/facturas

{
  "emisor": {
    "nif": "B12345678",
    "nombre": "Mi Empresa SL"
  },
  "factura": {
    "serie": "A",
    "numero": "001",
    "fecha": "2024-12-31",
    "tipo": "F1"
  },
  "totales": {
    "base": 100.00,
    "cuota": 21.00,
    "total": 121.00
  }
}

Le pasas los datos de negocio de la factura; la API se encarga del resto. No necesitas calcular ni almacenar nada relacionado con la cadena.

Validación del encadenamiento por parte de la AEAT

Cuando recibes la factura, la AEAT:

1. Recalcula la huella con los datos que has enviado.
2. Comprueba que coincide con la huella declarada en el campo Huella.
3. Verifica que la huella de la factura anterior coincide con la última huella recibida para esa serie.

Si cualquiera de estos puntos falla, la AEAT rechaza la factura con un código de error específico, sin indicarte exactamente qué parte del cálculo estaba mal. Ese es precisamente el motivo por el que la mayoría de los fallos de encadenamiento se detectan tarde: en producción y con facturas reales ya generadas.

Conclusión técnica

El encadenamiento de facturas en VeriFactu garantiza trazabilidad mediante criptografía básica: cada factura contiene el hash de la anterior. El concepto es simple; lo que lo vuelve difícil de implementar bien es todo lo que rodea al cálculo: el formato exacto exigido por la normativa, la gestión de estado por serie, la concurrencia, los reintentos y el mantenimiento frente a cambios regulatorios.

Si prefieres centrarte en la lógica de negocio de tu aplicación en lugar de mantener esta capa de cumplimiento normativo, delegar el encadenamiento a una API especializada es la opción más eficiente.

Puedes probar cómo funciona el encadenamiento automático en el sandbox de VerifactuAPI sin certificado digital registrándote gratis más abajo.