Cadena de hash SILICIE: por qué tus asientos no se pueden alterar

En una línea: cada asiento SILICIE se sella con SHA-256 sobre una cadena canónica que incluye el número legal del apunte, su posición en la cadena y la huella del asiento anterior; si alguien modifica, borra o reordena un apunte, todos los hashes posteriores quedan rotos y el sistema señala exactamente cuál fue el primero en fallar.

---

Base legal: Ley 38/1992 de Impuestos Especiales de Fabricación; RD 1165/1995, art. 50;

Orden HAC/998/2019 (SILICIE, en vigor desde el 1-1-2020);

Orden HAC/998/2019 (SILICIE), modificada por la Orden HAC/566/2020.

Autoridad: AEAT (Agencia Tributaria).

La misma primitiva SHA-256 rige en Verifactu/RRSIF (RD 1007/2023) y en los

registros de jornada con cadena encadenada.

---

1. Por qué SILICIE exige inalterabilidad

La AEAT recibe, casi en tiempo real, la contabilidad de productos de toda bodega obligada a SILICIE (Suministro Inmediato de Libros Contables de Impuestos Especiales). El sistema nació con la Orden HAC/998/2019 y lleva en vigor desde el 1 de enero de 2020; posteriormente fue modificada por la Orden HAC/566/2020.

El problema que SILICIE viene a resolver no es solo administrativo: es de fiabilidad. Una bodega lleva la cuenta de sus existencias de vino —entradas de uva y mosto, elaboración, trasiegos, salidas, mermas, autoconsumo, regularizaciones—. Si esa contabilidad puede modificarse a posteriori sin rastro, no tiene valor probatorio ante una inspección. La AEAT podría encontrar existencias que no cuadran con los movimientos declarados, y sin una cadena ininterrumpida de apuntes no hay forma de saber si el problema es un error de registro o una manipulación deliberada.

De ahí el principio de inalterabilidad: los asientos deben ser permanentes desde el momento en que se sellan. La corrección de un error es siempre un apunte nuevo que referencia al incorrecto, nunca una modificación del original. Y la garantía técnica de que esa permanencia es real —no solo declarativa— es la cadena de hash.

Vale la pena aclarar que este principio no nació con SILICIE. Es el mismo que rige en Verifactu (RD 1007/2023, Reglamento RRSIF) para los sistemas de facturación informática, en el SII (Suministro Inmediato de Información del IVA) y en los sistemas de registro de jornada con cadena encadenada. La AEAT aplica la misma lógica a todos sus instrumentos de control en tiempo real: lo que se suministra no puede desaparecer.

---

2. Qué es una cadena de hash: la idea en tres minutos

Un hash criptográfico es una función que transforma cualquier entrada —un texto, un archivo, una cadena de datos— en una huella de longitud fija. En el caso de SILICIE (y de Verifactu), la función empleada es SHA-256, que produce una cadena hexadecimal de 64 caracteres en mayúsculas.

Las propiedades clave de SHA-256 para este uso son tres:

1. Determinista. La misma entrada siempre produce el mismo hash.
2. Sensible a cualquier cambio. Modificar un solo carácter de la entrada produce una huella completamente diferente.
3. Unidireccional. No es posible reconstruir la entrada a partir del hash (no se puede «deshacer» la función).

Una cadena de hash añade una propiedad adicional: el hash de cada elemento depende del hash del elemento anterior. Así, el registro 5 refleja los datos propios del asiento 5 y, además, la huella del asiento 4, que a su vez reflejaba la del 3, y así sucesivamente hasta el origen. El resultado es que cualquier modificación en cualquier asiento intermedio rompe la cadena desde ese punto: el hash del asiento modificado cambia, el siguiente espera el hash anterior correcto y no lo encuentra, y la rotura se propaga hacia adelante.

Esta propiedad es precisamente la que hace que la inalterabilidad sea demostrable técnicamente, no solo afirmada. No basta con decir «no hemos tocado el asiento 47»: la cadena lo prueba o lo refuta.

---

3. La cadena canónica: qué campos entran en el hash de cada asiento

Para que el hash de dos sistemas que persisten los mismos datos produzca el mismo resultado —condición indispensable para que la reverificación funcione desde base de datos o desde memoria—, el orden y el formato de los campos deben estar completamente fijados. Cualquier variación, aunque sea un espacio o un decimal con distinto número de cifras, produce un hash diferente.

En SILICIE, la cadena canónica de cada asiento tiene este aspecto:

OrganizationId={valor}&EstablecimientoId={valor}&Ejercicio={valor}&NumeroAsiento={valor}&Tipo={valor}&Epigrafe={valor}&Producto={valor}&Unidades={valor}&Unidad={valor}&FechaMovimiento={valor}&CadenaSeq={valor}[&RegimenFiscal={valor}][&Justificante={valor}][&DepositoId={valor}][&AnulaAsientoId={valor}]&ClientOpId={valor}&HashAnterior={huella_del_anterior}

Los campos entre corchetes son opcionales: entran en la cadena solo cuando están presentes. Esta regla es importante porque garantiza el round-trip exacto: si en base de datos un campo es NULL, no se incluye en la cadena; si alguien lo añadiera artificialmente, la huella no coincidiría.

Sobre el formato de las cantidades: las unidades entran siempre con cuatro decimales fijos (por ejemplo, 3000.0000), que coinciden exactamente con la representación de la columna numeric(16,4) de la base de datos. Así, el hash calculado en memoria y el calculado leyendo desde la base son idénticos.

La cadena canónica se cierra con HashAnterior, que es la huella del asiento inmediatamente anterior en la cadena global del establecimiento. Para el primer asiento, ese valor es una cadena vacía.

---

4. El correlativo legal y la posición en cadena: los dos relojes que no pueden retroceder

Este es el punto más relevante para el auditor exigente, porque SILICIE mantiene dos contadores independientes que entran ambos en el hash:

El correlativo legal (NumeroAsiento)

Es el número de asiento dentro de un establecimiento y ejercicio (año natural). Arranca en 1 cada 1 de enero y avanza sin interrupciones: 1, 2, 3... El hecho de que este número esté dentro del hash significa que si alguien intentara renumerarlo —para disimular que falta un asiento, por ejemplo—, el hash resultante no coincidiría con el esperado.

La contabilidad SILICIE (Orden HAC/998/2019) se lleva con una secuencia correlativa de asientos vinculada al CAE (Código de Actividad y Establecimiento). El sistema verifica que la numeración no tiene huecos y no retrocede nunca.

La posición en cadena (CadenaSeq)

Es un segundo contador, de alcance más amplio que el correlativo legal: crece de forma continua para todo el establecimiento cruzando ejercicios. Si el correlativo legal es el «número de factura del año», la posición en cadena es el «número de registro histórico acumulado». Entran ambos en el hash, de modo que:

• No se puede insertar un asiento en el medio de la cadena (rompería la secuencia de CadenaSeq).
• No se puede reordenar la cadena (cambiaría la posición de cada asiento).
• No se puede «resetear» el ejercicio de forma artificial (el NumeroAsiento empezaría en 1 para el nuevo ejercicio, pero CadenaSeq continuaría desde donde estaba).

La combinación de ambos contadores establece que ni el número ni el orden pueden retroceder sin romper la cadena.

Por qué importa tener dos contadores

Un único contador dejaría un margen de maniobra: si solo hubiera NumeroAsiento por ejercicio, teóricamente se podría borrar el libro de un año y renumerar desde cero. Con CadenaSeq cruzando ejercicios, eso es imposible: el primer asiento del ejercicio nuevo referencia el hash del último del año anterior, y CadenaSeq continúa. Alterar esa continuidad es detectable de inmediato.

---

5. Cómo se sella un asiento: el proceso paso a paso

Cuando el módulo de bodega registra un movimiento —una entrada de mosto, una salida de vino, un trasiego, una merma—, el sellado se produce así:

1. El bodeguero registra el movimiento en su lenguaje. No introduce un «asiento IIEE» directamente; introduce lo que ha pasado en la bodega (quién, qué producto, cuántos litros, fecha). El módulo deriva el apunte IIEE correspondiente.

1. El servidor asigna los contadores. El NumeroAsiento (dentro del establecimiento y ejercicio) y el CadenaSeq (posición global acumulada) los asigna el servidor en el momento del registro, no el cliente. Esto es crítico: si el registro llega dos veces por un problema de red, el servidor detecta el clientOpId duplicado y no crea un segundo asiento, evitando así dobles apuntes. Los reintentos no duplican.

1. Se construye la cadena canónica. Los campos del asiento —en el orden fijo descrito en el apartado anterior— se concatenan en formato campo=valor&campo=valor&..., y al final se añade HashAnterior con la huella del asiento previo.

1. SHA-256 produce la huella. La función SHA-256 sobre la cadena canónica da un hash hexadecimal de 64 caracteres en mayúsculas. Ese es el sello definitivo del asiento.

1. Ambas representaciones se persisten. Se guardan tanto la cadena canónica textual como el hash resultante. Esto permite dos vías de verificación independientes: comprobar que la cadena persistida coincide con la reconstruida desde los campos, y comprobar que el hash persistido coincide con el SHA-256 de la cadena persistida.

El resultado es un asiento que ya no puede cambiarse: cualquier modificación de cualquiera de sus campos produciría un hash diferente, incompatible con el que guarda el asiento siguiente.

---

6. La reverificación: cómo se detecta el primer asiento roto

La utilidad de la cadena de hash no es solo preventiva (hacer que la alteración sea imposible sin dejar rastro); también es activa: el sistema puede verificar en cualquier momento si la cadena está íntegra, y si no lo está, señala exactamente dónde empezó el problema.

El proceso de reverificación recorre la cadena del establecimiento en orden de CadenaSeq y comprueba, para cada asiento:

Si cualquiera de estas comprobaciones falla, la reverificación se detiene y devuelve el índice del primer asiento roto y el motivo exacto. Esto permite al auditor saber, sin ambigüedad, en qué punto se perdió la integridad: no un genérico «hay un problema en la cadena», sino la precisión de que «el asiento número 47 tiene la cadena persistida distinta de la reconstruida desde sus campos».

Esta capacidad de diagnóstico preciso es especialmente valiosa en auditorías, inspecciones o procesos de migración de datos: si la cadena está íntegra después de importar o mover datos, hay certeza técnica de que ningún asiento fue alterado en el proceso.

---

7. Anulación sin borrado: el único camino para corregir

Una pregunta frecuente del bodeguero que se enfrenta por primera vez a SILICIE: «¿Y si me equivoqué en las unidades de una salida? ¿Cómo lo corrijo?».

La respuesta de la norma (Orden HAC/998/2019) es que no se corrige el asiento original: se crea un asiento de anulación que lo deja sin efecto, y si el movimiento correcto debe quedar registrado, se crea un segundo asiento nuevo con los datos correctos.

El asiento de anulación tiene un campo específico, AnulaAsientoId, que referencia al identificador del asiento que anula. Ese campo también entra en la cadena canónica, de modo que la anulación queda encadenada y es igualmente inalterable.

¿Por qué no se puede borrar el asiento original?

Técnicamente, porque el siguiente asiento de la cadena tiene en su HashAnterior la huella del asiento que se querría borrar. Si el asiento original desapareciera, la cadena quedaría rota en ese punto y la reverificación lo detectaría inmediatamente.

Normativamente, porque la inalterabilidad es el requisito que da valor probatorio al libro SILICIE. Un libro del que se pueden borrar apuntes no es un libro en el que la AEAT pueda confiar.

Desde el punto de vista práctico, el resultado es que el historial del establecimiento es siempre completo y auditable:

• Asiento original de salida: 3.000 litros de vino blanco, fecha X.
• Asiento de anulación referenciando al anterior.
• Asiento nuevo de salida con los datos correctos: 2.800 litros, misma fecha.

El auditor ve los tres apuntes. Puede rastrear cuándo se detectó el error, quién lo anuló y qué dato quedó finalmente registrado. No hay huecos ni borrones.

---

8. La misma primitiva que Verifactu y los fichajes: por qué importa

Un dato que suele sorprender al asesor que trabaja con varios módulos del sistema: SILICIE, Verifactu/RRSIF y los registros de jornada con cadena encadenada comparten exactamente la misma función criptográfica: SHA-256 hex en mayúsculas, cadena canónica de campos en formato campo=valor separados por &.

Esto no es una coincidencia de diseño aislada; es una decisión deliberada. La AEAT ha extendido este patrón a todos sus instrumentos de control en tiempo real (SILICIE, SII del IVA, Verifactu) porque ofrece tres ventajas que la administración valora:

1. Verificable de forma independiente. Cualquier auditor, inspector o el propio titular puede recalcular los hashes desde los datos en claro y comprobar que coinciden con los sellados. No hace falta acceso al código fuente ni a la base de datos interna.

1. Resistente a manipulaciones parciales. No basta con cambiar el hash de un asiento si se altera el contenido: el siguiente asiento espera el hash del anterior, y esa expectativa no puede cumplirse sin modificar toda la cadena desde el punto alterado.

1. Auditable sin complejidad de infraestructura. SHA-256 es una función estándar, disponible en cualquier entorno, sin dependencias externas. Un inspector con conocimiento básico de criptografía puede verificar una cadena con las herramientas habituales de su sistema operativo.

Para el asesor de bodega que también gestiona la facturación electrónica de ese mismo cliente, esto tiene una implicación práctica: si comprende cómo funciona la inalterabilidad en Verifactu, ya entiende cómo funciona en SILICIE. Son la misma lógica aplicada a un registro diferente.

---

9. Qué significa esto en la práctica para el asesor y el auditor

Pasemos de la teoría a las consecuencias concretas del día a día.

Lo que el asesor debe exigir al software de bodega

Antes de adoptar o recomendar un sistema de gestión SILICIE, estas son las preguntas técnicas que conviene hacerle al proveedor:

¿Permite el sistema editar o eliminar asientos ya sellados? Si la respuesta es sí, el sistema no es conforme con el principio de inalterabilidad de la Orden HAC/998/2019. La corrección de errores debe hacerse siempre mediante un asiento de anulación.

¿La numeración de los asientos es correlativa, sin huecos y sin retrocesos? La Orden HAC/998/2019 exige una contabilidad completa y ordenada por establecimiento (CAE). Un sistema que permita saltos o reasignaciones en la numeración puede no ser conforme.

¿Hay un mecanismo para verificar la integridad de la cadena? Un sistema que genere hashes pero no ofrezca una función de reverificación es como una caja fuerte sin llave de comprobación: promete seguridad pero no la puede demostrar.

¿El suministro a la AEAT está diferenciado entre entorno de pruebas y producción? La remisión de asientos a la AEAT sin certificado y sin decisión expresa del titular puede generar consecuencias en la contabilidad real del CAE. El sistema debe funcionar en modo de pruebas (sandbox) por defecto y requerir una configuración explícita para el paso a producción.

Lo que el auditor puede verificar

Dado que la cadena de hash es reversible desde los datos en claro, el auditor puede realizar una verificación independiente sin depender del software de gestión:

1. Exportar la tabla de asientos del establecimiento en orden de CadenaSeq.
2. Para cada asiento, reconstruir la cadena canónica desde sus campos (en el orden exacto del contrato: OrganizationId, EstablecimientoId, Ejercicio, NumeroAsiento... HashAnterior).
3. Calcular SHA-256 y comparar con el hash sellado.
4. Comprobar que el HashAnterior del asiento actual coincide con el hash del anterior.

Si todos los hashes cuadran, hay certeza técnica de que ningún asiento fue alterado desde su sellado. Si alguno no cuadra, el asiento en cuestión fue modificado después de sellarse.

La tabla de movimientos y sus asientos SILICIE

Para que el asesor tenga una referencia clara de qué tipo de asiento genera cada movimiento de bodega:

El trasiego merece mención especial porque genera confusión: mover vino de un depósito a otro dentro del mismo CAE no es una salida ni una entrada; es una práctica enológica interna. La contabilidad IIEE del establecimiento no varía, aunque sí puede quedar reflejado en los libros de bodega vitivinícola de la comunidad autónoma (que son una capa diferente, bajo autoridad autonómica y no de la AEAT).

---

10. Preguntas frecuentes (FAQ)

¿Por qué no puedo simplemente editar un asiento que registré mal?

Porque la cadena de hash lo haría imposible sin romper la integridad. El asiento siguiente tiene en su HashAnterior la huella del asiento que quieres editar. Si cambias el contenido del original, su hash cambia, y el siguiente ya no lo reconoce. La reverificación señalaría inmediatamente el asiento modificado. La única vía conforme con la Orden HAC/998/2019 es el asiento de anulación.

¿Qué significa «la cadena se rompe»? ¿Qué consecuencias tiene eso?

Que al ejecutar la reverificación —que el sistema puede hacer en cualquier momento, y que un auditor o inspector también puede hacer de forma independiente—, se detecta una discrepancia: el hash esperado no coincide con el hash encontrado. El resultado es un informe que indica el primer asiento donde se produjo la rotura y el motivo (campo modificado, hash anterior incorrecto, hueco en la numeración, etc.). Esto es, a todos los efectos, evidencia de que la contabilidad fue alterada.

¿El correlativo legal es el mismo en todos los ejercicios?

No. El NumeroAsiento arranca en 1 cada año natural (ejercicio) y no se continúa desde el año anterior. Sin embargo, el CadenaSeq (posición global en cadena) sí continúa de forma acumulada cruzando ejercicios. Ambos valores entran en el hash, de modo que ni el orden ni la numeración pueden manipularse.

¿La bodega pequeña (≤ 100.000 L/año) también tiene que usar cadena de hash?

Las bodegas que se acogen a la excepción del pequeño elaborador no están obligadas a SILICIE y, por tanto, no tienen obligación de cadena de hash electrónica. Llevan libros en papel habilitados por la oficina gestora y presentan el modelo 553. Sin embargo, el principio de inalterabilidad aplica también a los libros en papel: un tachón sin justificar puede generar problemas ante la oficina gestora de la misma forma que lo haría una rotura de cadena digital.

¿Campodato remite los asientos a la AEAT?

El módulo de bodega de Campodato genera la cadena de hash, sella los asientos y produce la declaración (por asiento o mensual agregada), pero remite exclusivamente en modo de pruebas (sandbox) por diseño. El sistema tiene un guard que impide cualquier comunicación con producción AEAT mientras no haya certificado y decisión expresa del titular de la bodega. Esto se refuerza con una restricción a nivel de base de datos que bloquea cualquier registro de remisión fuera de entorno de pruebas. El paso a producción requiere una configuración explícita y deliberada, no ocurre por accidente.

¿Por qué SHA-256 y no otro algoritmo?

SHA-256 es el algoritmo de hash recomendado por el NIST (Instituto Nacional de Estándares y Tecnología de Estados Unidos), está ampliamente auditado, es resistente a colisiones conocidas y produce una huella de longitud fija de 256 bits (64 caracteres hexadecimales). La AEAT lo adoptó para Verifactu/RRSIF (RD 1007/2023) y el mismo estándar se aplica en SILICIE. El uso de un único algoritmo en todos estos sistemas facilita la verificación independiente por parte de auditores e inspectores.

---

Conclusión y CTA

La cadena de hash no es un detalle técnico irrelevante para la bodega: es la garantía concreta de que el libro SILICIE tiene valor probatorio ante la AEAT. Sin ella, la inalterabilidad sería una promesa; con ella, es una propiedad verificable matemáticamente.

Para el asesor o auditor exigente, los puntos clave son tres. Primero, el correlativo legal y la posición en cadena entran ambos en el hash de cada asiento, de modo que ni el número ni el orden pueden retroceder sin dejar rastro. Segundo, la reverificación detecta si hay un problema y, de paso, señala exactamente qué asiento fue el primero en fallar y cuál fue el motivo. Tercero, la anulación es siempre un asiento nuevo que referencia al original; el borrado directo no existe en un sistema conforme.

Si gestionas bodegas y quieres entender cómo funciona esto en la práctica, puedes explorar el módulo de bodega de Campodato. Para el contexto normativo completo de qué bodegas están obligadas a SILICIE y qué umbral separa el régimen electrónico del papel más modelo 553, consulta qué es SILICIE y qué bodegas están obligadas.

---

Fuentes oficiales

• BOE — Ley 38/1992, de Impuestos Especiales
• BOE — Orden HAC/998/2019 (SILICIE)
• BOE — Orden HAC/566/2020 (modifica la Orden HAC/998/2019)
• AEAT — SILICIE: información y especificación técnica
• BOE — RD 1007/2023 (Reglamento de sistemas informáticos de facturación, Verifactu/RRSIF)

---

Artículos relacionados en Campodato:

• Qué es SILICIE y qué bodegas están obligadas (guía 2026)
• SILICIE o modelo 553: qué le toca a tu bodega según el umbral
• Software SILICIE para bodega: el libro de existencias que se cuadra solo
• Fichaje inalterable: por qué la Inspección ya no se fía del Excel

---

Artículo elaborado por el equipo de Campodato (Summum Marketing). No sustituye al asesoramiento fiscal. Verifica tu situación con la oficina gestora de Impuestos Especiales o con tu asesoría. Última revisión: junio de 2026. La normativa de Impuestos Especiales puede actualizarse; consulta siempre el BOE y la AEAT para la versión vigente.

---

Infografía sugerida: diagrama de flujo que muestre la cadena de tres asientos encadenados (entrada de mosto → trasiego → salida de vino), con las flechas de HashAnterior entre ellos y un recuadro que muestre los campos que entran en la huella de cada uno. Etiquetas: NumeroAsiento, CadenaSeq, SHA-256, HashAnterior. Útil para publicación en blog y para material de formación para asesores.