Declaración responsable del sistema informático de facturación

Emitida al amparo del artículo 13 del Reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y del artículo 15 de la Orden HAC/1177/2024, de 17 de octubre, conforme a la estructura de los ejemplos de declaración responsable publicados por la Agencia Estatal de Administración Tributaria.

1.a) Nombre del sistema informático a que se refiere esta declaración responsable:	OptiPymIA Motor Fiscal
1.b) Código identificador del sistema informático a que se refiere el apartado a) de esta declaración responsable:	OP
1.c) Identificador completo de la versión concreta del sistema informático a que se refiere esta declaración responsable:	1.0.0

1.d) Componentes, hardware y software, de que consta el sistema informático a que se refiere esta declaración responsable, junto con una breve descripción de lo que hace dicho sistema informático y de sus principales funcionalidades:

OptiPymIA Motor Fiscal es un sistema informático de facturación que se presta como servicio y se utiliza mediante una interfaz de programación de aplicaciones (API). No tiene usuarios finales ni pantallas propias. Lo utilizan las aplicaciones de gestión de GRUPO OPTIPYMIA, S.L., como FlexTaller, el programa de gestión para talleres de reparación de vehículos. Las aplicaciones le envían los datos de cada factura que el obligado tributario quiere expedir y reciben de él la factura ya expedida: su número, su código QR tributario y su documento en PDF.

No se instala en los equipos del usuario ningún componente del sistema, ni se necesita hardware específico (dispositivos criptográficos, impresoras fiscales u otros). El sistema se ejecuta en la infraestructura del productor, en Google Cloud, en regiones de la Unión Europea; el servicio de aplicación y la base de datos, en la región europe-southwest1 (Madrid, España). El servicio no admite llamadas públicas: solo lo pueden invocar las aplicaciones cliente autorizadas por el productor, y cada una se identifica con su propia credencial de servicio, que el sistema verifica en cada llamada.

El sistema está formado por los componentes software siguientes:

• Numeración: series de facturación propias de cada obligado tributario, cada una con su numeración correlativa.
• Expedición: valida los datos de la factura y la expide. Desde ese momento quedan fijados y no se pueden modificar los datos del emisor y del destinatario, las líneas, el desglose y los importes.
• Calificación y desglose: calificación de cada operación y desglose por régimen, calificación y tipo impositivo.
• Motor de registros de facturación: calcula la huella, encadena cada registro con el anterior del mismo obligado tributario y genera el registro de facturación de alta y la URL del código QR tributario.
• Generación del documento de la factura: genera la factura en PDF, con el código QR tributario y las menciones obligatorias.
• Remisión: remite los registros de facturación a la Agencia Estatal de Administración Tributaria. Incluye la cola de remisión, el control de flujo y el cliente del servicio web.
• Identificación del sistema y de la instalación de cada obligado tributario.
• Control de la representación ante la Agencia Estatal de Administración Tributaria bajo la cual el productor remite los registros, y control de la fecha de activación de cada obligado tributario.
• Consulta y exportación: estado de remisión, registros no remitidos y exportación de los registros de cada obligado tributario.

Aplicaciones cliente. Las aplicaciones de gestión que utilizan el sistema no forman parte de él. Cada aplicación cliente:

• compone el contenido de la factura: qué se factura, a quién y por qué importe;
• autentica a sus propios usuarios;
• indica al sistema por cuenta de qué obligado tributario se expide cada factura, de entre los que el productor ha vinculado a esa aplicación.

Una aplicación cliente no numera, no genera registros de facturación, no calcula huellas ni códigos QR, no genera el documento de la factura y no remite nada a la Agencia Estatal de Administración Tributaria. Tampoco puede modificar ni borrar lo expedido. Los cambios en las aplicaciones cliente no alteran esta declaración.

Activación del sistema por cada obligado tributario. El sistema genera los registros de facturación y los remite en la modalidad «VERI*FACTU» desde la fecha de activación de cada obligado tributario. Esa fecha es la que solicita el obligado tributario y nunca es posterior a la fecha desde la que la normativa le obliga a utilizar un sistema informático de facturación adaptado al Reglamento. Si no solicita ninguna, el sistema se activa en esa fecha. Una fecha de activación ya solicitada se puede adelantar, pero no retrasar. La activación es irreversible: desde la fecha de activación, todas las facturas que el obligado tributario expide con el sistema tienen su registro de facturación, y el sistema no vuelve a expedirlas sin él.

Antes de su fecha de activación, el sistema no actúa para ese obligado tributario como sistema informático de facturación adaptado al Reglamento. Numera y expide sus facturas con los mismos datos fijados y genera su documento, pero no genera registros de facturación, no remite nada a la Agencia Estatal de Administración Tributaria y no expide facturas con el código QR tributario. Lo que esta declaración responsable describe del sistema como sistema adaptado se refiere a las facturas expedidas desde la fecha de activación de cada obligado tributario.

Principales funcionalidades del sistema:

• Facturas completas (tipo F1) y facturas simplificadas (tipo F2), estas de hasta 3.000 euros, impuestos incluidos.
• Facturas rectificativas (tipos R1 a R5), por sustitución o por diferencias. La rectificación del importe total de una factura se expide como rectificativa por diferencias.
• Rectificativas de facturas expedidas fuera del sistema, identificando la factura rectificada por su número, su fecha y sus importes.
• Facturas con varios tipos impositivos, con desglose por tipo.
• Operaciones con inversión del sujeto pasivo.
• Facturas de venta de bienes usados en el régimen especial de los bienes usados (REBU), en series de facturación propias, separadas de las del régimen general, con sus rectificativas.
• Generación de un registro de facturación de alta por cada factura expedida, con huella SHA-256 encadenada a la del registro anterior del mismo obligado tributario.
• Generación de la factura en PDF con el código QR tributario y la leyenda «VERI*FACTU».
• Remisión automática de todos los registros de facturación a la Agencia Estatal de Administración Tributaria, con control de flujo y reintento sin límite ante fallos de comunicación.
• Corte de la remisión cuando no hay representación vigente del obligado tributario, y descarga de los registros no remitidos por este motivo.
• Consulta del estado de remisión de cada registro, de su huella y del contenido remitido y recibido, y exportación de todos los registros de facturación de un obligado tributario.

El sistema no permite anular facturas expedidas. Cualquier modificación, cancelación o anulación se instrumenta mediante la expedición de una factura rectificativa (artículo 15 del Real Decreto 1619/2012), con su registro de facturación de alta. En consecuencia, el sistema no genera registros de facturación de anulación.

Este sistema permite gestionar de forma independiente varias facturaciones dentro de él, una por cada obligado tributario. Cumple separadamente para cada una de ellas la normativa mencionada en el apartado 1.k) de esta declaración responsable, como si, en la práctica, se tratara de sistemas informáticos de facturación distintos. Los datos de cada obligado tributario están identificados por su NIF, y tiene un número de instalación propio y una cadena de registros de facturación propia, única para todas sus series. Si un mismo obligado tributario utiliza el sistema desde varias aplicaciones cliente, mantiene una sola instalación y una sola cadena de registros. Cada una de sus series pertenece a una sola aplicación cliente, y cada aplicación solo consulta y rectifica las facturas que ella expidió.

1.e) Indicación de si el sistema informático a que se refiere esta declaración responsable se ha producido de tal manera que, a los efectos de cumplir con el Reglamento, solo pueda funcionar exclusivamente como «VERI*FACTU»:

S - Sí

1.f) Indicación de si el sistema informático a que se refiere la declaración responsable permite ser usado por varios obligados tributarios o por un mismo usuario para dar soporte a la facturación de varios obligados tributarios:

S - Sí

1.g) Tipos de firma utilizados para firmar los registros de facturación y de evento en el caso de que el sistema informático a que se refiere esta declaración responsable no sea utilizado como «VERI*FACTU»:

Dado que se trata de un sistema de facturación que solo puede ser utilizado exclusivamente en la modalidad «VERI*FACTU», no se realiza una firma electrónica expresa de los registros de facturación generados, ya que la normativa considera que quedan firmados al ser remitidos correctamente a los servicios electrónicos de la Agencia Estatal de Administración Tributaria con la debida autenticación mediante el adecuado certificado electrónico cualificado. Por el mismo motivo, el sistema no genera registros de evento.

1.h) Razón social de la entidad productora del sistema informático a que se refiere esta declaración responsable:

GRUPO OPTIPYMIA, S.L.

1.i) Número de identificación fiscal (NIF) español de la entidad productora del sistema informático a que se refiere esta declaración responsable:

B93795219

1.j) Dirección postal completa de contacto de la entidad productora del sistema informático a que se refiere esta declaración responsable:

Calle Tomillar, 16, 4.º A.

28042 – Madrid.

España.

1.k)

La entidad productora del sistema informático a que se refiere esta declaración responsable hace constar que dicho sistema informático, en la versión indicada en ella, cumple con lo dispuesto en el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, en la Orden HAC/1177/2024, de 17 de octubre, y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de dicha orden.

1.l)

• Fecha en que la entidad productora de este sistema informático suscribe esta declaración responsable del mismo: 19 de octubre de 2026.
• Lugar en que la entidad productora de este sistema informático suscribe esta declaración responsable del mismo: Madrid – España.

Firmado: Manuel Gutiérrez San José, administrador único de GRUPO OPTIPYMIA, S.L.

ANEXO

2.a) Otras formas de contacto con la entidad productora del sistema informático a que se refiere esta declaración responsable:

• Correo electrónico: info@optipymia.com

2.b) Direcciones de internet de la entidad productora del sistema informático a que se refiere esta declaración responsable:

• Sitio web de la empresa: https://www.optipymia.com
• Acceso a esta declaración responsable y, cuando las haya, a las declaraciones responsables de las versiones anteriores de este sistema: https://www.optipymia.com/motor-fiscal/declaracion-responsable También se accede desde el menú «Acerca de / Ayuda» de las aplicaciones cliente.

2.c) El sistema informático a que se refiere esta declaración responsable cumple las diferentes especificaciones técnicas y funcionales contenidas en la Orden HAC/1177/2024, de 17 de octubre, y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de dicha orden, de la siguiente manera:

Además del modo que es de obligado cumplimiento en ciertos casos (como el algoritmo de huella a emplear), otras implementaciones utilizadas son:

Expedición, generación y encadenamiento de los registros

• Empleo de la tecnología transaccional del sistema gestor de base de datos (PostgreSQL) para consolidar en una sola unidad transaccional la numeración y expedición de la factura, la generación de su registro de facturación y su alta en la cola de remisión. Si cualquiera de ellas falla, no se escribe ninguna.
• Las emisiones de cada obligado tributario se serializan mediante un bloqueo exclusivo por obligado. Así, sus registros se generan de uno en uno y forman una única cadena por obligado, sea cual sea la serie y sea cual sea la aplicación cliente que solicita la factura. Las emisiones de un obligado tributario no bloquean las de otro.
• Antes de generar cada registro, el sistema comprueba el encadenamiento con tres comprobaciones:
  • recalcula la huella del registro anterior con sus datos y comprueba que coincide con la guardada;
  • comprueba que la huella anterior que ese registro lleva es la huella del registro que lo precede;
  • comprueba que la fecha y hora de generación del registro nuevo no es anterior en más de un minuto a la del registro previo.

  Si alguna comprobación falla, se deja constancia en el registro de auditoría y en la consulta de salud del sistema, y la emisión continúa.

• Cada solicitud de expedición lleva una clave de idempotencia. Si la aplicación cliente la repite, por ejemplo tras un fallo de comunicación, el sistema devuelve la factura ya expedida, sin numerar ni registrar otra.

Inalterabilidad y corrección de facturas

• Las facturas, sus líneas y los registros de facturación no se pueden modificar ni borrar:
  • el usuario de base de datos con el que opera el sistema no tiene permisos de modificación ni de borrado sobre esas tablas;
  • hay disparadores en la base de datos que rechazan la modificación y el borrado de las facturas y de los registros de facturación;
  • la interfaz de programación no ofrece ninguna operación de modificación ni de borrado de facturas expedidas.
• El sistema no permite anular facturas expedidas. Cualquier modificación, cancelación o anulación se instrumenta mediante una factura rectificativa, con su registro de facturación de alta. Por eso el sistema no genera registros de facturación de anulación.
• Lo remitido coincide con lo expedido. Al expedir, se guardan los datos del emisor y del destinatario y los datos del sistema informático. El registro se remite con esos datos aunque cambien después los del obligado tributario, los del destinatario o los de la aplicación cliente. El reintento de la remisión de un registro envía el mismo registro, sin alterarlo; el error de datos se corrige con una factura rectificativa.
• Antes de expedir la factura se validan los datos que exige el formato del registro. Si alguno no es válido, la factura no se expide. Se validan, entre otros:
  • el NIF del emisor;
  • la identificación y el nombre del destinatario, obligatorios en las facturas completas y en sus rectificativas y no admitidos en las simplificadas y en sus rectificativas;
  • el límite de importe de las facturas simplificadas;
  • la coherencia de los importes;
  • las fechas;
  • las longitudes de los campos.

  Los códigos de serie solo admiten letras mayúsculas y cifras.

• El documento PDF de la factura se genera a partir de los datos fijados en la expedición. Una vez generado, no cambia.

Identificación del sistema, de la instalación y del obligado tributario

• El nombre, el código identificador y la versión del sistema están definidos en el propio código del sistema, se asignan a la instalación de cada obligado tributario al darlo de alta y se transmiten en cada registro. Ni el obligado tributario ni las aplicaciones cliente los pueden modificar. Si la versión registrada en la instalación no coincide con la del código, la emisión se bloquea.
• Cada obligado tributario recibe al darse de alta un número de instalación propio y único. Cada registro indica que el sistema puede ser usado por varios obligados tributarios (TipoUsoPosibleMultiOT = S) y que esa instalación factura para un solo obligado (IndicadorMultiplesOT = N).
• El sistema determina qué aplicación cliente hace cada solicitud a partir de su credencial de servicio verificada, nunca a partir de los datos que la aplicación envía. Solo actúa sobre los obligados tributarios que el productor ha vinculado a esa aplicación; cualquier otro se trata como inexistente.

Separación entre obligados tributarios y entre aplicaciones cliente

• Todos los datos de un obligado tributario están identificados por su NIF, directamente o a través de la factura o del registro de los que dependen. Las series, las facturas y los registros de facturación llevan además la aplicación cliente que los generó. El acceso a ellos está restringido a tres niveles:
  • en el código, toda consulta se hace con la aplicación cliente de la credencial, y toda operación sobre un obligado tributario comprueba antes que está vinculado a esa aplicación;
  • en la base de datos, una política de seguridad por fila solo devuelve las series, las facturas y los registros de la aplicación cliente de la conexión, y los datos de los obligados tributarios vinculados a ella, aunque la consulta no lo filtre; el usuario de base de datos del sistema no puede saltarse esa política. Solo el propio sistema, para remitir, y la aplicación de administración del productor, que gestiona la representación, acceden a los de todos los obligados;
  • una prueba automática recorre todos los accesos a datos y falla si alguno no filtra.

Remisión de los registros

• La remisión se realiza por servicio web con autenticación mutua mediante el certificado electrónico cualificado del productor. El productor actúa como colaborador social en la aplicación de los tributos, en representación del obligado tributario, al amparo del modelo normalizado de representación que este otorga.
• Control de flujo, por obligado tributario. Entre dos envíos del mismo obligado, el sistema espera el tiempo indicado por la Agencia Estatal de Administración Tributaria en su última respuesta (TiempoEsperaEnvio; 60 segundos hasta la primera). En cada envío agrupa todos los registros pendientes, hasta un máximo de 1.000, en el orden de la cadena.
• Reintento sin límite. Cuando falla la comunicación con la sede electrónica (red, indisponibilidad del servicio o tiempo de espera agotado), el registro permanece pendiente y se reintenta sin límite de intentos, a intervalos crecientes de hasta diez minutos. Los envíos que incluyen registros cuya remisión falló antes por un fallo de comunicación se marcan con la indicación de incidencia. Un proceso periódico de barrido vuelve a programar los registros pendientes cuya remisión no está en curso. El sistema informa a las aplicaciones cliente de los registros que llevan más de una hora pendientes de remitir.
• Los registros rechazados por la Agencia Estatal de Administración Tributaria quedan marcados con el código y la descripción del error, que el sistema pone a disposición de la aplicación cliente para que el usuario corrija el error mediante factura rectificativa. Los aceptados con errores tienen un estado propio. Si la Agencia Estatal de Administración Tributaria responde que un registro ya constaba, el sistema adopta el estado con el que consta.

Remisión sin representación vigente

• El productor solo remite los registros de un obligado tributario mientras la representación de este está vigente. Sin representación vigente:
  • el sistema no expide facturas, tampoco rectificativas, porque todo registro generado debe remitirse;
  • los registros pendientes no se remiten.
• Al registrarse la revocación de la representación, en la misma transacción, el sistema marca como «no remitidos» todos los registros pendientes del obligado tributario y deja de remitirlos. También obtiene la relación de los registros remitidos después de la fecha de efecto de la revocación.
• El sistema informa de esa situación a las aplicaciones cliente: la fecha desde la que no se remiten los registros y el número de registros no remitidos. También permite descargar esos registros tal como se generaron, en un documento XML, en el orden de la cadena, junto con un índice en CSV con la serie, el número, la fecha, el importe y la huella de cada uno. Si se otorga una representación nueva, esos registros se pueden remitir sin alterar el registro, su huella ni su código QR.

Régimen especial de los bienes usados (REBU)

• Las facturas de venta de bienes usados en REBU se expiden en series separadas de las del régimen general, con sus propias series de rectificativas, y comparten la cadena de registros del obligado tributario.
• Cada factura REBU tiene una sola línea y no lleva cuota de IVA repercutida. Su registro de facturación se genera, se encadena y se remite como cualquier otro, con estos valores:
  • ClaveRegimen 03;
  • CalificacionOperacion S1;
  • TipoImpositivo 0,00;
  • CuotaRepercutida 0,00;
  • CuotaTotal 0,00;
  • ImporteTotal igual al precio de venta cobrado.

  La factura impresa lleva la mención «Régimen especial de los bienes usados».

• Las rectificativas de facturas REBU mantienen la ClaveRegimen 03 y, en las rectificativas por sustitución, informan una CuotaRectificada de 0,00. En una factura REBU no se admiten operaciones con inversión del sujeto pasivo.

Inversión del sujeto pasivo

• Las operaciones con inversión del sujeto pasivo se califican S2 y solo se admiten en facturas completas y en sus rectificativas. El destinatario se identifica con su NIF español y su domicilio completo. La factura impresa lleva la mención «Inversión del sujeto pasivo».

Facturas simplificadas y facturas rectificadas expedidas fuera del sistema

• Las facturas simplificadas no llevan destinatario y su importe total no supera 3.000 euros, impuestos incluidos. Se rectifican con facturas rectificativas de tipo R5.
• La rectificativa de una factura expedida fuera del sistema identifica la factura rectificada en su registro de facturación por su número y su fecha de expedición y, en la rectificación por sustitución, por su base imponible y su cuota. Sin esos datos, no se expide.

Fecha de la operación

• Cuando la aplicación cliente indica una fecha de realización de la operación distinta de la fecha de expedición, el registro de facturación la remite (FechaOperacion) y la factura impresa la muestra.

Código QR tributario y documento de la factura

• El código QR se genera conforme a la norma ISO/IEC 18004 con nivel de corrección de errores M y un tamaño de 35 × 35 mm. Contiene la URL del servicio de cotejo de la Agencia Estatal de Administración Tributaria con los cuatro parámetros establecidos (NIF del emisor, número y serie, fecha de expedición e importe total).
• El código QR se imprime una sola vez, en la esquina superior izquierda de la primera página, antes del contenido de la factura. Encima lleva el texto «QR tributario:» y debajo la leyenda «VERI*FACTU», en negro y en un cuerpo de letra no menor que el de ningún otro dato de la factura. Alrededor del código queda una zona libre de al menos 2 mm.
• El documento de la factura lo genera siempre el sistema, con una plantilla por tipo de aplicación cliente y con la marca del obligado tributario (logotipo, colores y textos de pie). La aplicación cliente puede añadir datos informativos que no son fiscales, como la matrícula o los kilómetros del vehículo; esos datos se fijan con la factura. El código QR, las leyendas y las menciones obligatorias los añade el propio sistema, y la aplicación cliente no los puede suprimir ni alterar.

Consulta y exportación de los registros

• El sistema permite consultar en todo momento, para cada obligado tributario y a través de las aplicaciones cliente:
  • cada registro de facturación: su posición en la cadena, su huella y la huella anterior, su estado de remisión, el contenido remitido y la respuesta recibida de la Agencia Estatal de Administración Tributaria;
  • el estado general del sistema para ese obligado: versión, certificado y cola de remisión.
• El sistema genera, a petición, la exportación de todos los registros de facturación de un obligado tributario, tal como se generaron y en el orden de la cadena, con un índice en CSV.

Historial de declaraciones responsables

La declaración vigente es la de la versión 1.0.0, firmada el 19 de octubre de 2026. Las de versiones anteriores se conservan (art. 13.3 del Reglamento) y se enlazarán aquí con el aviso de que están archivadas. Todavía no hay ninguna anterior.