FiveTech Support Forums

Verhoven wrote: Estamos, en algunos casos, planteando la cuestión de seguir utilizando los sistema de facturación existentes, muchas veces bien probados, robustos
y funcionales y enlazar con algún programa, que puede ser incluso de otro fabricante de software, para hacer la parte verifactu. En este sentido,
le he pasado a la IA grok la cuestión y quiero compartir con vosotros la respuesta porque no me deja tranquilo. De hecho, vista la respuesta que da creo este esquema de funcionamiento que no sería seguro del todo, puesto que, la aplicación original existente y en uso NO está diseñada conforme a la nueva normativa de aplicación y esto podría llevar a decir a la AEAT que no cumple, la parte antigua, y que por lo tanto el sistema no cumple, con lo cual 150.000 euros de multa por cada programa instalado para el productor de software y 50.000 euros para cada usuario, todo ello por cada ejercicio fiscal.

En consecuencia, parece que no quedaría más remedio que meter mano en el código existente para adaptarlo a verifactu, o arriesgarse a unas consecuencias de ruina.

Os copio la respuesta de Grok:

[Para determinar si el esquema de facturación descrito, en el que un **primer programa de facturación** (de un productor de software) genera las facturas y las envía mediante ficheros de intercambio de datos a un **segundo programa** (de otro fabricante) que remite los registros a la **AEAT** en modalidad **VERI*FACTU**, es conforme a la legislación española, debemos analizar si cumple con los requisitos establecidos en el **Real Decreto 1007/2023**, la **Orden HAC/1177/2024**, y las disposiciones relacionadas de la **Ley General Tributaria** y el **Real Decreto 1619/2012**. A continuación, evalúo el esquema paso a paso:

### Análisis del esquema propuesto
1. **Primer programa (generación de facturas)**:
- Este programa, desarrollado por el primer fabricante, es el encargado de **generar las facturas** (completas o simplificadas) y los **registros de facturación** (de alta o anulación).
- **Requisitos que debe cumplir** según la normativa VERI*FACTU:
- **Integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad**: Los registros de facturación generados deben cumplir con estos principios (artículo 29.2.j de la Ley General Tributaria). Esto implica que no se puedan alterar sin dejar rastro y que se mantengan disponibles durante el plazo de prescripción (4 años, salvo excepciones).
- **Formato estandarizado**: Los registros deben generarse en el formato especificado en el Anexo de la Orden HAC/1177/2024, incluyendo datos como NIF del emisor, número y serie de factura, fecha de expedición, importe total, etc.
- **Código QR**: Las facturas emitidas deben incluir un código QR con información parcial de la factura, conforme a las especificaciones técnicas.
- **Registro de eventos**: El programa debe mantener un registro de eventos que documente acciones relevantes (como modificaciones o accesos) con los mismos requisitos de seguridad.
- **Prohibición de software de doble uso**: El programa no debe permitir la manipulación u ocultación de datos contables, según la Ley 11/2021.
- **Certificación**: El fabricante debe emitir una **declaración responsable** certificando que el programa cumple con la normativa VERI*FACTU.

- **Aspecto crítico**: Dado que este programa no envía directamente los registros a la AEAT, sino que los transfiere a otro programa, debe garantizar que los ficheros de intercambio de datos mantengan la **integridad y trazabilidad** de los registros. Esto incluye:
- Uso de mecanismos de seguridad (como firma electrónica o hash) para evitar alteraciones durante la transferencia.
- Formato de intercambio compatible con las especificaciones técnicas de VERI*FACTU.

2. **Segundo programa (remisión a la AEAT)**:
- Este programa, desarrollado por el segundo fabricante, recibe los ficheros de intercambio de datos y se encarga de **remitir los registros de facturación a la AEAT** en modalidad VERI*FACTU.
- **Requisitos que debe cumplir**:
- **Envío automático e inmediato**: Debe enviar los registros a la AEAT en el momento de la generación de la factura, utilizando los protocolos de comunicación segura establecidos por la Orden HAC/1177/2024.
- **Integridad y autenticidad**: Debe garantizar que los registros recibidos del primer programa no han sido alterados y que se envían a la AEAT en el formato correcto, manteniendo la trazabilidad.
- **Código QR y leyenda VERI*FACTU**: Aunque el primer programa genera las facturas con el código QR, el segundo programa debe verificar que estas cumplen con los requisitos (por ejemplo, que el código QR contiene la información correcta) y, si es necesario, añadir la leyenda “Factura verificable en la sede electrónica de la AEAT” o “VERI*FACTU” en los casos aplicables.
- **Registro de eventos**: También debe mantener un registro de eventos para las acciones relacionadas con la recepción y envío de datos.
- **Certificación**: El segundo fabricante debe emitir una **declaración responsable** certificando que su programa cumple con las especificaciones de VERI*FACTU para la remisión de datos.
- **Cumplimiento con protección de datos**: Si los ficheros incluyen datos personales, el programa debe cumplir con el **RGPD** y la **Ley Orgánica 3/2018**.

3. **Interoperabilidad entre ambos programas**:
- La normativa exige que los sistemas sean **interoperables** y utilicen formatos estándares para garantizar la coherencia y seguridad de los datos transferidos. Los ficheros de intercambio deben:
- Ser compatibles con el formato estandarizado de registros de facturación (Anexo de la Orden HAC/1177/2024).
- Incluir mecanismos de seguridad (como firma electrónica o hash) para garantizar que los datos no se alteren durante la transferencia.
- Permitir la trazabilidad completa desde la generación de la factura hasta su envío a la AEAT.
- Ambos programas deben estar diseñados para evitar cualquier manipulación no autorizada de los datos, cumpliendo con la prohibición de software de doble uso (Ley 11/2021).

4. **Certificación conjunta**:
- Ambos fabricantes deben emitir **declaraciones responsables** que certifiquen que sus respectivos sistemas cumplen con la normativa VERI*FACTU. En este caso:
- El primer fabricante certifica que su programa genera facturas y registros conformes.
- El segundo fabricante certifica que su programa recibe y remite los registros a la AEAT de forma segura y conforme.
- La AEAT no exige que un único sistema realice todo el proceso (generación y envío), por lo que este esquema de dos programas es válido siempre que ambos cumplan con los requisitos y la interoperabilidad esté garantizada.

5. **Cumplimiento de plazos**:
- Los productores de ambos programas deben tener sus sistemas adaptados antes del **29 de julio de 2025** (plazo de nueve meses desde la entrada en vigor de la Orden HAC/1177/2024).
- Los usuarios (empresas o autónomos) deben implementar el sistema completo antes del **1 de enero de 2026** (para contribuyentes del Impuesto sobre Sociedades) o del **1 de julio de 2026** (para el resto de obligados).

### Evaluación de conformidad
El esquema descrito es **conforme a la legislación VERI*FACTU** siempre que se cumplan las siguientes condiciones:
- El **primer programa** genera facturas y registros de facturación que cumplen con los requisitos de **integridad, trazabilidad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad**, e incluye un **código QR** en las facturas, conforme al formato estandarizado especificado en la Orden HAC/1177/2024.
- Los **ficheros de intercambio de datos** mantienen la integridad y trazabilidad de los registros mediante mecanismos de seguridad como firma electrónica o hash, y son compatibles con el formato requerido.
- El **segundo programa** recibe los registros, los valida y los remite automáticamente a la AEAT en cumplimiento con las especificaciones técnicas de VERI*FACTU, asegurando que los datos no han sido alterados y que se envían de forma inmediata y segura.
- Ambos programas mantienen un **registro de eventos** que documenta las acciones relevantes, con los mismos requisitos de seguridad que los registros de facturación.
- Ambos fabricantes emiten una **declaración responsable** certificando que sus sistemas cumplen con la normativa.
- Los programas no incluyen funcionalidades que permitan manipular u ocultar datos contables, conforme a la Ley 11/2021.
- Si los ficheros contienen datos personales, ambos programas cumplen con el **RGPD** y la **Ley Orgánica 3/2018** de Protección de Datos.

### Aspectos críticos a verificar
- **Interoperabilidad**: Los ficheros de intercambio deben estar en un formato que garantice la compatibilidad entre ambos programas y con los requisitos de VERI*FACTU. Cualquier error en la transferencia (por ejemplo, pérdida de integridad o alteración de datos) podría hacer que el sistema no sea conforme.
- **Seguridad en la transferencia**: Los ficheros deben incluir mecanismos (como firma electrónica o hash) para garantizar que los datos no se modifiquen durante el intercambio entre los programas.
- **Trazabilidad completa**: El sistema debe permitir rastrear todo el proceso, desde la generación de la factura en el primer programa hasta su envío a la AEAT por el segundo programa, sin lagunas en la cadena de custodia de los datos.
- **Certificación de ambos fabricantes**: Cada fabricante debe certificar que su software cumple con la normativa, y el usuario debe asegurarse de que ambos programas estén correctamente integrados.

### Conclusión
El esquema descrito es **conforme a la legislación VERI*FACTU** siempre que ambos programas cumplan con los requisitos técnicos y funcionales establecidos en la normativa, especialmente en lo que respecta a la generación, transferencia y envío de registros de facturación de forma segura, trazable e inalterable. La clave está en garantizar la **interoperabilidad** entre los dos programas y en que cada uno cumpla con su parte del proceso (generación y remisión) conforme a las especificaciones de la Orden HAC/1177/2024 y el Real Decreto 1007/2023. Además, ambos fabricantes deben emitir sus respectivas declaraciones responsables, y el sistema debe estar operativo dentro de los plazos establecidos (29 de julio de 2025 para productores, y 1 de enero o 1 de julio de 2026 para usuarios, según corresponda).

Si tienes detalles específicos sobre los programas (por ejemplo, nombres, formatos de los ficheros o mecanismos de seguridad utilizados), puedo ayudarte a evaluar con mayor precisión si el esquema cumple con todos los requisitos./quote]

Independientemente de si tu programa envía a verifactu o lo hace por otro sistema, deberá cumplir con los requisitos de encadenamiento, inalterabilidad, log de cambios, etc...
Después de aplicar Verifactu a mi software, el tema del envío y recepción de datos a hacienda habrá sido un 15% del tiempo total empleado para adaptar el programa de facturación a toda la normativa ( evitar modificar / borrar facturas, anulado de facturas, encadenamiento, detección de cambios por programas externos, revisar todos los procesos que generan facturas, y varios etcéteras más )

Hola,

Yo veo 2 procedimientos a implantar:

1-Adaptar el SIF para enviar a Veri*factu.

2-Adaptar el SIF a lo que permite ya la normativa ACTUAL (de hace años); hay muchísimos SIF que no la cumplen y permiten realizar cosas 'ilegales'; pero esta 'ilegalidad' no llega a hacienda y poco le importa por que la mayoría que hace cosas 'ilegales' no defrauda.

Por ejemplo la famosa corrección (abono, anulación, aplicación de descuento, etc) de una factura ya emitida pero aún no declarada en la declaración del IVA trimestral.

Hoy en día existen programas que no son SIF pero se dedican a enviar información a Veri*factu, los hay de pago y alguna otra que no.

Yo creo que vale la pena estudiar esta posibilidad.

Si convence, es cuestión de:

• abordar el punto 2 y seguir con el Segundo Software (el enviador)

o - abordar el punto 2 y mientras se utiliza el Segundo Software desarrollar nuestro propio enviador.

o - empezar de '0' con todo.

Por oro lado:

Envío automático e inmediato

El envío no tiene por que ser inmediato, AEAT da margen para el envío (e incluso puede forzar un retraso de nuestro próximo envío); de hecho si lo envías y el error es 2004 (creo recordar), no precisa subsanación (esto lo he recibio de consulta a hacienda).

Código QR y leyenda VERI*FACTU: Aunque el primer programa genera las facturas con el código QR, el segundo programa debe verificar

 que estas cumplen con los requisitos (por ejemplo, que el código QR contiene la información correcta)

Esto tampoco es cierto, el encargado de la generación del QR es el SIF, y los datos que debe enviar al 'Segundo programa' es responsabilidad suya. El 'enviador' sólo envía y valida ciertas cosas, pero nunca podrá saber si el QR impreso por el SIF en la factura se corresponde con los datos que el propio SIF le ha proporcionado.

AI aún está aprendiendo.

"En consecuencia, parece que no quedaría más remedio que meter mano en el código existente para adaptarlo a verifactu, o arriesgarse a unas consecuencias de ruina."

Esto con un Segundo Software lo puedes tener en 1 día. Es cuestión de pasarle los datos que te pida este segundo Software.

Me preocupa más el SIF, hay que 'cerrar muchas puertas'.

yo estoy con la opción 1, y con lo de "cerrar muchas puertas" confirmas lo que he indicado anteriormente, por mi parte ha sido un 15% de adaptación a Verifactu y un 85% de adaptación del SIF cerrando todas las puertas, ventanas, alcantarillas, etc... Ha sido un buen curro.

El tema de un segundo programa, pues es una muy buena solución para empresas que realizan programación a medida y tienen un software por cada cliente, en este caso el tema del segundo programa es una solución excelente.

Hola a todos,

Estoy con la Declaración responsable y en el ejemplo de la AEAT uno de los párrafos del punto 2.c dice:

"- Existe la posibilidad de elegir una forma especial que permite entrar en la aplicación de facturación de tal manera que solo se da acceso a la información con trascendencia tributaria, ocultando o impidiendo el acceso a la posible información confidencial de carácter no patrimonial, de forma que la Administración tributaria pueda acceder directamente a la consulta y al resto de funcionalidades exigidas sobre la información de los registros de facturación y de eventos. En este caso se ha implementado mediante un control tipo “check” que puede ser seleccionado (por defecto no lo está) antes de entrar en la aplicación."

Esto... se dice en la Ley o el Reglamento de Veri*factu?

Se debe dar acceso a la AEAT a nuestro SIF?

¿Me he perdido algo?

ME RESPONDO

Si lo dice la Ley.

Muchas gracias,

Verhoven wrote: Os dejo un link que hace referencia a una consulta vinculante hecha por una empresa que produce software de gestión:

https://cissactualidad.ciss.es/Content/Documento.aspx?params=H4sIAAAAAAAEAMtMSbF1jTAAAiNzY2NLS7Wy1KLizPw8WyMDI1MDSwMjtdLi1CJbd3dLU3MzU1-XILWCxOLictsw4yhLpzCQ6sy0Spf85JDKglTbtMSc4lS13MSSEqAWN89gZ0cfKM87tdLW1zHENcjTUS2z2LGgoCi_LDUFaomhmYGFsREAuc8IhooAAAA=WKE

La respuesta de la aeat es un galimatías que se presta a todo tipo de interpretaciones. Si alguien, con conocimientos jurídicos, lo entiende, que tenga la amabilidad de explicarlo.

Buenos días Álvaro,

He preferido contestarte aquí por no desdoblar más el asunto.

En principio cada software debe de cumplir, por lo que si hay varios procesos, que se van concatenando, cada uno debe de tener su certificación.

Lo de las sanciones, que van de 50.000€ a 150.000€, no es así exactamente. Los 150.000€ es lo que aplica al que produce el software y también al que lo comercializa -a cada uno de los dos, no a uno u otro- y los 50.000€, por cada ejercicio (que se podría poner en 200.000€) es al usuario, por cada programa que use que la inspección considerara que no cumple. Por lo que tu cliente podría repercutirte a ti el importe que le impusiera la inspección a él por tu programa, con lo que se te podría poner, por cada instalación, en 800.000 euros. Ver art. 201.bis de la LGT.

Tened en cuenta que las sanciones son de ruina, carentes de proporcionalidad, porque no dependen de la cifra de negocios (las ventas) y son, no por cometer un fraude, sino por la posibilidad de cometerlo. Es como sancionar al fabricante de cuchillos de cocina, al de la tienda que te los vende y a ti, que lo usas para cortar el queso en la cocina, porque con ese cuchillo se puede matar a alguien. Se sanciona por la posibilidad cometer un fraude no por la comisión del mismo.

Lo de las API no termino de verlo claro porque cada software, debe en sí mismo de cumplir y éstas lo único que hacen es de pasarela de envío de datos (facturas) a la administración, después de eso, que dentro de lo que exigen las normas creo que es lo más fácil, ya no asumen nada.

De momento he pedido un dictamen jurídico.

Verhoven wrote: Buenos días Álvaro,
He preferido contestarte aquí por no desdoblar más el asunto.

En principio cada software debe de cumplir, por lo que si hay varios procesos, que se van concatenando, cada uno debe de tener su certificación.
Lo de las sanciones, que van de 50.000€ a 150.000€, no es así exactamente. Los 150.000€ es lo que aplica al que produce el software y también al que lo comercializa -a cada uno de los dos, no a uno u otro- y los 50.000€, por cada ejercicio (que se podría poner en 200.000€) es al usuario, por cada programa que use que la inspección considerara que no cumple. Por lo que tu cliente podría repercutirte a ti el importe que le impusiera la inspección a él por tu programa, con lo que se te podría poner, por cada instalación, en 800.000 euros. Ver art. 201.bis de la LGT.

Tened en cuenta que las sanciones son de ruina, carentes de proporcionalidad, porque no dependen de la cifra de negocios (las ventas) y son, no por cometer un fraude, sino por la posibilidad de cometerlo. Es como sancionar al fabricantes de cuchillos de cocina, al de la tienda que te los vende y a ti que lo usas para cortar el queso en la cocina porque con ese cuchillo se puede matar a alguien. Se sanciona por la posibilidad cometer un fraude no por la comisión del mismo.

Lo de las API no termino de verlo claro porque cada software, debe en sí mismo de cumplir y éstas lo único que hacen es de pasarela de envío de datos (facturas) a la administración, después de eso, que dentro de lo que exigen las normas creo que es lo más fácil, ya no asumen nada.

De momento he pedido un dictamen jurídico.

Buenas tardes

Tengo mis dudas, de que se vaya aplicar la nueva normativa de VeriFactu, más control a las empresas y gastos,

Un saludo

Gabriel