España: Normativa sancionadora sistemas informáticos

FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

Verhoven wrote: Mon Jun 02, 2025 6:35 am Si tiene dudas sobre el nuevo sistema o la factura electrónica, es el momento de resolverlas. Dispone de más de un año para encontrar un programa informático homologado, conocer la plataforma de la Agencia Tributaria o los formatos aceptados para la transmisión de datos.
Esto de 'programa informático homologado...', pués...:
Homologar: Dicho de una autoridad: Contrastar el cumplimiento de determinadas especificaciones o características de un objeto o de una acción.

Entonces ¿Debe haber 'alguién' que homologue al programa informático? Creo que no es así.
¿Hay algùn documento que diga que el progama informático está homologado? ¿Quién lo emite?

Es que estoy un poco... como decirlo educadamente...

Nadie va a homologar nada.

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

Verhoven
Posts: 565
Joined: Sun Oct 09, 2005 7:23 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by Verhoven »

Te dejo el enlace de la propia aeat: https://sede.agenciatributaria.gob.es/S ... FZ01.shtml

Es que son muchas las normas que afectan a la informática...
Me parece que el concepto subyacente, por resumirlo, es que cualquier ordenador que se use para gestión, facturación y/o contabilidad sean como una terminal de la aeat. Ya hay procesos, por ejemplo los impuestos especiales, donde la contabilidad de las existencias no se lleva en los ordenadores de los particulares o empresas, se llevan en los de la aeat. Para estos impuestos, la ley ya establece que la única contabilidad válida es la que consta en la aeat (aduanas), si tu mantienes una en tu ordenador es solo una réplica de aquella con menús más o menos amigables que los de la aeat, pero no sirve para nada. El resto de impuestos llevan el mismo camino y con el dinero digital pretenden cerrar el círculo. Saquen ustedes sus propias conclusiones.
FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

Verhoven wrote: Mon Jun 02, 2025 11:07 am Te dejo el enlace de la propia aeat: https://sede.agenciatributaria.gob.es/S ... FZ01.shtml

Es que son muchas las normas que afectan a la informática...
Me parece que el concepto subyacente, por resumirlo, es que cualquier ordenador que se use para gestión, facturación y/o contabilidad sean como una terminal de la aeat. Ya hay procesos, por ejemplo los impuestos especiales, donde la contabilidad de las existencias no se lleva en los ordenadores de los particulares o empresas, se llevan en los de la aeat. Para estos impuestos, la ley ya establece que la única contabilidad válida es la que consta en la aeat (aduanas), si tu mantienes una en tu ordenador es solo una réplica de aquella con menús más o menos amigables que los de la aeat, pero no sirve para nada. El resto de impuestos llevan el mismo camino y con el dinero digital pretenden cerrar el círculo. Saquen ustedes sus propias conclusiones.
Verhoven wrote: Mon Jun 02, 2025 11:07 am Me parece que el concepto subyacente, por resumirlo, es que cualquier ordenador que se use para gestión, facturación y/o contabilidad sean como una terminal de la aeat.
Eso es una opinión como la mía, no un hecho.
Eso no requiere de homologación, "si lo envías mal te lo rechazo" (como hace Veri*factu), no necesita nada más.
"Pero procura que las liquidaciones cuadren con la información que tengo yo, si no iré a por ti".

Pero de Veri*factu no hay nada respecto de la homologación.
La factura electrónica ya existe y se usa en las operaciones con las administraciones (si no estoy equivocado).
Y de momento no está ni publicado el reglamento para el resto de operaciones/mortales.

Si hablan de homologar aplicaciones, levantaran muchas ampollas.
No sé si los programas de las gestorías que presentan la 'renta' (estas semanas estará muy de moda) 'sufren' de esta homologación.

Por favor, que alguién con conocimiento de causa me desmienta, a ver si estoy equivocado y no lo sé.

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

paquitohm
Posts: 318
Joined: Fri Jan 14, 2022 8:37 am

Re: España: Normativa sancionadora sistemas informáticos

Post by paquitohm »

Buenos días,

La que en ese texto llaman "homologados" quizas simplemente lo hagan de manera genérica: "Bastará" una declaracion responsable para dar por "homologado" el software vf.

Salu2
FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

paquitohm wrote: Tue Jun 03, 2025 5:38 am La que en ese texto llaman "homologados" quizas simplemente lo hagan de manera genérica: "Bastará" una declaracion responsable para dar por "homologado" el software vf.
Si, seguramente se trata de eso.

Pero es que hay mensajes, propaganda, anuncios en periódicos, etc. que juegan a 'asustar' (o buscar un prestigio que está por ver), con esto de la 'homologación'.

Y a mi me esto me cabrea, por qué es mentir al cliente/consumidor.
Vaya por delante que yo no me gano los desayunos ni mucho menos la vida con Veri*factu, ni me la ganaré.

En mi caso, VeFa32, que es un aplicativo (gratis sin limitaciones) que está destinado a abarcar el 80% (incluso creo que más) de las operaciones con factura que se hacen (quitando grandes facturadores), no va a estar homologado, NADIE lo va a homologar ni a VeFa32 ni a NINGÚN otro software parecido o un SIF.

Hacienda no va a homologar estos software, Hacienda obliga a cumplir unos requisitos pero no homologa estos software.
Si alguién ha leído algo al respecto publicado por Hacienda, le agradeceré lo publique.

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

gmart1
Posts: 84
Joined: Wed Oct 24, 2007 12:48 pm
Location: Alhaurin de la Torre (MALAGA)

Re: España: Normativa sancionadora sistemas informáticos

Post by gmart1 »

Hola, yo hice una consulta a la aeat para saber qué rellenaba en el campo "IDSistemaInformatico" que aparece en el formato de los XML de VeriFactu.
Quería saber si me daba de alta como desarrollador y me suministraban un ID.
Su repuesta fue la siguiente
Buenos días:

No es necesario realizar ningún proceso de alta como desarrollador. En concreto, el campo "IdSistemaInformatico" es un código que deben establecer ustedes de dos posiciones de longitud. Le facilitamos la información completa al respecto:

CÓMO IDENTIFICAR UN SIF. QUÉ SE CONSIDERA SIF Y NÚMERO DE INSTALACIÓN, Y CÓMO IDENTIFICARLOS. SIF QUE GESTIONAN MÁS DE UNA FACTURACIÓN.

Un SIF responde a la definición dada en el artículo 1.2 del reglamento de requisitos de los sistemas informáticos de facturación (RRSIF), aprobado por el RD 1007/2023 y, básicamente, viene determinado por el funcionamiento y comportamiento que realice y su posible interrelación con otros sistemas (dentro de una determinada arquitectura informática empleada).

Resumidamente, un SIF expide (o gestiona/dirige/controla la expedición de) facturas –con su QR tributario incluido– de forma autónoma e independiente (aunque se puede apoyar en servicios externos que invoque), a la vez que “simultáneamente” genera (o gestiona/dirige/controla la generación) y remite o conserva (o gestiona/dirige/controla la remisión o conservación) sus correspondientes registros de facturación (RF).

Un SIF se identifica universalmente por la “concatenación” de tres campos: Id.OEF (NIF) + Id.SIF (código de 2 posiciones dado por el fabricante a su producto SIF) + NºInstalación(*). Otro dato importante que caracteriza al SIF es su versión, pero un cambio en dicha versión (cuando se actualiza, por ejemplo) no significa que el SIF pase a ser otro SIF con identificación distinta, cosa que sí ocurre con los otros 3 campos mencionados.

(*) El Nº de instalación es una forma de completar una identificación unívoca de cada SIF -por si tuviera varios- de un mismo OEF, y así distinguirse de cualquier otro SIF de ese OEF en cualquier momento del tiempo (pasado, presente o futuro). Como dice su definición en el anexo de la Orden HAC/1177/2024, de 17 de octubre, y en el documento de diseños de registros que está publicado en la web de desarrolladores de la Agencia Tributaria, no puede repetirse nunca: por ejemplo, incluso si se formatea el ordenador donde estaba instalado un SIF y se reinstala el mismo software de nuevo en ese mismo ordenador, el nuevo SIF así constituido debe llevar otro nº de instalación diferente al anterior que tenía, y que no coincida con la de ningún otro SIF de ese OEF (pasado, presente o futuro).

Por ello, como valores recomendados de número de instalación, se propone alguno de los dos siguientes, ya que, en principio, ambos garantizarían que no haya coincidencias con ninguna otra instalación (pasada, presente o futura) de SIF de ese OEF:

- “Timestamp” (al menos fecha+hora+minuto+segundo) en que se efectuó la instalación del producto de facturación (momento en el cual se constituye como SIF).

- Asignar un nº secuencial (por ejemplo, el típico “autonumérico” generado dentro de la organización del OEF) que no se repita nunca entre las distintas instalaciones de los diferentes SIF para ese OEF: 1, 2, 3... n.

Ha de tenerse en cuenta que si se utiliza un SIF que permite llevar distintas facturaciones, como contempla el artículo 7.a) del RRSIF, cada una de esas facturaciones distintas (sean de distintos OEF o del mismo OEF pero de distintos centros de facturación independientes, como tiendas) debe tener un nº de instalación propio y distinto al resto (pasado, presente o futuro) porque se consideran SIF independientes, como si fueran “SIF virtuales”, dentro de un producto SIF más completo que los gestiona y administra.

También relacionado con este asunto de SIF que permiten gestionar distintas facturaciones, en el caso de SIF en la nube, tipo SaaS (Software as a Service), que se ofrecen a muchos usuarios, los cuales, a su vez, pueden gestionar distintas facturaciones, sean del mismo OEF (por ejemplo, tiendas distintas) o de distintos OEF (por ejemplo, una gestoría que lleva la facturación de distintos OEF), se aclara a continuación cuándo poner el valor “S” en el campo ‘IndicadorMultiplesOT’ del bloque ‘SistemaInformatico’ de los registros de facturación y de evento: este valor deberá calcularse de forma independiente por cada usuario del SIF SaaS (no a nivel global del SIF SaaS) y se informará con “S” en todos los registros de facturación (y, en su caso, de evento) de aquellos usuarios que tengan creadas más de una facturación en el SIF SaaS, independientemente del estado de dichas facturaciones (alta, baja…) y de si son de igual o de distinto OEF. En caso contrario, o sea, cuando el usuario solo tiene una facturación en el SIF SaaS, se informará con “N”.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]
No parece que vayan a hacer un control exhaustivo, más bien cuando realicen una inspección a una empresa, localizarán el NIF que ha desarrollado el SIF y le harán una revisión completa al sistema que envía los datos a Verifactu.
Verhoven
Posts: 565
Joined: Sun Oct 09, 2005 7:23 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by Verhoven »

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]
User avatar
VictorCasajuana
Posts: 317
Joined: Wed Mar 28, 2018 4:38 pm
Location: Vinaròs
Contact:

Re: España: Normativa sancionadora sistemas informáticos

Post by VictorCasajuana »

Verhoven wrote: Tue Jul 22, 2025 3:14 pm 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 )
--------
¿ Y porque no ?
¿ And why not ?
FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

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.

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

"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'.

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

User avatar
VictorCasajuana
Posts: 317
Joined: Wed Mar 28, 2018 4:38 pm
Location: Vinaròs
Contact:

Re: España: Normativa sancionadora sistemas informáticos

Post by VictorCasajuana »

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.
--------
¿ Y porque no ?
¿ And why not ?
FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

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,

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

Verhoven
Posts: 565
Joined: Sun Oct 09, 2005 7:23 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by Verhoven »

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/ ... ooAAAA=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.
FiveWiDi
Posts: 1467
Joined: Mon Oct 10, 2005 2:38 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by FiveWiDi »

Verhoven wrote: Tue Sep 16, 2025 8:39 am 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/ ... ooAAAA=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.
Hola Verhoven,

Básicamente dice que para la DGT no existe el término 'transacción', y por tanto con lo establecido en el artículo 12 de la LGT, nos remite al Código Civil para poder decir que sería/se entendería por una 'transacción'.

*******************************************************
Extraído de la respuesta que han dado, está al final.
"Pues bien, en los textos normativos anteriores no existe una definición jurídica de qué se entiende por transacción.
Una vez sentado lo anterior, resulta preciso indicar lo dispuesto en el artículo 12 de la LGT sobre la interpretación de las normas tributarias:
1. Las normas tributarias se interpretarán con arreglo a lo dispuesto en el apartado 1 del artículo 3 del Código Civil.
2. En tanto no se definan por la normativa tributaria, los términos empleados en sus normas se entenderán conforme a su sentido jurídico, técnico o usual, según proceda.
(…)
Por su parte, el apartado 1 del artículo 3 del Código Civil dispone lo siguiente:

Artículo 3.

1. Las normas se interpretarán según el sentido propio de sus palabras, en relación con el contexto, los antecedentes históricos y legislativos, y la realidad social del tiempo en que han de ser aplicadas, atendiendo fundamentalmente al espíritu y finalidad de aquellas”.

Por tanto, debe tenerse en cuenta que la finalidad última de los artículos 29.2.j) y 201 bis de la LGT es impedir o dificultar la producción, comercialización, uso o simple tenencia de programas y sistemas informáticos que permitan la manipulación u ocultación de datos contables, de facturación y de gestión.

En este sentido, con carácter general, no existe una definición jurídica o técnica del término “transacción”. Por tanto, habrá que acudir a su significado usual de conformidad con la finalidad última mencionada, a la cual se dirige el régimen normativo.

Así, la acepción 2 del diccionario de la RAE señala que “transacción” es “trato, convenio, negocio”. Ello unido a la finalidad indicada, así como la propia redacción del artículo 29.2.j) de la LGT cuya indemnidad supone el bien jurídico protegido del artículo 201 bis del mismo texto legal, hace que se interprete el término “transacción” como cualquier operación de negocio que sea objeto de registro en un sistema o programa informático o electrónico que soporte los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas.

Conforme a lo anterior, a título de ejemplo y con carácter enunciativo y no limitativo, en el caso de sistemas informáticos utilizados para soportar los procesos contables, podría considerarse como “transacción” cualquier anotación contable en los libros de contabilidad obligatorios (diario, mayor…) o auxiliares; en el caso de sistemas informáticos utilizados en los procesos de facturación, sería cualquier operación de entrega de bienes o prestación de servicios que se documente mediante factura; y si fueran sistemas utilizados para soportar los procesos de gestión empresarial de cualquier otra naturaleza, podría ser toda anotación de datos resultantes de la actividad desarrollada, tales como la gestión de stocks y pedidos, gestión de albaranes, gestión de pagos y cobros, gestión financiera y gestión de personal, etc."
*******************************************************

En nuestro caso interpreto que se entendería que 'transacción' es 1 operación comercial (factura, emisión, impresión y entrega), contablemente sería un asiento contable.

Es que primero te meten toda la legislación en la que se basaran para responder y al final dicen lo que es.

Feliz Veri*factu!!!

Un Saludo
Carlos G.

FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home

Verhoven
Posts: 565
Joined: Sun Oct 09, 2005 7:23 pm

Re: España: Normativa sancionadora sistemas informáticos

Post by Verhoven »

Ya que estamos con la IA y aunque, para no asumir responsabilidades, termina por decir que hay que recurrir a un asesor fiscal, os dejo el resultado de un ratito que he estado consultándola.

https://grok.com/share/bGVnYWN5_75b1ec6 ... 01da77def5

Creo que os será de utilidad. Atentos a los importes ... de las sanciones.
Post Reply