Qué es el registro de eventos y a quién obliga
El registro de eventos es obligatorio para los sistemas de emisión de facturas no verificables; un SIF VERI*FACTU no tiene que generarlo. Su función es dejar rastro automático de determinadas interacciones, operaciones y sucesos relevantes que ocurren durante el uso del programa. Cada anotación debe poder consultarse desde el propio sistema. No es un historial escrito a mano por el usuario ni una lista libre de mensajes técnicos. Es un conjunto reglado de registros que permite revisar después qué sucedió y detectar posibles alteraciones. La AEAT lo explica en su FAQ específica.
La diferencia entre modalidades importa. VERIFACTU remite los registros de facturación a la Agencia Tributaria de forma continuada. En un sistema no verificable esa remisión inmediata no existe, de modo que el control queda apoyado en medidas locales adicionales: firma electrónica, conservación, comprobación y registro de eventos. Por eso «NO VERIFACTU» no significa ausencia de supervisión. En este punto ocurre justo lo contrario: el sistema conserva más evidencia bajo la responsabilidad del usuario y del productor.
El artículo se limita a esa evidencia de eventos. Para una comparación completa entre las dos modalidades está la guía sobre VERIFACTU frente a NO VERIFACTU. Tampoco aborda cómo emitir una factura concreta, cómo rectificarla o cómo calcular su huella. Esa frontera evita mezclar el diario de control del sistema con los registros de facturación de alta y anulación.
Los nueve eventos mínimos y el resumen periódico
La AEAT enumera nueve tipos mínimos. El primero registra el inicio del funcionamiento como sistema no VERI*FACTU y el segundo, su finalización. Estos dos hitos delimitan cuándo opera el programa en esa modalidad. No deben confundirse con abrir o cerrar una sesión de usuario: lo relevante es el comienzo o fin del funcionamiento del sistema conforme a la modalidad.
El tercer evento es el lanzamiento del proceso que busca anomalías en los registros de facturación. El cuarto deja constancia de las anomalías detectadas en su integridad, inalterabilidad o trazabilidad. La separación es útil: una cosa es demostrar que el control se ejecutó y otra registrar su resultado. Un informe que solo diga «sin incidencias» pero no permita acreditar cuándo se lanzó el proceso deja una pregunta sin responder.
Los eventos quinto y sexto repiten esa lógica sobre el propio registro de eventos. Se anota el lanzamiento del control de anomalías y, por separado, la detección de problemas de integridad, inalterabilidad o trazabilidad en esos registros. El mecanismo de vigilancia queda así dentro de la evidencia que debe vigilar. Esto obliga al proveedor a tratar con cuidado los fallos del control: silenciar un error o sustituir una anotación deterioraría precisamente el rastro que la norma busca conservar.
El séptimo evento se genera al restaurar una copia de seguridad cuando la copia se gestiona desde el propio SIF. Una restauración puede devolver datos a un estado anterior; por eso debe quedar visible. La empresa debería poder relacionar la anotación con el procedimiento interno aplicado, la persona autorizada y la comprobación posterior, aunque esos campos organizativos no sustituyen el formato reglamentario.
Los eventos octavo y noveno corresponden a exportaciones: una de registros de facturación generados durante un periodo y otra de registros de evento del periodo. Exportar no es simplemente descargar una hoja de cálculo de consulta. El proceso reglamentario debe preservar estructura, legibilidad y posibilidad de verificación. Si el proveedor llama «exportar» a un PDF parcial o a una pantalla sin los datos exigidos, conviene pedir una demostración con la versión que se contratará.
Además existe el registro resumen. La AEAT enumera nueve tipos mínimos de evento y añade un registro resumen que se graba cada seis horas operativas y antes de cerrar o apagar el SIF. El resumen cubre lo sucedido desde el anterior o, cuando todavía no se ha generado ninguno, desde el inicio del funcionamiento sujeto al Reglamento. El fabricante puede añadir voluntariamente otros eventos que considere útiles, pero esa ampliación no elimina los obligatorios. La lista y la periodicidad constan en la FAQ de eventos.
Cómo interpretar las seis horas
El periodo no son seis horas de reloj desde cualquier evento: cuenta cada seis horas en las que el SIF haya estado operativo y disponible, y también exige un resumen antes de su cierre o apagado. Un sistema utilizado dos horas al día no debería interpretarse como si necesitara cuatro resúmenes mientras permanece apagado. Lo que debe acreditarse es el tiempo de operación y disponibilidad que activa el hito.
Esta redacción plantea preguntas prácticas que merecen una respuesta del proveedor. ¿Cómo acumula el sistema el tiempo operativo después de una suspensión? ¿Qué ocurre ante un cierre forzado, una caída de alimentación o un proceso terminado por el sistema operativo? ¿El arranque siguiente detecta que faltó el resumen previo al cierre? La norma técnica, no una explicación comercial, debe dirigir la implementación. La prueba sirve para comprobar el resultado observable.
El resumen tampoco sustituye cada evento individual. Es una anotación adicional del periodo. La aplicación debe mantener los registros que describen una restauración, una exportación o una anomalía aunque el resumen refleje que se produjeron eventos. Borrar los detalles y conservar solo un recuento impediría reconstruir la secuencia.
Para auditar la periodicidad se puede preparar una sesión controlada. Se registra la hora de arranque, se mantiene el sistema disponible, se identifica el resumen producido y después se ejecuta un cierre normal. La evidencia debería permitir distinguir el resumen periódico del generado antes de apagar. La prueba debe repetirse tras una interrupción inesperada, sin manipular datos reales ni provocar daños en producción.
Firma electrónica de los registros
Todos los registros de evento generados por un sistema no verificable deben firmarse electrónicamente. La obligación también alcanza a los registros de facturación de alta y anulación. La FAQ de firma de la AEAT identifica XAdES Enveloped Signature como el tipo de firma aplicable y remite a las especificaciones y ejemplos técnicos.
Firmar no equivale a mostrar un icono verde en la interfaz. La firma debe permitir comprobar después que el contenido corresponde a lo firmado y verificar su autoría. La AEAT indica que el sistema debe ofrecer una comprobación rápida, fácil e intuitiva de las firmas de los registros que estén a su alcance. Esa comprobación se realiza, en principio, a petición del usuario; no tiene que ejecutarse automáticamente con una periodicidad inventada.
Una revisión sensata pide ver el registro, la firma y el resultado de validación. También comprueba qué sucede cuando el contenido se altera en un entorno de ensayo: la verificación debe fallar de forma visible. Hay que saber qué certificado utiliza la solución, cómo se renueva, quién atiende una caducidad y qué pasa con las firmas históricas al cambiar de proveedor. Son preguntas operativas, no una ampliación de la norma.
La firma de un evento no prueba por sí sola que el evento sea completo o que el sistema haya detectado todo lo que debía. Acredita propiedades del registro firmado. Por eso la auditoría combina tres planos: que se genere el evento correcto, que sus datos sean los exigidos y que la firma pueda verificarse. Centrarse solo en el certificado deja fuera la mitad del problema.
Integridad, trazabilidad y consulta
Los eventos deben garantizar integridad, inalterabilidad, trazabilidad, conservación, accesibilidad y legibilidad de forma análoga a los registros de facturación. La AEAT detalla estas características en la FAQ de eventos. Es una exigencia acumulativa. Un archivo legible que pueda editarse sin dejar rastro no cumple la finalidad; un bloque criptográfico íntegro que nadie pueda recuperar o interpretar tampoco resuelve accesibilidad y legibilidad.
La consulta desde el SIF debe ser una capacidad real. Conviene probar filtros por periodo, tipo de evento y obligado, y comprobar que el resultado conserva identificadores y orden temporal. La interfaz puede facilitar el trabajo, pero la evidencia no debe depender de capturas de pantalla. Ante un requerimiento habrá que recuperar registros estructurados, no reconstruirlos a partir de imágenes.
Cuando un mismo SIF gestiona varios obligados a expedir factura, debe llevar los eventos de cada obligado de manera independiente. La AEAT lo expresa como si fueran SIF distintos: habrá tantos registros como obligados. Esta separación evita que una exportación, restauración o anomalía de una entidad se mezcle con la trazabilidad de otra. En una gestoría, un grupo empresarial o una plataforma multiempresa, la prueba debe incluir al menos dos obligados y confirmar que los permisos tampoco cruzan información.
La independencia por obligado no significa que deban instalarse necesariamente programas separados. Significa que la identificación, las cadenas y la recuperación de eventos deben mantener la frontera. El proveedor debe explicar cómo se comportan los procesos comunes, por ejemplo una copia de seguridad de toda la plataforma, sin perder la atribución que exige cada registro.
Conservación, exportación y cambio de proveedor
El plazo y la responsabilidad de conservación de los eventos coinciden con los aplicables a los registros de facturación del mismo periodo. Así lo aclara la AEAT para los registros de evento. La respuesta oficial no fija un número aislado de años para aplicarlo sin contexto: remite a las reglas correspondientes de conservación. Por eso no conviene convertir esta equivalencia en un plazo universal sin revisar las obligaciones tributarias y mercantiles del caso.
La conservación puede organizarse dentro del sistema o mediante archivos externos cuando el procedimiento lo permita, pero siempre debe mantener accesibilidad y legibilidad. La FAQ de conservación de la AEAT admite almacenamiento remoto para registros de facturación si se cumplen los requisitos aplicables. Para eventos, la regla de conservación análoga exige que el diseño no rompa sus firmas, relación y consulta.
El cambio de proveedor es una prueba especialmente reveladora. Antes de contratar, la empresa debería saber qué recibe al terminar el servicio, en qué formato, con qué firmas y qué herramienta permite comprobarlas. También necesita conocer si podrá responder a un requerimiento cuando ya no tenga una suscripción activa. Una promesa genérica de «descarga de datos» no responde estas preguntas.
Las copias de seguridad merecen doble atención. Restaurar una copia gestionada desde el SIF genera un evento, y la propia evidencia debe sobrevivir a la recuperación sin crear una historia falsa. En un ensayo puede compararse el estado anterior y posterior, comprobar el evento de restauración y verificar que las cadenas siguen siendo interpretables. La prueba no debe improvisarse en producción.
Cuándo se envían a la AEAT
Los registros de evento no se remiten periódicamente a la AEAT, pero deben enviarse si la Administración los requiere. La respuesta oficial limita la remisión a ese supuesto. Esta es la diferencia entre disponibilidad y envío automático. Elegir NO VERI*FACTU no crea una obligación de transmitir cada evento al producirse, pero tampoco permite guardarlos en un formato inaccesible esperando no necesitarlos.
Ante un requerimiento importan el alcance y el periodo solicitado. La organización debe localizar los eventos correspondientes, exportarlos por el procedimiento previsto y conservar la evidencia de lo entregado. El artículo no anticipa el canal ni el formato de un requerimiento concreto; mandan la notificación, la normativa y las especificaciones vigentes.
Prepararse no requiere inventar envíos de prueba a la AEAT. Requiere demostrar internamente que los registros se recuperan completos y verificables. Un simulacro puede fijar un intervalo, exportar los eventos, contar los tipos presentes, validar firmas y documentar quién aprobó el resultado. Si el proveedor necesita intervenir cada vez, debe quedar claro el plazo de soporte y la responsabilidad contractual.
Matriz de controles para aceptar el sistema
La primera comprobación es de cobertura. Hay que obtener evidencia de los nueve eventos mínimos y del resumen, no solo una lista en un folleto. Para cada uno se anota qué acción lo provoca, qué datos produce y dónde se consulta. Los eventos voluntarios pueden valorarse después; no compensan la ausencia de uno obligatorio.
La segunda es temporal. Se comprueba el resumen tras seis horas operativas y antes del cierre, además del comportamiento ante un apagado anormal. El objetivo no es medir rendimiento, sino confirmar que la aplicación no deja huecos silenciosos en el periodo.
La tercera es criptográfica. Se valida la firma de varios registros, incluidos un resumen, una exportación y una restauración. Se prueba el mensaje que recibe el usuario cuando la firma no puede verificarse. También se revisan renovación de certificados, sellado histórico y documentación técnica de la versión.
La cuarta es de recuperación. Se exporta un periodo, se abre fuera del flujo habitual y se comprueba su legibilidad. Después se repite por cada obligado cuando el SIF es multiempresa. El resultado debe conservar la atribución y no mezclar cadenas.
La quinta es operativa. Se asignan responsables para revisar anomalías, custodiar exportaciones y atender requerimientos. El software puede automatizar registros, pero no decide quién investiga una detección ni quién acredita que se resolvió. Un control sin propietario acaba siendo una alarma ignorada.
Una prueba útil recorre el ciclo completo: provocar un evento controlado, localizarlo, comprobar su firma, exportarlo y verificar que sigue siendo legible. Es una comprobación práctica derivada de las exigencias de consulta, firma y conservación descritas por la AEAT. Conviene guardar el resultado con la versión del producto, la fecha, el entorno y las incidencias encontradas. Esa carpeta no reemplaza el registro reglamentario; demuestra que la empresa verificó su capacidad operativa.
Señales de una implantación incompleta
Hay una señal clara cuando el proveedor no distingue registro de eventos de registro de facturación. También preocupa que presente el log técnico del servidor como respuesta automática, sin enseñar estructura, firma ni consulta. Un log puede ayudar al soporte, pero no adquiere por llamarse así las garantías del registro reglamentario.
Otra señal es afirmar que los eventos se mandan continuamente a Hacienda. Esa descripción corresponde a una mezcla incorrecta de modalidades. En NO VERI*FACTU los eventos quedan disponibles y se remiten ante requerimiento. También es inexacto afirmar que basta con un resumen diario: la referencia es cada seis horas operativas y antes del cierre o apagado.
La tercera señal es depender de un administrador del proveedor para cualquier consulta o exportación. La AEAT dice que los datos deben poder consultarse desde el SIF. El soporte puede participar, pero la empresa necesita una vía documentada y probada, especialmente si un requerimiento tiene plazo.
La cuarta es no separar obligados. En un entorno multiempresa, una pantalla común puede ser cómoda, pero la trazabilidad debe mantenerse independiente para cada obligado a expedir factura. Si una exportación incluye datos de terceros sin una separación clara, existe además un problema práctico de confidencialidad.
Si la empresa no puede operar y probar firma, conservación, exportación y recuperación de eventos, la modalidad no verificable exige controles que aún no tiene resueltos. Es un criterio de preparación inferido de los requisitos del artículo 8.3 del RRSIF. Eso no convierte automáticamente VERI*FACTU en la opción correcta para todos. Sí indica que la decisión debe incorporar coste de operación, soporte, continuidad y capacidad de responder, no solo una preferencia sobre el envío inmediato.
Qué pedir al proveedor antes de aprobar la versión
Pide la declaración responsable de la versión y una demostración sobre el producto real. La demostración debería identificar los eventos obligatorios, provocar al menos una restauración o exportación en un entorno seguro, mostrar el resumen y verificar firmas. Anota las diferencias entre lo enseñado y la configuración que se desplegará.
Solicita también el procedimiento de salida. Debe explicar formatos, conservación después de terminar el contrato, herramienta de validación y asistencia ante requerimientos. Si el producto funciona en la nube, aclara cómo se accede cuando hay una incidencia del servicio y cómo se recupera un periodo completo.
Documenta quién controla cada acción sensible. Restaurar copias, exportar registros y cambiar la modalidad no deberían quedar disponibles sin permisos adecuados. Los perfiles y aprobaciones no sustituyen el evento reglamentario, pero reducen errores y permiten investigar lo ocurrido con contexto.
Por último, repite las pruebas después de una actualización relevante. Una declaración responsable corresponde a una versión, y un cambio puede afectar generación, firma o exportación. La revisión no tiene que convertirse en un proyecto interminable: basta un conjunto estable de casos, resultados esperados y evidencias comparables.
Calendario y límites de esta guía
El texto consolidado del Real Decreto 1007/2023 establece, con carácter general, la adaptación antes del 1 de enero de 2027 para los contribuyentes del Impuesto sobre Sociedades incluidos en el artículo 3.1.a) y antes del 1 de julio de 2027 para el resto de obligados del artículo 3.1. Consulta el texto vigente en el BOE. El calendario concreto debe revisarse según el obligado, su ámbito y futuras modificaciones; no se debe extrapolar la fecha general sin esa comprobación.
Este artículo no certifica un producto ni sustituye la Orden HAC/1177/2024, sus anexos técnicos o las pruebas sobre la versión concreta del software. Tampoco determina el plazo de un requerimiento ni ofrece una estrategia de defensa. Si ya existe una notificación, hay que revisar su contenido y vencimiento.
Preguntas frecuentes sobre el registro de eventos
¿Qué eventos debe registrar un SIF no VERI*FACTU?
Como mínimo, el inicio y fin del modo no verificable; el lanzamiento y resultado de controles de anomalías sobre registros de facturación y de evento; la restauración de copias gestionada desde el SIF; las exportaciones de registros de facturación y de evento; y el registro resumen periódico.
¿Cada cuánto se genera el resumen de eventos?
Por cada seis horas en las que el SIF haya estado operativo y disponible. También debe generarse antes de cerrar o apagar el sistema. El periodo cubre desde el resumen anterior o, si todavía no existe, desde el inicio de funcionamiento conforme al Reglamento.
¿Hay que enviar los eventos a la AEAT?
No se remiten de forma periódica ni automática. La AEAT indica que deben enviarse cuando ella los requiera. Por eso el sistema debe conservarlos, permitir su consulta y mantenerlos disponibles en un formato que pueda recuperarse y entregarse.
¿Qué trazabilidad debe conservarse para cada evento del sistema?
Los eventos deben mantener integridad, inalterabilidad, trazabilidad, conservación, accesibilidad y legibilidad de manera análoga a los registros de facturación. Además, el SIF no verificable firma electrónicamente todos los registros de evento que genera.
Para ampliar el contexto puedes consultar el registro de eventos no VERI*FACTU, el hub fiscal-contable y la guía sobre facturación manual sin programa. Si necesitas revisar controles, versión y evidencias con tu operativa real, puedes auditar los eventos del SIF con el servicio fiscal-contable.