El algoritmo indicado actualmente por la AEAT es SHA-256 para todos los tipos de registro. La FAQ oficial concreta el algoritmo y remite a las especificaciones técnicas. La huella no es un número de factura, una firma electrónica ni un código de respuesta de la Agencia Tributaria. Es el resultado de aplicar el algoritmo a los datos que la especificación selecciona para cada tipo de registro.
La huella de un registro se incluye en el contenido del registro inmediatamente siguiente, formando el mecanismo de encadenamiento. La AEAT explica esta relación entre hash y trazabilidad. Así, cada nuevo eslabón apunta al anterior. Si cambia un dato que intervino en el cálculo, la comprobación deja de cuadrar.
Esta guía cubre el encadenamiento de registros de facturación en los SIF sujetos al Real Decreto 1007/2023. No sustituye los diseños de registro de la Orden HAC/1177/2024, no ofrece código de producción y no determina por sí sola si una factura es fiscalmente correcta. Las instalaciones forales y los sistemas excluidos del ámbito estatal necesitan un análisis propio.
Huella, cadena y trazabilidad son controles relacionados
Una función hash transforma una entrada en una salida de longitud fija. Un cambio mínimo en los datos produce, con una probabilidad abrumadora en la práctica, una salida distinta. Esa propiedad permite detectar alteraciones, pero no permite reconstruir la información original a partir de la huella.
Todos los registros de facturación de alta y de anulación generados por el SIF deben incorporar su huella. La AEAT incluye expresamente ambos tipos. El Real Decreto 1007/2023 también exige añadir el hash a esos registros. No basta con calcularlo para la factura PDF ni para el asiento contable: el objeto es el registro de facturación definido por la norma.
La cadena aparece cuando el siguiente registro conserva la referencia del anterior. Si R1 tiene una huella H1, R2 incorpora los datos de enlace de R1, incluida H1, y calcula su propia H2. R3 enlaza con R2. Este ejemplo es conceptual, no una especificación de campos ni una muestra válida para programar.
El artículo 8 del RRSIF exige trazabilidad mediante registros encadenados desde el primero hasta el último. El BOE formula el requisito y prohíbe mecanismos que oculten el rastro. La cadena ayuda a comprobar el orden y a detectar ausencias o modificaciones. No sustituye la conservación de los registros completos.
Qué datos enlazan con el registro anterior
Los datos de encadenamiento identifican la factura del registro anterior e incorporan su huella, actualmente completa. La FAQ de trazabilidad menciona emisor, serie, número, fecha de expedición y la huella anterior. La implementación exacta debe seguir el diseño técnico vigente; no copies una lista abreviada de una guía editorial.
La referencia permite distinguir dos comprobaciones. Primero, que el registro señala al predecesor correcto. Segundo, que la huella almacenada coincide con la que resulta de recalcular el registro anterior conforme a las reglas aplicables. Una referencia correcta con un hash incorrecto sigue siendo una incidencia.
No todos los campos visibles de una factura intervienen necesariamente en el cálculo de la misma manera. La AEAT señala que la huella se calcula sobre datos relevantes definidos por tipo de registro. Por eso exportar el XML, reordenarlo o cambiar una representación puede afectar a una herramienta casera aunque el SIF aplique correctamente la canonicalización prevista. La prueba debe usar la función del producto o un validador compatible con la especificación.
Una sola cadena para altas y anulaciones
Los registros de alta y de anulación no forman cadenas separadas: se intercalan en el orden en que el SIF los genera. La AEAT responde expresamente a esta duda. Si se genera un alta, después una anulación y luego otra alta, ese es el orden de la cadena.
Separarlas artificialmente ocultaría la secuencia real de actuaciones del sistema. También complicaría detectar qué ocurrió entre dos altas. La anulación es un nuevo registro; no borra el alta anterior ni vuelve atrás para modificar su huella.
Una factura rectificativa se expide como una nueva factura y origina su registro correspondiente. No se corrige la cadena editando el registro de la factura original. Conviene separar el problema documental de la factura del problema técnico de trazabilidad: una rectificativa puede estar perfectamente encadenada y, aun así, contener un error fiscal; una factura correcta puede estar dentro de una cadena rota por una incidencia del sistema.
La cadena se separa por SIF y obligado
La cadena de registros de facturación es única por cada par formado por SIF y obligado tributario. La AEAT describe esta unidad como el par SIF–obligado. Si una plataforma gestiona varios obligados, cada uno mantiene su secuencia. Si un obligado usa dos SIF independientes, cada sistema mantiene la suya.
Esto evita que la factura de una empresa dependa de la última huella generada para otra. También significa que una auditoría debe identificar con precisión instalación, versión, código del sistema y obligado. Pedir «la cadena de la empresa» puede ser ambiguo cuando hay varios centros o productos.
La separación no autoriza a mezclar registros al exportarlos. Una consolidación contable puede reunir datos, pero debe preservar el origen y permitir volver a la cadena correcta. Para arquitecturas distribuidas, consulta la guía sobre VERI*FACTU en centros de facturación desconectados.
Qué comprueba cada modalidad
Todos los SIF deben calcular y colocar correctamente la huella y encadenar los registros conforme a las especificaciones. La obligación de cálculo es común a las modalidades. La diferencia aparece en las funciones locales de comprobación.
Al generar un nuevo registro, un SIF no verificable debe comprobar el correcto encadenamiento del registro anterior. La FAQ exige verificar la huella anterior y la que este encadena. También debe ofrecer al usuario la posibilidad de comprobar las huellas de los registros disponibles.
Los SIF VERI*FACTU no están obligados a ofrecer una función de comprobación de huellas porque la AEAT puede verificarlas tras la remisión. La respuesta oficial explica esta diferencia. Eso no elimina el cálculo ni el encadenamiento.
La elección de modalidad no debe basarse solo en si el programa muestra un botón de validación. Compara remisión, operación sin conexión, soporte, conservación y responsabilidades. La guía sobre VERIFACTU frente a NO VERIFACTU desarrolla esa decisión.
Cómo revisar una cadena sin modificarla
Empieza con un periodo corto y una instalación identificada. Exporta los registros por el procedimiento previsto, conserva el original y trabaja sobre una copia. Anota versión, obligado, sistema, fecha de extracción y número de registros.
Ordena por secuencia de generación, no por fecha de la operación económica ni por número de factura. Para cada registro, comprueba:
- tipo de registro: alta o anulación;
- identificador del SIF y del obligado;
- fecha y hora de generación;
- datos que identifican al anterior;
- huella almacenada del anterior;
- huella propia calculada con las reglas vigentes;
- continuidad con el registro siguiente.
No recalcules hashes con una herramienta genérica sin reproducir los datos y la transformación técnica exactos. SHA-256 es el algoritmo, pero la entrada importa tanto como el propio algoritmo. Un salto de línea, una codificación o un orden distinto pueden producir otra salida sin demostrar que el registro original sea inválido.
Documenta cada resultado como correcto, no comprobable o discrepante. «No comprobable» sirve cuando falta la herramienta o el formato; no debe presentarse como fallo confirmado. Una discrepancia necesita el registro, el resultado esperado, el obtenido y el método usado.
Qué hacer ante una ruptura
Una ruptura puede aparecer porque falta un registro, se alteró un dato, se importó una copia incompleta, se restauró el sistema o la herramienta está aplicando mal las especificaciones. No atribuyas fraude ni incumplimiento antes de distinguir esas causas.
Conserva primero la evidencia. No edites el XML, no renumeres facturas y no insertes un registro fabricado. Identifica el primer punto donde la referencia o la huella dejan de coincidir y comprueba el registro inmediatamente anterior y el posterior.
Un registro ya generado y firmado o remitido no debe modificarse; cualquier cambio debe reflejarse mediante nuevos registros. La FAQ de integridad exige conservar el original y usar los registros posteriores que correspondan. La corrección de una factura no consiste en reparar silenciosamente el hash histórico.
Pide al proveedor un análisis reproducible: versión afectada, causa, alcance, procedimiento de recuperación y evidencia de que no se modificaron los originales. Si existe una notificación de la AEAT, prevalecen su alcance y su plazo; esta guía no sustituye la respuesta al requerimiento.
Diferenciar error de cadena y corrección fiscal
Una anulación o una subsanación legítima genera registros nuevos dentro de la cadena del SIF que realiza la operación. Una ruptura, en cambio, indica que la secuencia técnica no puede verificarse como debería. No uses una factura rectificativa para «arreglar» una huella ni un recálculo de hash para resolver una factura incorrecta.
Haz dos preguntas. ¿La factura o el registro necesitan una corrección conforme a la normativa de facturación? ¿La cadena técnica presenta una discrepancia independiente? Pueden coincidir, pero requieren evidencias y actuaciones distintas.
Un hash correcto no demuestra por sí solo que la operación económica sea real ni que todos los datos fiscales de la factura sean correctos. La AEAT define la huella como el resultado del algoritmo sobre determinados datos del registro; de esa definición se desprende este límite. El algoritmo prueba coherencia con una entrada, no la veracidad material de esa entrada. Tampoco acredita que no falte otra factura fuera del SIF.
Restauraciones, migraciones y cambios de versión
Las restauraciones son un punto sensible porque pueden devolver la base de datos a un estado anterior. Antes de recuperar, conserva copias, registra el último eslabón conocido y sigue el procedimiento del productor. Después verifica que la secuencia continúa y que no se han duplicado registros.
Una migración debe preservar los registros y su capacidad de consulta. No conviertas el histórico a un formato nuevo sobrescribiendo la única copia. Conserva exportaciones legibles y la herramienta o evidencia necesaria para comprobarlas durante el periodo exigible.
Tras una actualización, ejecuta una muestra con un alta, una anulación y otra alta. Comprueba que se intercalan, que el primer registro posterior enlaza correctamente y que no se abrió una cadena nueva sin justificación. Documenta cualquier cambio de identificador del sistema.
Evidencia que conviene pedir al proveedor
Solicita la declaración responsable de la versión y, por separado, una demostración del hash. La declaración no sustituye la prueba. La demostración debe mostrar los datos de entrada, la huella resultante, el enlace al anterior y el comportamiento ante una alteración controlada.
Pide también:
- especificación técnica aplicada y fecha;
- algoritmo y representación de la huella;
- unidad de cadena por SIF y obligado;
- tratamiento del primer registro;
- altas, anulaciones y subsanaciones;
- recuperación tras copia de seguridad;
- exportación y comprobación del histórico;
- mensaje y registro de una anomalía;
- procedimiento de soporte y conservación.
Estas peticiones son controles operativos, no una lista adicional atribuida a la AEAT. Ayudan a comprobar que el producto observado coincide con su documentación.
Un ejemplo conceptual para leer el informe
Imagina una secuencia con tres registros. El primero es un alta de la factura A-101. El segundo es un alta de A-102 y contiene la identificación y la huella del primero. El tercero es la anulación de A-101 y enlaza con el segundo, porque fue el registro generado inmediatamente antes. La anulación no vuelve a enlazar con el alta de A-101 por el hecho de referirse a esa factura: la relación documental y el orden técnico son dos cosas distintas.
En un informe deberían aparecer dos referencias diferentes para el tercer registro. Una identifica la factura anulada, A-101. Otra acredita cuál fue el registro anterior de la cadena, el alta de A-102. Si la herramienta mezcla ambas, puede dar la impresión de que la secuencia está rota cuando en realidad se está leyendo el campo equivocado.
Supón ahora que falta el segundo registro en la exportación. El tercero seguirá conteniendo su referencia y su huella, pero no será posible recalcularlo con el archivo recibido. Antes de declarar una ruptura en el SIF, comprueba si la exportación aplicó un filtro, si el periodo comenzó demasiado tarde o si se omitió un tipo de registro. Una extracción incompleta y una cadena dañada producen síntomas parecidos, pero exigen respuestas distintas.
El ejemplo no aporta valores de hash porque serían engañosos fuera de una especificación completa. Para reproducir un cálculo hacen falta los campos exactos, su representación, el orden, la codificación y las reglas vigentes. Un digest SHA-256 calculado sobre una frase didáctica no valida un registro de producción.
Cómo convertir la revisión en un control repetible
Define una muestra estable que el equipo pueda ejecutar después de cada cambio relevante. Incluye al menos dos altas, una anulación y, cuando proceda, registros de obligados distintos. Conserva el resultado esperado y la versión del SIF. Si la prueba cambia sin que haya cambiado la especificación, abre una incidencia antes de desplegar.
La evidencia debe permitir que otra persona repita la comprobación. Guarda el archivo original, la función utilizada, la versión del validador y el resultado. Evita depender de una captura aislada que solo muestre «válido». El registro concreto, la huella calculada y el enlace anterior deben quedar identificados.
Separa también los permisos. Quien factura no necesita modificar archivos históricos para consultar su estado. Quien administra copias no debería poder cerrar una incidencia alterando el origen. Estos controles internos son recomendaciones de operación, no requisitos literales nuevos del RRSIF.
Revisa el resultado con contabilidad cuando haya anulaciones o subsanaciones. El equipo técnico puede confirmar la continuidad, mientras contabilidad comprueba que el documento posterior responde al motivo correcto. Esta doble lectura evita convertir una cadena válida en una falsa garantía fiscal.
Preguntas frecuentes
¿Qué hash usa VERI*FACTU?
La AEAT indica actualmente SHA-256 para todos los tipos de registro. El cálculo no se hace sobre cualquier representación del archivo, sino sobre los campos y reglas definidos en las especificaciones técnicas vigentes.
¿Cómo se encadenan los registros de facturación?
El registro siguiente incorpora datos que identifican la factura del registro anterior y su huella. Las altas y anulaciones se encadenan juntas, según el orden de generación, en una cadena independiente por cada combinación de SIF y obligado tributario.
¿Qué pasa si falta el hash anterior?
Trátalo como una incidencia de trazabilidad. Conserva los registros originales, identifica el primer punto de ruptura, revisa exportaciones, restauraciones y cambios de versión y pide al proveedor una explicación reproducible. No inventes ni recalcules un registro histórico para cerrar el hueco.
¿Cómo detectar y documentar una ruptura en el encadenamiento?
Guarda la versión del SIF, el obligado, los identificadores de los registros anterior y posterior, sus huellas, la hora del hallazgo y el resultado de la comprobación. Añade la causa conocida, la actuación del proveedor y la evidencia de que los registros originales no se modificaron.
Siguiente paso
Selecciona una instalación y exporta un periodo corto. Comprueba una secuencia que incluya altas y una anulación, sin tocar los originales. Para situar la prueba dentro del proyecto completo, revisa la guía sobre hash SHA-256 y VERI*FACTU para pymes, el hub fiscal-contable y el contexto de la facturación manual sin programa.
Si necesitas contrastar una ruptura, una migración o la evidencia del proveedor, TaxFactory puede comprobar el encadenamiento del SIF. La revisión técnica y fiscal parte de la versión real; no certifica productos ni sustituye las especificaciones de la AEAT.