1. ¿Qué es el Registro de Eventos (ICALTI)?

El Reglamento VeriFactu establece que no es suficiente garantizar que una factura emitida no se borre. Para asegurar que el software no funciona como una herramienta de doble contabilidad o software de supresión de ventas, es imperativo registrar la actividad del propio sistema.

Aquí entra el concepto de ICALTI (Identificador de Cada Actuación en Libro de Trazabilidad Inalterable). Un registro de eventos es un archivo de bitácora (log) altamente securizado, donde el Sistema Informático de Facturación (SIF) deja constancia de toda interacción técnica o de configuración que pueda comprometer la integridad fiscal.

El fin del software de doble uso

Cualquier intento de deshabilitar temporalmente la emisión oficial, purgar bases de datos o alterar el reloj del servidor, quedará registrado en el ICALTI. Este componente es la barrera tecnológica principal contra el fraude.

2. Tipos de eventos que deben registrarse

La normativa detalla exhaustivamente qué hitos deben formar parte de este log inalterable. Los eventos operativos y del ciclo de vida del propio SIF incluyen:

Tabla de eventos mínimos auditables en el registro VeriFactu
Categoría Evento Registrado Descripción y Finalidad
Sistema Inicio / Arranque del SIF Registro de cada vez que el servicio de facturación se activa (muy útil en sistemas TPV).
Sistema Cierre / Parada del SIF Fin del funcionamiento del servicio, previniendo apagados maliciosos durante jornadas.
Facturación Alta de Registro de Facturación Confirmación de generación exitosa de un registro de factura (alta).
Facturación Anulación de Registro Registrar quién y cuándo anuló una factura emitida (registro de anulación).
Facturación Factura Rectificativa Sección que aborda la sustitución o rectificación por diferencias de una factura previa.
Seguridad Cambio de Configuración Alteraciones en impuestos, series de facturación, permisos de usuarios o perfiles.
Datos Exportación o Copia (Backup) Identificación de volcados de base de datos para evitar la extracción ilícita.
Software Actualización de Versión Rastreo de instalación de parches o updates del propio sistema de facturación.
Comunicación Interacción con la AEAT Fallos de conectividad, reintentos de envío y lotes remitidos con éxito o error.

3. Estructura XML del registro de eventos

El formato de los registros debe seguir un esquema XML estandarizado que permita su lectura automatizada por parte de los inspectores de la AEAT. Cada bloque debe asegurar no repudiabilidad.

A continuación se muestra un ejemplo esquemático simplificado de la estructura de un evento:


<?xml version="1.0" encoding="UTF-8"?>
<sf:RegistroEvento xmlns:sf="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/Evento.xsd">
  <sf:IDVersionSistema>v2.1.0-2026</sf:IDVersionSistema>
  <sf:TipoEvento>A0</sf:TipoEvento> <!-- Código estandarizado de evento -->
  <sf:FechaHoraEvento>2027-01-15T10:30:00+01:00</sf:FechaHoraEvento>
  <sf:DescripcionEvento>Alta de factura FA-2027-0015</sf:DescripcionEvento>
  <sf:IdentificacionUsuario>admin@empresa.es</sf:IdentificacionUsuario>
  <sf:HuellaEvento>e4d909c290d0fb1ca068ffaddf22cbd0a1b2c3d4e5f6...</sf:HuellaEvento>
  <sf:HashAnterior>a1b2c3d4e5f6e4d909c290d0fb1ca068ffaddf22...</sf:HashAnterior>
</sf:RegistroEvento>

Obsérvese que la etiqueta <sf:HashAnterior> asegura el encadenamiento de este evento con el inmediatamente anterior del mismo sistema, formando una cadena irrompible.

4. Inalterabilidad del registro: Técnicas exigidas

La inalterabilidad es el principio rector del Reglamento. El registro de eventos no puede ser modificado, eliminado ni truncado bajo ninguna circunstancia. Para asegurar esta premisa, la norma técnica exige:

  • Encadenamiento criptográfico: Cada nuevo evento incluye en su cálculo de hash (SHA-256) la huella del evento anterior, similar a una arquitectura blockchain.
  • Almacenamiento protegido: El fichero o base de datos que aloje este log no puede ser accesible para edición por parte del administrador del sistema.
  • Integridad continua: Si la cadena de hashes se rompe, el software debe detectar automáticamente el fallo, emitir un evento de alarma y bloquear las operaciones que puedan comprometer más datos.

5. Periodo de conservación de la información

Según la Ley General Tributaria (LGT), toda información con trascendencia tributaria debe conservarse durante el periodo de prescripción, que de manera general es de 4 años, contados desde el día siguiente a aquel en que finalice el plazo para presentar la correspondiente declaración.

El software debe garantizar que los eventos ICALTI y los registros de facturación sean recuperables durante todo este periodo. Esto implica que las plataformas en la nube (SaaS) y los servidores on-premise deben prever planes de contingencia, redundancia de backups (cuyas extracciones generarán, a su vez, nuevos eventos) y formatos de exportación estandarizados de todo este histórico.

6. Registro de Facturación vs Registro de Eventos

Es muy común confundir estos dos pilares de VeriFactu. Aunque ambos registros deben estar encadenados y securizados, su finalidad es diametralmente opuesta:

Diferencias clave entre ambos registros obligatorios
Característica Registro de Facturación Registro de Eventos (ICALTI)
Contenido Datos económicos y fiscales (Base imponible, cuotas, NIFs, tipo de factura). Metadatos operativos, auditoría de seguridad y acciones de sistema.
Frecuencia Por cada factura (alta) o rectificación/anulación. Continuo. Inicios de sesión, copias de seguridad, errores de red.
Envío a la AEAT Se envía automáticamente en tiempo real (si es sistema "VeriFactu"). Se almacena localmente y solo se envía bajo inspección o requerimiento.
Visibilidad Cliente Sus datos se reflejan en la factura en PDF/papel y en el código QR. Totalmente invisible para el cliente y el usuario estándar.

7. Inspección por parte de la AEAT

La Agencia Tributaria tiene potestad para realizar inspecciones in situ o requerimientos telemáticos. En un sistema homologado "VeriFactu" que remite los registros de facturación de forma continuada (y por ende goza de presunción de veracidad), el registro de eventos actuará como la caja negra de un avión en caso de sospecha.

¿Qué dispara una inspección al registro de eventos?

  • Discrepancias crónicas entre los hashes enviados y los esperados.
  • Huecos detectados en la numeración de las series de facturación.
  • Recepción de demasiados "eventos de error de envío" prolongados en el tiempo.
  • Denuncias de terceros mediante el escaneo de Códigos QR de facturas que no constan en las bases de datos de Hacienda.

Ante un requerimiento, el sistema debe poseer un módulo de exportación segura que empaquete todo el histórico de eventos en el formato XML dictado por la normativa.

8. Implicaciones para el desarrollador de software (ISV)

Para las empresas desarrolladoras y los departamentos de IT internos, el sistema ICALTI supone el mayor reto arquitectónico de la Ley Antifraude. Implica rediseñar el core transaccional para:

  • Cálculo criptográfico sincrónico: Insertar eventos en base de datos requiere bloquear hilos (locks) para asegurar que el cálculo del hash toma el evento inmediatamente anterior exacto, sin condiciones de carrera (race conditions) en entornos concurrentes.
  • Tolerancia a fallos: Si la base de datos se corrompe parcialmente, se necesita un proceso de reconstrucción que pueda validar matemáticamente dónde ocurrió la brecha de integridad.
  • Declaración responsable: El fabricante del software firmará una declaración asumiendo la responsabilidad técnica de que este registro no puede ser manipulado ni siquiera por un administrador de base de datos con acceso directo al servidor SQL/NoSQL (por ejemplo, cifrando a nivel de aplicación).