La firma electrónica de los registros no se aplica igual en las dos modalidades del Reglamento de sistemas informáticos de facturación. Los sistemas de emisión de facturas no verificables deben firmar electrónicamente los registros de facturación de alta y de anulación, además de los registros de evento que generen. La FAQ de la AEAT delimita expresamente los registros afectados.
Los SIF VERI*FACTU no están obligados a realizar la firma electrónica explícita de los registros que remiten. La AEAT explica esa excepción en su apartado sobre firma. La diferencia no autoriza a hablar de un sistema «sin seguridad»: cambia el mecanismo con el que se acredita la generación y remisión del registro.
Esta guía se limita a la firma de registros en España, en el marco del Real Decreto 1007/2023 y de las especificaciones estatales. No sustituye la documentación técnica vigente, no certifica un producto concreto y no resuelve las particularidades de los territorios forales. Tampoco analiza en detalle la declaración responsable del productor, que tiene su propio control.
La pregunta que evita revisar el componente equivocado
Antes de pedir certificados o capturas, confirma cómo opera realmente el sistema. La etiqueta comercial no basta. Un mismo proveedor puede ofrecer configuraciones diferentes y una instalación puede cambiar de modalidad si empieza la remisión sistemática de registros.
La AEAT explica esa diferencia porque la remisión inmediata incluye autenticación mediante certificado electrónico cualificado y medios de transmisión seguros. Ese proceso hace innecesaria la firma electrónica explícita en VERI*FACTU. En el sistema no verificable, los registros permanecen bajo control del obligado y el software incorpora la firma como una medida adicional de autoría, integridad e inalterabilidad.
Una comprobación útil empieza por confirmar la modalidad, continúa con una muestra de altas, anulaciones y eventos y termina verificando la firma desde el propio SIF y guardando el resultado. No empieces preguntando qué certificado comprar. Primero necesitas saber qué registros existen, quién los genera y qué modalidad estaba activa cuando se crearon.
Usa una ficha por instalación con estos datos:
| Dato | Qué debes obtener | Por qué importa |
|---|---|---|
| Identificación del SIF | Producto, versión, instalación y productor | Evita mezclar evidencias de versiones distintas |
| Modalidad activa | VERI*FACTU o no verificable | Determina si existe obligación de firma explícita |
| Fecha del cambio | Inicio efectivo de la modalidad | Separa registros anteriores y posteriores |
| Certificado | Titular, emisor, vigencia y uso | Permite revisar la autoría de la firma |
| Registros | Altas, anulaciones y eventos | Delimita la muestra que debe comprobarse |
| Resultado | Verificación correcta o error documentado | Acredita que la función puede usarse |
Si el proveedor responde solo con un folleto, pide la declaración responsable de la versión, el manual de funcionamiento y una demostración sobre registros reales de prueba. La documentación comercial puede orientar, pero no demuestra el comportamiento de la instalación.
Qué registros se firman en modalidad no verificable
La obligación no se limita al registro asociado a una factura ordinaria. Abarca tres familias que deben mantenerse separadas en la revisión.
Registros de facturación de alta
El registro de alta se genera de forma simultánea o inmediatamente anterior a la expedición de cada factura. Contiene la identificación del obligado, datos de la factura, importes, fecha de generación, identificación del sistema y referencia al registro anterior, entre otros campos. Los artículos 9 y 10 del Real Decreto 1007/2023 definen su generación y contenido.
Para comprobar la firma no basta con ver un icono verde. Exporta o visualiza el registro, identifica el contenido firmado y comprueba que la herramienta muestra el certificado y el resultado. Selecciona ejemplos con series distintas, facturas completas y simplificadas si existen, y al menos un cambio de día. No necesitas enviar datos de clientes a un tercero para hacer esta prueba: puede ejecutarse en un entorno controlado con información adecuada.
Registros de facturación de anulación
La anulación no borra el alta original. El reglamento prevé un registro posterior cuando una factura se emitió erróneamente y hay que anular su registro de alta. Ese registro conserva datos que identifican la factura afectada, el sistema, el momento de generación y el enlace con el registro anterior. El artículo 11 regula el registro de anulación.
La prueba debe incluir una anulación porque su estructura no es idéntica a la de un alta. Comprueba que queda firmada, que el alta sigue disponible y que ambos registros pueden seguirse en la cadena. Si el sistema permite «eliminar» una factura sin dejar el registro posterior correspondiente, no conviertas la incidencia en una simple pregunta sobre certificados: afecta a la inalterabilidad y necesita revisión del proveedor.
Registros de evento
El registro de eventos solo es obligatorio para los sistemas de emisión de facturas no verificables. La AEAT lo distingue de la modalidad VERI*FACTU. El registro de eventos recoge automáticamente determinadas interacciones, operaciones y sucesos en el momento en que se producen, y debe poder consultarse desde el propio SIF. La explicación oficial aclara que no es un diario manual añadido al final del mes.
Entre los eventos previstos figuran el inicio y fin del funcionamiento como NO VERI*FACTU, la detección de anomalías, la restauración de copias y las exportaciones de registros. La FAQ oficial enumera esas categorías y otras relacionadas. Por eso la revisión debe mirar más allá de las facturas: una restauración o exportación también deja un rastro técnico.
El registro resumen de eventos se graba cada seis horas en las que el SIF haya estado operativo y disponible, y también antes de cerrarse o apagarse. La AEAT concreta la frecuencia del resumen. Si la aplicación estuvo abierta doce horas y no aparece ningún resumen, documenta el horario y pide al proveedor que explique el comportamiento antes de concluir que la firma funciona correctamente.
XAdES: qué acredita y qué no
El tipo previsto por la AEAT para estos registros es XAdES Enveloped Signature. La FAQ remite además a las especificaciones técnicas y a ejemplos para desarrolladores. «Enveloped» describe una firma integrada en el documento XML que contiene los datos firmados. No significa que baste con adjuntar un PDF firmado a una exportación.
La firma permite comprobar la correspondencia entre el contenido y la firma y acreditar su autoría en los términos descritos por la AEAT. Su valor operativo aparece cuando una modificación posterior provoca que la verificación deje de ser válida. Una captura de pantalla de la factura no ofrece esa prueba, porque no contiene necesariamente el registro ni la firma electrónica que exige el SIF.
La página de capacidad de remisión señala que la firma puede usar certificados distintos de los empleados por la AEAT siempre que sea cualificada y sirva para autenticar y hacer inmutable el contenido. La AEAT formula esa condición al responder sobre certificados similares a TicketBAI. No deduzcas de esa respuesta que cualquier certificado instalado en Windows es suficiente. Pide al proveedor la justificación técnica y compárala con las especificaciones vigentes.
La identificación del firmante también debe ser coherente con la arquitectura. Anota quién controla el certificado, dónde se custodia, cómo se renueva y qué ocurre cuando caduca. Estas son recomendaciones de control, no requisitos adicionales atribuidos a la AEAT. Sirven para evitar que una renovación deje registros sin firmar o que el sistema use silenciosamente otra credencial.
Cómo probar la verificación sin quedarse en una captura
Un SIF no verificable debe permitir comprobar de forma rápida, fácil e intuitiva las firmas de los registros que estén a su alcance. La AEAT exige esa posibilidad para altas, anulaciones y eventos. La comprobación se realiza, en principio, a petición del usuario; no tiene que ser automática ni periódica. La misma FAQ aclara ese límite.
Prepara una prueba reproducible:
- Registra producto, versión, instalación, modalidad, usuario y fecha.
- Genera o selecciona un alta, una anulación y eventos de tipos diferentes.
- Ejecuta la función de comprobación desde el propio SIF.
- Guarda el resultado con la identificación del registro y del certificado.
- En un entorno de prueba autorizado, altera una copia del contenido y confirma que la firma deja de validarse.
- Repite la verificación después de actualizar el software o renovar el certificado.
No alteres el registro original de producción para demostrar el control. Trabaja con una copia segura o con un entorno de ensayo que el proveedor haya previsto. El objetivo es comprobar la detección, no crear una anomalía en la contabilidad real.
Un resultado «válido» debe poder relacionarse con el registro concreto. Guarda el identificador, la fecha de generación, el tipo, la huella, el certificado y la salida de la herramienta. Si la pantalla solo dice «todo correcto» y no permite saber qué verificó, pide un informe o exportación que deje rastro suficiente.
Firma, hash y encadenamiento no son sinónimos
El Real Decreto 1007/2023 exige añadir una huella o «hash» a los registros de facturación de alta y de anulación. El artículo 12 establece el hash y la firma. El hash resume determinados datos del registro. La firma vincula el contenido con un firmante y permite comprobar su integridad. El encadenamiento usa información del registro anterior para mantener la secuencia.
Los registros deben estar encadenados para que pueda seguirse su secuencia de creación desde el primero hasta el último. El artículo 8 define la trazabilidad. Un registro puede tener una firma técnicamente válida y, aun así, existir un problema si la referencia a la cadena está rota, si falta un registro o si se oculta una operación.
La conservación, accesibilidad y legibilidad alcanzan a todos los registros de facturación generados por el propio sistema. El reglamento exige además un procedimiento de descarga, volcado y archivo seguro. Verificar hoy una firma no garantiza que el archivo siga disponible y legible durante el periodo exigible.
Una firma válida no acredita por sí sola todo el cumplimiento: siguen siendo exigibles el hash, el encadenamiento, la conservación, la accesibilidad y la capacidad de remisión. La revisión debe producir evidencias distintas para cada control, sin repetir el mismo pantallazo como respuesta universal.
Capacidad de remisión aunque no se envíe cada registro
Todo SIF debe tener capacidad de remitir electrónicamente a la Administración tributaria los registros de facturación generados. La AEAT conecta esta capacidad con el artículo 8.1 del reglamento. Un sistema no verificable no hace la remisión inmediata y sistemática propia de VERI*FACTU, pero debe poder atender el mecanismo previsto y también permitir un cambio posterior de modalidad.
La Administración puede exigir acceso, consulta, descarga o copia de los registros de facturación y de eventos con los límites legales aplicables. El artículo 14 describe las facultades de verificación. Por eso el archivo de evidencias no debe depender de un técnico concreto ni de una base de datos indescifrable sin la aplicación.
Prueba una exportación controlada y documenta el formato, el periodo, el número de registros y la posibilidad de comprobar sus firmas. No confundas esta prueba con el envío sistemático a la AEAT. Si al ejecutarla el sistema comienza a remitir registros como VERI*FACTU, detén la prueba y revisa la configuración, porque la modalidad tiene consecuencias temporales.
Qué cambia al usar VERI*FACTU
Si el sistema remite de forma sistemática e inmediata como VERIFACTU, no se exige firma explícita; si opera como sistema no verificable, debe firmar los registros que genera y permitir su comprobación. La opción VERIFACTU se produce al iniciar sistemáticamente la remisión de registros y se mantiene, al menos, hasta terminar el año natural del primer envío efectivo. El artículo 16 define la modalidad y la duración mínima de la opción.
Aunque no estén obligados, los SIF VERI*FACTU pueden firmar los registros de facturación y remitirlos firmados. La AEAT admite expresamente esa posibilidad. Esa firma voluntaria no convierte el sistema en no verificable ni crea por sí sola la obligación de llevar el registro de eventos propio de esa modalidad.
La comparación práctica queda así:
| Control | SIF no verificable | SIF VERI*FACTU |
|---|---|---|
| Firma explícita de altas y anulaciones | Obligatoria | No obligatoria; puede ser voluntaria |
| Registro de eventos | Obligatorio | No obligatorio por esta modalidad |
| Firma de eventos | Obligatoria sobre los que genera | No aplica si no genera esos eventos |
| Hash de registros de facturación | Obligatorio | Obligatorio |
| Remisión | Capacidad disponible | Inmediata y sistemática |
| Comprobación de firma | Debe ofrecerla | No exigida si no firma |
No uses esta tabla para elegir modalidad por un único coste técnico. La decisión afecta a la remisión, la operativa ante incidencias, los listados disponibles y el mantenimiento anual. Debe tomarse con el proveedor y con quien gestione las obligaciones fiscales.
La declaración responsable es otro expediente
La declaración responsable del productor es una obligación distinta de la firma electrónica de cada registro. El artículo 13 exige que identifique el sistema, su versión, tipología, composición y funcionalidades. Un PDF de declaración responsable no demuestra que un registro concreto esté firmado; una firma válida tampoco sustituye la declaración de la versión.
Pide ambos elementos con nombres distintos. Para la declaración responsable, conserva el documento correspondiente a la versión instalada. Para la firma, conserva la prueba ejecutada sobre registros. Si necesitas revisar la primera, consulta la guía para elegir software VERI*FACTU y comprobar su declaración responsable.
También conviene separar la firma del registro de la firma de una factura PDF o de un contrato. Son objetos, finalidades y formatos diferentes. La pregunta correcta para el proveedor es: «¿Dónde puedo verificar la firma XAdES del registro de alta, anulación o evento generado por esta versión?».
Incidencias que merecen una respuesta concreta
El proveedor dice que VERI*FACTU siempre firma
Pídele que distinga obligación y función voluntaria. VERI*FACTU puede remitir registros firmados, pero la norma no exige la firma explícita porque la remisión ya incorpora autenticación. La explicación debe indicar qué se firma, con qué certificado y cómo se verifica.
Solo se firman las altas
La muestra está incompleta. En modalidad no verificable también deben revisarse anulaciones y eventos. Genera una anulación de prueba y localiza eventos de inicio, exportación o resumen. Si no aparecen, abre una incidencia por tipo de registro.
El certificado caducó
No supongas que los registros anteriores han perdido automáticamente su validez ni que los nuevos están bien firmados. Identifica el periodo afectado, comprueba firmas anteriores y posteriores y pide al proveedor el procedimiento de renovación. La respuesta depende de la implementación y de las especificaciones aplicables.
La firma valida, pero la cadena no
Trata ambos resultados por separado. Conserva el informe de firma y el error de encadenamiento. Revisa qué registro anterior se referencia, si existe una bifurcación o si hubo restauración de copia. El registro de eventos puede aportar el contexto técnico.
Se trabaja sin conexión
La ausencia temporal de red no elimina las obligaciones de la modalidad no verificable. El SIF debe generar y conservar los registros y aplicar sus controles. La capacidad de remisión debe seguir disponible para cuando proceda. Documenta cómo se renuevan certificados y cómo se recupera la operación sin alterar la secuencia.
Lista de control para aceptar una versión
Antes de dar por revisada la firma, deja constancia de estas comprobaciones:
- modalidad real de cada instalación y fecha desde la que opera;
- declaración responsable de la versión, archivada como documento separado;
- firma XAdES verificable en una muestra de altas y anulaciones;
- firma verificable en eventos y existencia de resúmenes cada seis horas operativas;
- certificado identificado, vigente y coherente con la documentación técnica;
- prueba de detección sobre una copia alterada en entorno controlado;
- hash y encadenamiento comprobados como controles distintos;
- exportación legible y archivo seguro de registros;
- procedimiento de renovación, actualización y recuperación documentado;
- responsable interno y evidencia de la fecha de revisión.
Esta lista es una recomendación operativa. No convierte cada punto documental en un requisito literal adicional de la AEAT. Su función es evitar una aceptación basada en una sola captura o en una afirmación comercial imposible de reproducir.
Preguntas frecuentes
¿Qué registros debe firmar un sistema no verificable?
Todos los tipos que genere: registros de facturación de alta, registros de facturación de anulación y registros de evento. La revisión debe comprobar cada familia por separado, porque una prueba válida sobre un alta no acredita por sí sola el tratamiento de anulaciones o eventos.
¿Qué firma exige VERI*FACTU?
VERIFACTU no exige la firma electrónica explícita de los registros: la remisión inmediata incorpora autenticación mediante certificado electrónico cualificado y medios seguros. XAdES Enveloped Signature corresponde a los registros del SIF no verificable. Un SIF VERIFACTU puede firmar voluntariamente los registros de facturación. La AEAT explica la autenticación de la remisión y la firma voluntaria.
¿Es obligatorio firmar los registros en VERI*FACTU?
No se exige la firma electrónica explícita a los SIF VERI*FACTU. La AEAT lo vincula a la remisión inmediata autenticada y segura. El sistema puede firmar voluntariamente los registros de facturación, pero esa decisión no cambia las obligaciones propias de la modalidad.
¿Cómo verificar que el certificado o algoritmo usado sirve para firmar registros?
Pide una verificación desde el propio SIF sobre un alta, una anulación y varios eventos. Comprueba resultado, certificado, fecha, contenido firmado y detección de una alteración controlada. Conserva la evidencia de la prueba y repítela tras cambios relevantes de versión o certificado. La AEAT exige que el SIF no verificable permita comprobar las firmas.
Siguiente paso
Reúne la declaración responsable, el manual de la versión y una exportación de prueba. Marca la modalidad activa y ejecuta la verificación sobre altas, anulaciones y eventos antes de aceptar el sistema. Si aún estás delimitando el ámbito, revisa la guía sobre facturación manual sin programa. Para situar esta comprobación dentro del proyecto completo, consulta la guía sobre firma electrónica SIF y requisitos de VERI*FACTU y el hub fiscal-contable.
Si necesitas contrastar la modalidad, la evidencia del proveedor y el impacto fiscal de una incidencia, TaxFactory puede validar la firma y la modalidad del SIF. La revisión parte de la versión instalada y de registros de prueba; no sustituye la certificación técnica del productor.