Respuesta corta

El artículo 4 de la Orden HAC/1177/2024 exige que el SIF gestione certificados electrónicos para autenticarse en la conexión con la AEAT durante la remisión. La misma capacidad incluye conectarse a internet, remitir los registros mediante protocolos seguros y procesar la respuesta. Artículo 4 de la Orden HAC/1177/2024.

Según la FAQ de la AEAT sobre firma, los SIF VERI*FACTU no están obligados a firmar electrónicamente los registros que generan. En esta modalidad no se exige una firma electrónica explícita adicional. Fuente oficial. Los sistemas no verificables sí deben firmar electrónicamente los registros de alta, anulación y evento con el formato XAdES previsto en el artículo 14. Artículo 14 de la Orden.

La declaración responsable es el documento con el que el productor manifiesta la conformidad de una versión del SIF; no es el certificado usado para autenticar la remisión. Su contenido se regula en el artículo 15 de la Orden, con las aclaraciones de la FAQ oficial sobre declaración responsable.

Esa distinción evita uno de los errores más frecuentes al preparar un sistema de facturación: pedir al proveedor “el certificado VERI*FACTU” como si existiera un único documento capaz de resolver autenticación, integridad del registro y cumplimiento del software. Son tres asuntos relacionados, pero distintos.

Ese marco exige que el sistema pueda conectarse a internet, gestionar certificados electrónicos, remitir los registros mediante protocolos seguros y procesar la respuesta de la AEAT. El certificado se usa para autenticar esa conexión y, cuando proceda, también puede intervenir en la firma electrónica. Que participe en ambas operaciones no las convierte en una sola.

Para implantarlo bien hay que contestar cuatro preguntas: qué obligado figura en los registros, quién hace materialmente el envío, con qué representación actúa si no es el propio obligado y dónde se custodia la clave privada. La marca comercial del programa no responde ninguna de ellas.

Tres piezas que conviene nombrar bien

La autenticación de la remisión, la firma de los registros y la declaración responsable tienen reglas y fuentes distintas. Conviene revisarlas por separado, sin atribuir al certificado de conexión efectos que corresponden al productor o a la firma del registro.

Pieza Para qué sirve Quién la aporta o controla Qué no demuestra
Certificado de la conexión Autentica al remitente ante el servicio de la AEAT El obligado o quien pueda actuar válidamente en su nombre No certifica por sí mismo que el software cumpla el RRSIF
Firma electrónica del registro Permite comprobar autoría e integridad del registro firmado El SIF cuando la modalidad obliga a firmar No sustituye la autenticación de la conexión
Declaración responsable Identifica una versión del SIF y declara su conformidad normativa La persona o entidad productora No es una credencial, un apoderamiento ni una firma de cada envío

La tabla es un mapa operativo, no una equivalencia jurídica entre documentos. Un certificado cualificado puede servir como soporte criptográfico en más de un punto, pero el equipo debe registrar qué uso se hace de él. De lo contrario, una renovación puede dejar activa la conexión y romper la firma, o al revés, sin que nadie entienda por qué.

1. Autenticación de la remisión

El artículo 4 de la Orden define la capacidad de remisión de todo SIF. Gestionar certificados es una parte expresa de esa capacidad. La finalidad que cita la norma es autenticarse en la conexión con la AEAT para enviar información. También exige que el programa use la estructura y codificación requeridas, transmita por protocolos seguros y procese la contestación del servicio.

Autenticarse solo abre la puerta correcta con una identidad admitida. No significa que el fichero sea válido, que todos los registros se acepten ni que la persona que instaló la credencial tenga autorización interna para usarla. El artículo 16 de la Orden prevé una respuesta con código seguro de verificación cuando se acepta al menos un registro e información sobre los registros erróneos. Por eso la prueba de conexión no termina al comprobar que no hubo un error TLS.

En la práctica, el expediente técnico debería relacionar el titular del certificado, el obligado al que se refieren los registros, la base de representación cuando sean distintos y la respuesta obtenida. Si el envío mezcla registros de varios obligados, esa relación debe poder reconstruirse sin depender de la memoria de quien configuró el programa.

2. Firma electrónica del registro

Los SIF VERI*FACTU no están obligados a firmar electrónicamente los registros que generan. La FAQ oficial de la AEAT sobre firma explica que los remiten inmediatamente y que la operación incluye autenticación mediante certificado electrónico cualificado y medios seguros de transmisión. La AEAT considera que ese recorrido aporta una firma básica del registro, de modo que no exige una firma electrónica explícita adicional.

La excepción no se debe generalizar. Los sistemas no verificables sí deben firmar electrónicamente los registros de alta, anulación y evento con el formato XAdES previsto en el artículo 14. El artículo 14 de la Orden HAC/1177/2024 fija XAdES Enveloped Signature, basado en ETSI EN 319 132, y exige que la clave privada esté asociada a un certificado cualificado de firma electrónica en vigor, emitido por un prestador cualificado incluido en la lista de confianza de la UE.

Un SIF VERI*FACTU puede firmar voluntariamente los registros, según la misma FAQ. Si el proveedor decide hacerlo, conviene documentarlo porque añade una dependencia operativa que no nace de la obligación general de esa modalidad. La respuesta a “¿quién firma?” será distinta según el modo real del sistema, no según la etiqueta que figure en una presentación comercial.

3. Declaración responsable del productor

El artículo 13 del Real Decreto 1007/2023 atribuye a la persona o entidad productora la certificación del SIF mediante una declaración responsable. Debe constar por escrito, ser visible en el sistema para cada versión y estar disponible para clientes y comercializadores cuando adquieren el producto.

La FAQ de la AEAT sobre certificación aclara que no se exige una certificación externa ni un registro previo del producto: es una autocertificación del productor.

La declaración responsable es el documento con el que el productor manifiesta la conformidad de una versión del SIF; no es el certificado usado para autenticar la remisión. El artículo 15 de la Orden desarrolla su contenido y la FAQ de la AEAT aclara su carácter de autocertificación del productor. Pedirla al proveedor es necesario para revisar el SIF, pero no resuelve la configuración de la remisión.

Quién puede aparecer en cada papel

La elección práctica depende de quién se autentica ante la AEAT y de su representación. La declaración responsable del proveedor no es una credencial de envío y no autoriza por sí sola a un tercero a remitir registros. El artículo 13 del Real Decreto 1007/2023 atribuye esa declaración al productor del sistema.

En esta operativa aparecen varios roles. A veces recaen en la misma empresa; muchas veces, no:

  • El obligado tributario expide las facturas y responde del cumplimiento de sus obligaciones.
  • El productor desarrolla el SIF y emite la declaración responsable de la versión.
  • El comercializador suministra o implanta el producto, sin convertirse por ese hecho en productor o representante fiscal.
  • El remitente ejecuta la conexión. Puede ser el propio obligado o un tercero que actúe con la habilitación adecuada.

La remisión puede efectuarla el propio obligado tributario o un tercero que actúe en su representación conforme a las reglas citadas por el artículo 5 de la Orden HAC/1177/2024. Artículo 5 de la Orden HAC/1177/2024. Esto no borra la necesidad de atribuir correctamente el envío ni convierte el contrato de software en un apoderamiento tributario universal. Si una asesoría, plataforma o integrador remite por cuenta del cliente, debe comprobar qué régimen de representación o colaboración resulta aplicable y si el certificado elegido funciona bajo ese régimen.

Matriz práctica de roles

Escenario Identidad que debe revisarse Evidencia mínima antes de producción Riesgo típico
Empresa que remite desde su propio SIF Obligado titular y usuario autorizado internamente Certificado vigente, prueba de acceso, envío aceptado y responsables de custodia Compartir la clave entre demasiadas personas
Asesoría que remite por clientes Asesoría remitente, cliente obligado y representación aplicable Relación de clientes, habilitación, prueba por NIF y trazabilidad de cada envío Presumir que un certificado válido autoriza cualquier cliente
Plataforma cloud que automatiza el envío Titular de la credencial, operador de la plataforma y obligado de cada registro Diseño de tenencia de claves, segregación por cliente, logs y procedimiento de revocación Convertir una incidencia de custodia en una caída para todos los clientes
Grupo con varias sociedades Cada obligado, aunque comparta tecnología Inventario por entidad, permisos separados y pruebas con datos no productivos Confundir pertenencia al grupo con identidad tributaria única

La matriz no prescribe una arquitectura. Sirve para detectar huecos antes de encargar el certificado o entregar una copia al proveedor. La solución correcta depende del servicio de la AEAT, la representación y el modo en que el SIF aísla clientes y claves.

Cómo preparar el certificado sin dejar cabos sueltos

Como pauta operativa, conviene identificar al obligado y al remitente, limitar el acceso a la clave privada, probar el envío y la respuesta, y planificar la renovación y la revocación según la arquitectura y el riesgo. El artículo 4 de la Orden HAC/1177/2024 respalda las capacidades de autenticación, remisión y tratamiento de respuestas; la secuencia propuesta es una recomendación de implantación, no una lista legal cerrada.

Inventario previo

Empieza por un inventario breve: razón social y NIF de cada obligado, modalidad del SIF, persona o entidad que enviará, entorno desde el que conectará y fecha prevista de activación. Añade la versión del software y su declaración responsable. Esto permite separar una carencia documental del producto de un problema de identidad electrónica.

Después revisa la credencial. Deben quedar registrados su titular, emisor, número de serie o identificador equivalente, usos habilitados, fecha de expiración y entorno autorizado. No copies la clave privada al inventario. Basta con documentar dónde se custodia y quién administra el acceso.

Instalación y custodia

La clave privada merece más atención que el archivo visible del certificado. Si el proveedor pide enviarla por correo, alojarla en una carpeta compartida o reutilizar una contraseña común, detén la implantación y acuerda un canal y un almacén adecuados. Limita las exportaciones y separa a quien administra la infraestructura de quien puede aprobar cambios sensibles cuando el tamaño de la organización lo permita.

En servicios cloud hay que preguntar si la clave sale del control del cliente, si se cifra en reposo, quién puede descifrarla, cómo se rota y qué ocurre al terminar el contrato. La respuesta “cumplimos VERI*FACTU” no cubre estas cuestiones. La normativa de facturación establece el resultado funcional; la custodia necesita controles de seguridad propios.

Prueba de extremo a extremo

Una comprobación útil recorre el camino completo: el SIF genera un registro de prueba admitido por el entorno correspondiente, autentica la conexión, transmite el mensaje, procesa la respuesta y deja una evidencia vinculada al intento. También hay que ensayar un rechazo controlado. Así se comprueba que el equipo distingue una credencial caducada de un error de formato o de un registro rechazado.

Guarda el identificador del envío, fecha y hora, obligado afectado, resultado global, resultado por registro cuando exista y persona que revisó la prueba. Evita conservar más datos fiscales de los necesarios en tickets generales o capturas sin control de acceso.

Renovación, revocación e incidentes

No esperes al último día de vigencia. Define una alerta con margen suficiente para obtener, instalar y probar la nueva credencial. La renovación no está terminada cuando el fichero se importa: termina cuando el recorrido completo funciona y la credencial anterior se retira según el procedimiento acordado.

El plan de revocación debe indicar quién puede ordenar el bloqueo, a qué prestador se contacta, qué integraciones usan la clave y cómo se mantiene la facturación mientras se investiga. Si una persona con acceso abandona la empresa o se sospecha una extracción, no basta con cambiar la contraseña de una aplicación que ya tiene la clave cargada.

Decidir entre credencial propia y remisión por tercero

No hay una respuesta universal. Una pyme con un solo SIF puede preferir que la credencial pertenezca al propio obligado y mantener el control directo. Una asesoría que gestiona cientos de clientes necesita una operación distinta, con representación comprobada, segregación y trazabilidad por cliente. El criterio no debería ser qué opción requiere menos clics durante el alta.

Para decidir, pide respuestas verificables. Empieza por estas preguntas, pero amplía la revisión si tu arquitectura tiene más actores:

  1. ¿Quién figura como titular de la credencial que se presentará ante la AEAT?
  2. ¿Qué habilitación permite a ese titular actuar por el obligado de cada registro?
  3. ¿Quién conserva y puede usar la clave privada?
  4. ¿Puede revocarse el acceso de un operador sin interrumpir a todos los clientes?
  5. ¿Cómo se demuestra qué identidad remitió cada lote y qué respondió la AEAT?
  6. ¿Qué pasa cuando vence el certificado o termina la relación con el proveedor?

Una propuesta es incompleta si responde solo a la primera. También es mala señal que el proveedor mezcle la declaración responsable con la autorización del envío. Para revisar el producto en sí, la guía sobre elegir software VERI*FACTU y revisar su declaración responsable cubre ese otro ángulo.

Errores que una conexión correcta no descarta

Un certificado aceptado prueba una parte del proceso. Todavía puede haber registros con estructura incorrecta, NIF mal atribuido, desfase horario, duplicidad, error de encadenamiento o una respuesta que el SIF no procesa. La Orden exige recibir y tratar las respuestas, no limitarse a enviar.

Tampoco debe confundirse un envío aceptado parcialmente con una remisión íntegra. El código seguro de verificación puede aparecer cuando al menos un registro es correcto, mientras la contestación identifica otros erróneos. El control operativo debe bajar al resultado que corresponda a cada registro.

Otro fallo habitual es tener dos copias activas de la misma clave sin inventario. Funciona hasta que llega una renovación, una baja de proveedor o una sospecha de compromiso. Entonces nadie sabe qué servidor sigue autenticándose con la copia antigua. El inventario debe recoger cada despliegue autorizado, aunque todos usen el mismo certificado.

Fechas y alcance: qué no debe deducirse de esta guía

El calendario de adaptación ha cambiado mediante modificaciones normativas. El texto consolidado del Real Decreto consultado el 31 de agosto de 2026 recoge la redacción vigente en esa fecha. La fecha general indicada en la matriz editorial es el 1 de julio de 2027, mientras que para contribuyentes del Impuesto sobre Sociedades la regla principal puede aplicar desde el 1 de enero de 2027. Antes de tomar una decisión de implantación hay que comprobar el tipo de obligado y el texto vigente, no trasladar una fecha genérica a todos los casos.

Esta guía no valida un certificado concreto ni su cadena de confianza. Los certificados admitidos, la representación y los detalles técnicos del servicio deben comprobarse en la sede y en la documentación técnica vigentes al implantar o renovar. La FAQ oficial sobre capacidad de remisión y certificados es uno de los puntos que hay que reconsultar.

Tampoco aborda cómo implementar internamente la firma XAdES campo por campo. Explica por qué no debe confundirse con la autenticación de la remisión. La especificación técnica, los algoritmos y los ejemplos oficiales deben revisarse en el momento de desarrollar o auditar un SIF no verificable.

La información es general y no sustituye una revisión fiscal, jurídica o de ciberseguridad del caso. Si intervienen varios obligados, un tercero remitente o custodia cloud de claves, documenta la arquitectura y sométela a revisión antes de producción.

Lista de comprobación antes de activar

Conviene que esta lista la revise alguien de fiscal y alguien de sistemas. La conversación suele descubrir afirmaciones que parecen técnicas pero dependen de la representación. También aparecen decisiones fiscales que, en realidad, fallan por una mala custodia.

  • Está identificado cada obligado cuyos registros se remitirán.
  • Está documentado quién se autentica y con qué habilitación actúa.
  • La versión del SIF tiene declaración responsable accesible y coherente con el modo usado.
  • El certificado está vigente y admitido para el servicio probado.
  • La clave privada se guarda en un entorno controlado, con accesos nominativos.
  • El envío de prueba recibe una respuesta que el SIF procesa y conserva de forma trazable.
  • Se ha probado un error de autenticación y un rechazo de registro sin confundirlos.
  • Existen alertas de caducidad, procedimiento de renovación y criterio de revocación.
  • La salida de un empleado o proveedor permite retirar su acceso sin perder evidencia.
  • El contrato asigna tareas operativas sin presentar la declaración responsable como autorización tributaria.

Para situar esta configuración dentro del proyecto completo, consulta la guía sobre certificado de remisión en VERI*FACTU y el recorrido para conectar un SIF con la AEAT. El centro de recursos sobre VERI*FACTU y facturación agrupa las decisiones relacionadas. Si necesitas revisar certificado, representación y controles con tu operativa, puedes acudir al servicio fiscal-contable.

Preguntas frecuentes

¿Qué certificado necesita VERI*FACTU?

Un certificado electrónico que permita autenticar la conexión del remitente con la AEAT y que sea válido para su titular o representación. La Orden exige que el SIF gestione certificados, pero la admisión de una credencial concreta debe verificarse en la sede y en la documentación técnica vigente. No compres ni renueves basándote solo en que el proveedor lo llame “certificado VERI*FACTU”. Artículos 4 y 5 de la Orden HAC/1177/2024.

¿Quién firma la remisión de registros?

En el envío se autentica el remitente legitimado mediante su certificado. En VERI*FACTU no se exige una firma electrónica explícita de cada registro porque la remisión inmediata autenticada y segura cubre esa función básica, según la AEAT. Los sistemas no verificables sí deben firmar electrónicamente sus registros de alta, anulación y evento con los requisitos de la Orden HAC/1177/2024. FAQ de la AEAT sobre firma.

¿Es el mismo certificado que la declaración responsable?

No. La declaración responsable ni siquiera es un certificado electrónico: es un documento del productor referido al sistema y a una versión concreta. Declara conformidad con el marco aplicable, pero no autentica la conexión ni concede representación al proveedor, asesor o integrador. Artículo 15 de la Orden HAC/1177/2024.

¿Cómo separar el certificado de remisión de la firma del registro?

Mira el propósito y la evidencia resultante. El certificado de remisión presenta una identidad ante el servicio de la AEAT y permite establecer la conexión autenticada. La firma XAdES se incorpora al registro cuando es obligatoria para probar autoría e integridad. Ambas operaciones pueden usar certificados cualificados, pero se configuran, prueban y auditan por separado. Artículos 4, 5 y 14 de la Orden HAC/1177/2024.

Fuentes oficiales consultadas

Validar el certificado de remisión