El registro de eventos es el cuaderno de bitácora del programa de facturación. Anota lo que le ocurre al propio sistema, no a las facturas: cuándo arranca, cuándo se detiene, si se ha exportado información, si ha detectado una anomalía. Es obligatorio en la modalidad NO VERI*FACTU, porque en ella los registros de facturación no salen de la empresa y la AEAT necesita una garantía adicional de que nadie ha manipulado el sistema.
Por qué solo en NO VERI*FACTU
En la modalidad VERIFACTU, cada registro llega a la AEAT pocos segundos después de emitirse la factura. Una manipulación posterior no cambiaría lo que ya consta en la sede. En NO VERIFACTU, en cambio, la única prueba está en el sistema de la empresa. Por eso la norma pide dos compensaciones: firma electrónica de cada registro y un registro de eventos protegido. Tienes la comparativa completa en modalidad VERIFACTU o NO VERIFACTU.
Qué tipo de eventos se anotan
La lista exacta la define la especificación técnica de la AEAT. Para entenderla, sirve agruparlos así:
| Grupo | Ejemplos |
|---|---|
| Funcionamiento | inicio y fin del programa en modo facturación, reanudación tras un corte |
| Integridad | detección de un fallo en la cadena de huellas o en una firma |
| Exportación y restauración | exportación de registros, restauración de copias de seguridad |
| Anomalías | intentos de acceso no autorizados, errores de reloj, imposibilidad de firmar |
| Resúmenes | eventos periódicos que resumen la actividad del sistema |
Cada evento lleva fecha y hora, identificación del sistema y su propia huella, encadenada con el evento anterior. Igual que con las facturas, borrar un evento rompe la cadena.
Lo que el usuario debe hacer
El programa genera los eventos solo; la empresa tiene que conservarlos y poder entregarlos:
- Incluye el registro de eventos en las copias de seguridad, con la misma periodicidad que los registros de facturación.
- Conserva los eventos durante el mismo plazo que los registros de facturación (revisa la guía de conservación de registros en VERI*FACTU).
- Asegúrate de que, si la AEAT lo pide, puedes exportarlos en un formato legible.
- No restaures copias antiguas “para arreglar algo” sin documentarlo: la restauración queda registrada y tendrás que explicarla.
Una revisión trimestral útil
Aunque no es obligatorio revisar el registro, mirarlo de vez en cuando detecta problemas antes que un requerimiento. Una revisión de diez minutos al trimestre:
- Exporta los eventos del periodo.
- Filtra los de integridad y anomalías. En un sistema sano deberían ser cero o muy pocos.
- Para cada anomalía, anota la causa (corte de luz, cambio de servidor, error de reloj) y la persona que lo comprobó.
- Comprueba que hay eventos de actividad en todos los días en que se facturó. Un hueco de una semana en plena temporada sugiere que alguien facturó con otra herramienta.
Ejemplo
Una tienda con un TPV en NO VERI*FACTU sufre un corte eléctrico un sábado. Al reiniciar, el sistema registra un evento de reanudación y otro de comprobación de integridad correcto. En la revisión trimestral, la responsable ve ambos eventos, los relaciona con la incidencia del sábado y lo anota en el informe. Si el registro mostrara además un fallo de cadena, habría que contactar con el proveedor y conservar toda la documentación del incidente.
Preguntas para tu proveedor
- ¿Dónde se guardan los eventos y cómo se incluyen en las copias?
- ¿Cómo los exporto si me los pide la AEAT o un auditor?
- ¿Qué hace el programa si no puede firmar un evento?
La respuesta debería encajar con lo que el productor declara en su declaración responsable.