Aviso ¡PLAZO AMPLIADO! Desde el 1 de enero de 2027 tu Software de Facturación debe cumplir el RD 1007/2023 (Veri*Factu). Winfac ya está adaptado.
🔗 Tecnología

Registros inalterables:
hash encadenado, logs
y trazabilidad

Guía técnica y accesible sobre cómo funciona la tecnología de registros inalterables en los sistemas de facturación conformes al RD 1007/2023: qué datos se guardan, cómo se protegen y qué los hace imposibles de manipular sin que se note.

¿Qué significa que los registros sean inalterables?

No puedes borrar ni modificar facturas sin dejar rastro...

¿Qué son los registros inalterables?

Un registro inalterable es un apunte digital que documenta cada operación de facturación (creación, anulación, sustitución o envío de una factura) de tal forma que, una vez creado, es técnicamente imposible modificarlo sin que la modificación quede al descubierto.

La inalterabilidad no se consigue guardando un PDF en una carpeta. Se consigue mediante técnicas criptográficas: concretamente, mediante funciones de hash (resumen criptográfico) y el encadenamiento secuencial de esos hashes. El RD 1007/2023 exige explícitamente que los sistemas de facturación implementen estos mecanismos.

¿Por qué hace falta tecnología criptográfica? Un fichero de base de datos o un fichero de texto se pueden editar con un editor. Un PDF se puede regenerar. La única manera de garantizar que un registro no ha sido alterado sin dejar rastro es matemática: calcular una huella digital del contenido que cambie completamente si se modifica cualquier carácter, y encadenar esas huellas para que no se pueda reescribir el historial.

¿Qué es una función hash? Explicación sencilla

Una función hash criptográfica toma cualquier cantidad de datos (texto, números, un fichero completo) y produce una cadena de caracteres de longitud fija, llamada huella digital o simplemente hash. Las propiedades fundamentales son:

  • Determinista: los mismos datos siempre producen exactamente el mismo hash.
  • Avalancha: cambiar un solo carácter de los datos de entrada cambia completamente el hash resultante. No hay forma de predecir el nuevo hash a partir del anterior.
  • Irreversible: a partir del hash no se pueden recuperar los datos originales.
  • Resistente a colisiones: es computacionalmente inviable encontrar dos documentos distintos con el mismo hash.

El estándar exigido por la Orden HAC/1177/2024 es SHA-256 (Secure Hash Algorithm 256 bits), que produce hashes de 64 caracteres hexadecimales. Actualmente, SHA-256 no tiene colisiones conocidas y se considera criptográficamente seguro.

El hash encadenado: la clave de la inalterabilidad

Un solo hash por factura no sería suficiente: alguien podría borrar una factura y recalcular su hash sin que se note. La solución es el encadenamiento: el hash de cada registro incluye en su cálculo el hash del registro anterior. Esto crea una cadena de dependencias donde:

  • El registro N depende del N-1.
  • El registro N-1 depende del N-2.
  • … y así hasta el primer registro.

Si alguien modifica o borra el registro 47, su hash cambia. Pero el registro 48 ya fue calculado incluyendo el hash del 47 original, por lo que el hash del 48 ahora no concuerda con el recalculado del 47. Toda la cadena posterior se invalida.

// Ejemplo simplificado de cadena de registros de facturación
▶ REGISTRO 001 — Factura F-2025-001
"IDFact": "F-2025-001",
"Fecha": "2025-03-15",
"Total": "1452.00",
"HashPrevio": "0000000000000000", // primer registro
"Hash": "a3f8c2e1d7b94..."
↓ el Hash de F-001 se incluye en F-002
▶ REGISTRO 002 — Factura F-2025-002
"IDFact": "F-2025-002",
"Fecha": "2025-03-17",
"Total": "890.50",
"HashPrevio": "a3f8c2e1d7b94...", // = Hash de F-001
"Hash": "9bc34f12a8e71..."
↓ el Hash de F-002 se incluye en F-003
▶ REGISTRO 003 — Factura F-2025-003
"IDFact": "F-2025-003",
"Fecha": "2025-03-18",
"Total": "2100.00",
"HashPrevio": "9bc34f12a8e71...", // = Hash de F-002
"Hash": "e52a9d3c7f041..."
¿Qué pasa si se intenta manipular? Si alguien modifica el importe de F-2025-002 de 890,50 € a 500,00 €, el hash de ese registro cambia completamente. Al verificar la cadena, el HashPrevio de F-2025-003 («9bc34f12a8e71…») ya no coincide con el nuevo hash del registro 002. El sistema detecta la manipulación automáticamente. Para que el fraude pasara desapercibido habría que recalcular todos los hashes posteriores, lo que requeriría acceso al código fuente del software y al entorno de cálculo original.

¿Qué contiene cada registro de facturación?

La Orden HAC/1177/2024 especifica exactamente los campos que debe contener cada registro. Winfac implementa todos ellos:

IDFactura
Serie y número de la factura. Identificador único dentro del ejercicio.
FechaExpedicion
Fecha y hora de expedición de la factura (ISO 8601).
NombreRazonSocial
Nombre o razón social del emisor.
NIF
NIF del obligado tributario emisor.
TipoFactura
Alta, anulación o sustitución del registro anterior.
CuotaTotal
Importe total de cuotas tributarias (IVA, recargo…).
ImporteTotal
Importe total de la factura (base + impuestos).
Encadenamiento
Hash del registro anterior. Campo que crea la cadena.
SistemaInformatico
Nombre, versión y NIF del fabricante del software (Winfac / Eventronic).
NumeroRegistro
Número correlativo del registro en la cadena del ejercicio.
FechaHoraHusoHorario
Fecha, hora y zona horaria del momento de generación del registro.
Huella (Hash)
SHA-256 calculado sobre todos los campos anteriores del registro.

Tipos de eventos registrados en el log

El log de auditoría no solo recoge la emisión de facturas. Debe documentar todos los eventos relevantes sobre cada registro de facturación:

Alta

Creación de una nueva factura. Es el evento más frecuente. Genera el registro con todos sus campos y calcula el hash encadenado.

Anulación

Anulación de una factura previamente emitida. La factura anulada sigue en el log; se añade un nuevo registro de anulación que referencia a la original. No se borra nada.

Sustitución

Rectificación de una factura (factura rectificativa). Se genera un nuevo registro que sustituye al anterior, dejando ambos en el log con su relación indicada.

Envío AEAT

(Solo modalidad Veri*Factu) Confirmación de que el registro fue enviado a la AEAT y el acuse de recibo fue recibido. Incluye fecha/hora y resultado del envío.

Formato del log: JSONL y base de datos

La norma permite que los registros se almacenen en base de datos o en ficheros estructurados. Winfac utiliza una doble capa de almacenamiento:

Base de datos interna (Access/BD local)

Cada registro de facturación se almacena en una tabla protegida de la base de datos del sistema, junto con su hash y el hash del registro anterior. Esta tabla no es editable desde el interfaz de usuario del programa. El acceso está restringido a nivel de aplicación.

Fichero JSONL de auditoría

Simultáneamente, cada evento queda registrado en un fichero de texto en formato JSONL (JSON Lines: un objeto JSON por línea). Este formato es legible por humanos, importable por cualquier herramienta de análisis y exportable en segundos para entregarlo a la inspección fiscal.

// Ejemplo de línea en el fichero JSONL de auditoría de Winfac {"tipo":"ALTA", "idFact":"F-2025-047", "fecha":"2025-04-15T09:32:11+02:00", "usuario":"jmartinez", "total":1815.40, "cuotaIVA":315.40, "hashPrev":"e52a9d3c7f041a8b...", "hash":"b7c3f8a291e04d5...", "sw":"Winfac", "swVer":"2025.1", "nifFab":"B12345678"} {"tipo":"ANULACION", "idFact":"F-2025-047", "fecha":"2025-04-16T11:05:44+02:00", "usuario":"jmartinez", "motivo":"Error en receptor", "hashPrev":"b7c3f8a291e04d5...", "hash":"a19d2c84f7b30e1...", "sw":"Winfac", "swVer":"2025.1", "nifFab":"B12345678"}

Conservación: 4 años mínimo

El RD 1007/2023 establece que los registros de facturación deben conservarse durante al menos 4 años contados desde la fecha de expedición de la factura correspondiente. Sin embargo, por coherencia con la normativa contable y fiscal general (que exige conservar la documentación durante 5 años o el período de prescripción), la recomendación práctica es conservarlos durante 5 años.

Winfac organiza los registros por ejercicio fiscal. Al cerrar cada año, el log del ejercicio queda sellado y puede exportarse a un fichero JSONL archivado. Los registros no se pueden eliminar desde la interfaz del programa.

El código QR tributario

El RD exige que toda factura entregada al cliente (en papel o en PDF) incluya un código QR que permita verificarla. El QR codifica una URL con los parámetros básicos de la factura:

  • NIF del emisor
  • Número y serie de la factura
  • Fecha de expedición
  • Importe total
  • Cuota de IVA
  • Indicador de si es Veri*Factu o no

Al escanear el QR, el receptor puede acceder al servicio de cotejo de la AEAT (si es Veri*Factu) o a una verificación local. Esto permite a cualquier persona comprobar que la factura existe y no ha sido manipulada.

📝

Factura emitida

Usuario registra la venta

🔢

Registro generado

Software crea campos normalizados

🔗

Hash calculado

SHA-256 sobre datos + hash previo

💾

Log guardado

BD + JSONL, inalterable

📱

QR en factura

URL de cotejo con parámetros

📡

Envío AEAT

(Solo Veri*Factu)

Exportación y entrega a la inspección

Si la Agencia Tributaria solicita los registros de facturación en una inspección o requerimiento, el sistema debe ser capaz de exportarlos en el formato especificado por la Orden HAC/1177/2024. Winfac permite exportar:

  • Por ejercicio fiscal: todos los registros del año seleccionado.
  • Por rango de fechas: para requerimientos específicos.
  • Formato JSONL: legible, verificable y conforme a la norma.
  • Formato XML normalizado: para entrega directa a la AEAT si se requiere.

La exportación incluye automáticamente los hashes de verificación, permitiendo a la AEAT comprobar la integridad de la cadena sin necesidad de acceder al software original.

Winfac: doble log por diseño Winfac mantiene simultáneamente la cadena de hash en la base de datos y el log JSONL en disco. Ambas fuentes son verificables de forma independiente. La especificación técnica completa de los logs de Winfac está disponible en los documentos descargables de esta página.