Append-only y firma JWS: por que tu cuaderno digital es prueba ante la administracion

Un inspector de fitosanitarios se planta en tu explotacion. Quiere ver los tratamientos del ultimo trimestre: fechas exactas, productos, dosis, equipos, aplicadores. Si llevas ese registro en un Excel, el inspector puede —con razon— preguntarse si lo has modificado esta manana. Si lo llevas en un cuaderno digital bien construido, la pregunta no tiene sentido: el sistema hace imposible borrar o alterar lo que ya esta escrito, y cada envio a la Administracion va firmado con una huella matematica que cualquiera puede comprobar.

Esta leccion explica como funciona esa garantia. No hace falta saber programar para entenderla. Si quieres protegerte en una inspeccion, basta con comprender el principio.

---

Modulo 1: el problema de fondo — por que un registro editable no es prueba

Imaginemos que el ano pasado aplicaste un fungicida fuera de plazo de seguridad. Despues lo sabes, y antes de la inspeccion corriges la fecha en tu hoja de calculo. El fichero guarda la fecha de la ultima edicion, pero si sabes hacerlo puedes manipular tambien esa marca. El inspector no tiene forma de saber si lo que ve es lo que paso de verdad.

Ese es exactamente el escenario que la normativa quiere evitar. El articulo 29.2.j de la Ley 11/2021 (que modifico la Ley General Tributaria) lo dice con claridad para los sistemas de facturacion: los registros deben garantizar "integridad, conservacion, accesibilidad, legibilidad, trazabilidad e inalterabilidad" y prohiben el "software de doble uso", es decir, aquel que permite llevar dos versiones de los datos. La misma filosofia impregna el RD 1054/2022 que crea el SIEX y el cuaderno digital de explotacion: los asientos son cronologicos, acumulativos y no se borran.

El concepto tecnico que hace realidad esa exigencia se llama append-only: solo se puede anadir, nunca editar ni borrar.

---

Modulo 2: que significa exactamente append-only

2.1 La logica de los asientos contables

Un cuaderno append-only funciona como un libro contable tradicional: si te equivocas en un apunte, no lo tachas —eso invalida la pagina—, sino que escribes un asiento de correccion en la siguiente linea, con fecha y motivo. El asiento erroneo sigue ahi, visible, como parte del historial.

En un sistema digital eso se traduce en reglas muy concretas a nivel de base de datos:

• La tabla de registros del cuaderno (tratamientos, fertilizaciones, riegos, vendimia, fichajes...) no admite operaciones UPDATE ni DELETE por parte del usuario.
• Si un dato esta mal, se introduce un asiento de rectificacion posterior, con su propia fecha y su referencia al asiento original.
• El corrido de asientos nunca tiene huecos en su numeracion: si el asiento 5 existe y el asiento 7 existe, el 6 tiene que estar ahi. Un hueco seria sospechoso.

En Campodato esto no es una politica de usuario que alguien puede saltarse: es una restriccion a nivel de base de datos, verificada por tests automatizados. Cualquier intento de ejecutar un UPDATE o un DELETE sobre los asientos del cuaderno o del libro SILICIE falla con un error de la propia base de datos, aunque quien lo intente tenga contrasena de administrador. El test que lo comprueba es parte del codigo fuente del producto y no se puede desactivar.

2.2 La anulacion como prueba de que el sistema funciona bien

Que no se pueda borrar no significa que no se pueda corregir. Significa que la correccion queda visible.

Si registraste un tratamiento con 3 litros de producto y en realidad fueron 2,5, la correccion correcta es:

1. Un asiento de anulacion del tratamiento original (queda en el historial, marcado como anulado).
2. Un asiento nuevo con el dato correcto.

El inspector puede ver los dos asientos, la fecha de cada uno y, si quiere, verificar que el original se anulo de forma reglamentaria. Es mas informacion, no menos. Y es informacion que tu no puedes haber fabricado retroactivamente, porque el sistema no te lo permite.

---

Modulo 3: la cadena de huellas — como se sella cada asiento para siempre

El principio append-only garantiza que no se borra. Pero alguien podria intentar insertar un registro falso con fecha retroactiva. Para cerrar esa puerta, los sistemas mas robustos —y Campodato es uno de ellos— usan una cadena de huellas inspirada en el patron que la AEAT exige para Verifactu/RRSIF (RD 1007/2023, articulo 12).

3.1 Que es una huella (hash)

Una huella criptografica es un numero muy largo que se calcula a partir del contenido de un documento. Dos documentos identicos producen exactamente la misma huella. Si cambias una sola letra, la huella cambia por completo. El algoritmo estandar que se usa (SHA-256) produce huellas de 64 caracteres hexadecimales.

Ejemplo practico: si el tratamiento del dia 5 de abril tiene la huella a3f7...b2, y ese dato esta almacenado en el asiento siguiente, cualquiera puede recalcular la huella del tratamiento del 5 de abril y comparar. Si no coincide, algo cambio.

3.2 Como se encadenan los asientos

Cada asiento nuevo incluye en su contenido la huella del asiento anterior. Cuando se calcula la huella del asiento nuevo, esa referencia al anterior queda "sellada" dentro. El resultado es una cadena:

`` Asiento 1 → huella_1 Asiento 2 (incluye huella_1) → huella_2 Asiento 3 (incluye huella_2) → huella_3 ... ``

Si alguien intentara modificar el asiento 1 a posteriori, su huella cambiaria. Pero el asiento 2 contiene la huella original del asiento 1, y al recalcular el asiento 2 la diferencia se detectaria. Y la diferencia en el asiento 2 se propagaria al asiento 3. La cadena entera queda rota, y eso es detectable de forma automatica.

En Campodato la funcion verificarCadena lee todos los asientos de un establecimiento o de un registro, recalcula hash a hash y confirma que la cadena es valida. Ese mismo proceso puede ejecutar un inspector con las herramientas adecuadas.

3.3 El correlativo sin huecos

Ademas de la cadena de huellas, cada asiento lleva un numero de orden correlativo que jamas retrocede. Si el asiento 47 existe y el siguiente es el 49, el 48 falta —lo que puede indicar una eliminacion. El correlativo dentro de un ejercicio legal puede reiniciarse al comenzar el ano (como exige la normativa contable), pero la cadena interna de la base de datos no reinicia nunca: el primer asiento del ejercicio 2027 sera el asiento numero 48 de la cadena global del establecimiento, aunque su numero legal sea el 1.

Esto coincide exactamente con lo que exige el RRSIF para los registros de facturacion (articulo 12 del RD 1007/2023) y con el libro de existencias de Impuestos Especiales (SILICIE, regulado por la Orden HAC/1505/2024 y la Ley 38/1992).

---

Modulo 4: la firma JWS de las remisiones al SIEX — el sello ante la Administracion

Tener un cuaderno append-only con cadena de huellas es muy valioso internamente. Pero el momento de maxima exigencia legal es la remision al SIEX: el envio de los datos del cuaderno al sistema de la comunidad autonoma, que a su vez los vuelca al repositorio estatal del MAPA/FEGA.

Aqui entra la firma JWS (JSON Web Signature).

4.1 Que es una firma JWS

Una firma JWS es el equivalente digital de firmar un documento con certificado electronico, pero aplicada al formato JSON que usan los servicios web modernos. El estandar lo define el IETF (RFC 7515).

Cuando Campodato prepara un lote de anotaciones para enviarlo a la autonomia, calcula una representacion canonica del lote —con un orden de campos fijo, para que dos lotes identicos produzcan siempre el mismo resultado— y a continuacion firma ese texto con la clave privada del Sello de Entidad de la empresa de software (en produccion, esa clave vive en un modulo hardware criptografico, el KMS, nunca en texto claro en un servidor).

El resultado es un JWS compacto: una cadena de texto que incluye el lote firmado y la firma. La autonomia puede verificar la firma con la clave publica del Sello de Entidad, que ya conoce porque el software esta dado de alta como desarrollador CUE en esa comunidad. Si la verificacion es correcta, la autonomia sabe con certeza tres cosas:

1. El lote procede del software registrado (autenticidad).
2. El lote no ha sido modificado en transito (integridad).
3. La empresa de software no puede negar haberlo enviado (no repudio).

El algoritmo admitido por el IUWS del FEGA (Anexo VI v3.11.4 del Documento Tecnico SIEX) es ES256 (ECDSA con curva P-256) o RS256 (RSA con SHA-256). Campodato parametriza el algoritmo por comunidad autonoma, ya que cada una puede tener preferencia.

4.2 El hash del lote: una huella que queda en tus registros

Antes de firmar, Campodato calcula el SHA-256 del payload canonico del lote. Ese hash se guarda en la base de datos junto con la remision. Si en el futuro hay una disputa sobre si lo que se envio coincide con lo que figura en el SIEX de la autonomia, tienes el hash: recalculando el lote original puedes demostrar que el contenido es identico.

Ademas, la propia remision queda como una fila append-only en la base de datos: ni el usuario ni el sistema pueden borrarla. Cada reintento en caso de error tecnico crea una nueva fila; la anterior no desaparece.

4.3 Integridad doble: cuaderno real y lote remitido

Campodato implementa una comprobacion adicional: antes de firmar y enviar un lote, el sistema verifica que cada anotacion del lote se corresponde exactamente con una operacion real del cuaderno legal, cotejando tipo, fecha y datos mediante un hash por anotacion. Si alguien intentara enviar a la Administracion un lote que no coincide con lo registrado en el cuaderno —una discrepancia que podria ser senial de manipulacion—, el sistema lo bloquea. El lote maquillado no llega.

---

Modulo 5: SILICIE y el patron Verifactu aplicado a la bodega

Las bodegas tienen una obligacion adicional: el libro de registro de existencias de Impuestos Especiales, conocido como SILICIE. La normativa (articulos 49 y 50 de la Ley 38/1992 y la Orden HAC/1505/2024) exige que ese libro sea completo, exacto y cronologico.

Campodato implementa SILICIE con exactamente los mismos principios que Verifactu aplica a la facturacion:

• Asientos append-only: la base de datos rechaza cualquier UPDATE o DELETE sobre los asientos del libro.
• Cadena de huellas SHA-256: cada asiento incluye la huella del anterior; la cadena es re-verificable en cualquier momento.
• Correlativo sin huecos por ejercicio: los numeros de asiento no saltan. El correlativo legal reinicia en 1 al comienzo de cada ejercicio, pero la cadena interna (el cadenaSeq) nunca retrocede.
• Anulacion por asiento posterior: si un movimiento es incorrecto, se crea un asiento de anulacion que lo referencia y revierte el saldo. El original queda intacto y visible.
• Declaracion verificable: cuando se genera la declaracion periodica, el sistema calcula un lote_hash del conjunto de asientos del periodo. Ese hash permite a Hacienda —o a un auditor— comprobar que la declaracion presentada es coherente con el libro.
• Solo sandbox hasta certificacion: mientras el contribuyente no haya completado el alta legal ante la AEAT, todos los envios van al entorno de pruebas. Un CHECK a nivel de base de datos rechaza cualquier intento de insertar una remision con entorno produccion sin la certificacion previa. Este guard no se puede sortear desde la aplicacion.

---

Modulo 6: por que esto te protege en una inspeccion

Junta todo lo anterior y obtienes una posicion muy diferente ante cualquier organismo de control (CCAA para el cuaderno de campo, Hacienda para SILICIE y Verifactu, la PAC para los ecorregimenes):

Lo que puedes demostrar:

• Que cada anotacion tiene una fecha y hora de creacion que no se puede alterar retroactivamente.
• Que la cadena de asientos no tiene huecos ni modificaciones: el sistema la re-verifica a peticion.
• Que cada remision al SIEX esta firmada digitalmente con el certificado de la empresa de software registrada ante tu comunidad autonoma.
• Que el lote enviado a la Administracion coincide exactamente con lo registrado en el cuaderno: el cotejo hash por anotacion lo garantiza.
• Que las correcciones son transparentes: cualquier modificacion deja rastro en forma de asiento de anulacion con fecha posterior.

Lo que no podras hacer (y eso es una ventaja):

No podras borrar un tratamiento con producto caducado. No podras cambiar una dosis a posteriori. No podras hacer desaparecer un movimiento de bodega que ya fue declarado. Esto puede parecer una restriccion, pero en una inspeccion es exactamente la garantia que necesitas: demuestras que la informacion es la que es, y que no la has tocado.

La diferencia con un Excel:

Un Excel no tiene nada de esto. Cualquier persona con acceso puede editar cualquier celda en cualquier momento, y las marcas de modificacion son opcionales y manipulables. En una inspeccion seria, un Excel no prueba nada por si solo; a lo sumo es un indicio. Un cuaderno con cadena de huellas y firma JWS es un registro con garantias tecnicas equiparables a las que exige la ley para los sistemas de facturacion.

---

Modulo 7: que hacer si hay un error en tus datos

La pregunta mas frecuente cuando se explica el principio append-only es: "si no puedo borrar ni editar, que hago cuando me equivoco?"

La respuesta es siempre la misma: el asiento de rectificacion.

1. Localiza el asiento incorrecto.
2. Crea una rectificacion que lo referencia y que explica el motivo.
3. Si el asiento ya fue incluido en una remision al SIEX, la rectificacion se incluira en el siguiente lote.

Esto es exactamente lo que hace la Hacienda publica con las facturas rectificativas: no se destruye la factura original, se emite una nueva que la corrige. El inspector ve las dos y puede evaluar el historial completo.

Lo que no debes hacer es esperar a la inspeccion para corregir errores. Un asiento de rectificacion creado dos dias despues del error es creible. Uno creado el dia antes de la visita del inspector, sobre un asiento de hace seis meses, levanta preguntas.

---

Preguntas frecuentes

¿La firma JWS del cuaderno equivale a una firma electronica cualificada (eIDAS)?

No necesariamente. La firma JWS que usa Campodato para las remisiones al IUWS utiliza un Certificado de Sello de Entidad que puede ser cualificado o no, dependiendo del prestador y del tipo concreto de certificado. El Documento Tecnico SIEX (Anexo VI v3.11.4 del FEGA) exige un certificado de componente o sello de entidad con NIF en serialNumber y organizationIdentifier formato VATES, compatible con ETSI TS 119 412. Si quieres saber exactamente que tipo de certificado usa tu software, pide la declaracion responsable del productor. Pendiente: validar con la especificacion FEGA la equivalencia exacta con eIDAS Nivel Avanzado o Cualificado en cada CCAA.

¿El SIEX tiene acceso continuo a mis datos?

No. Segun el RD 1054/2022 y el Documento Tecnico SIEX, la Administracion solo accede a tus datos cuando tu (o tu software, con tu autorizacion) hace una remision. El acceso extraordinario en controles oficiales existe pero es la excepcion. La frecuencia de sincronizacion REA→SIEX es trimestral desde 2025.

¿Que pasa si la CCAA rechaza un lote firmado?

La remision queda registrada con estado rechazada en tu cuaderno. No desaparece. Tienes el hash del lote rechazado y el acuse con el motivo. Puedes corregir los datos erroneos mediante asientos de rectificacion y enviar un nuevo lote. El rastro de lo que se intento enviar y cuando queda disponible para cualquier auditoria.

¿Campodato envia mis datos a produccion del SIEX desde el primer dia?

No. Mientras no estes dado de alta como usuario habilitado ante tu comunidad autonoma y el software no tenga el alta como empresa desarrolladora CUE en esa CCAA, todos los envios van al entorno de pruebas (sandbox). El sistema bloquea tecnicamente cualquier envio a produccion sin esa confirmacion previa. Esta proteccion opera a nivel de base de datos, no solo a nivel de interfaz.

---

Conclusion

Un cuaderno digital que merece ese nombre no es una hoja de calculo en la nube. Es un registro con garantias matematicas: no se borra, no se edita silenciosamente, cada asiento esta vinculado al anterior por una huella criptografica que cualquiera puede comprobar, y cada envio a la Administracion lleva la firma digital de la empresa de software registrada ante la autonomia.

Esas garantias no son un adorno tecnologico. Son la diferencia entre presentar a un inspector un papel que podria haber sido modificado esta manana, y presentarle un registro cuya integridad puede verificarse matematicamente en el momento.

Si tu explotacion o tu bodega va a enfrentarse a controles —de la PAC, de fitosanitarios, de Hacienda, de denominaciones de origen—, la pregunta que debes hacerte sobre tu software no es "es facil de usar", sino "puedo demostrar que lo que dice es lo que paso". Solo la combinacion de append-only, cadena de huellas y firma JWS te da esa respuesta.

---

Campodato. Disenado por Summum Marketing.