FiveTech Support Forums

Hola a todos,

A ver...

Estoy intentando encontrar la ley/reglamento/real decreto/loquesea en donde se vislumbre como se puede anular una factura.

Si Ustedes, hoy 20/04/2025 deben anular una factura por que se ha hecho mal. ¿Cómo lo hacen?

Muchas gracias,

Si por anular te refieres a borrar (delete) un registro como se borra de una base de datos no se puede. Debes de generar una factura nueva que rectifique la erronea. El término rectificar no se refiere al significado intuitivo que tenemos de modificar. No es modificar. Es generar un nuevo registro enlazado con el original erroneo que en el conjunto de operaciones lo que hace es "rectificar" la factura original erronea. La aeat no quiere que borres nada, todo se queda grabado, permitiendo en una revisión poder ir hacia atrás per secula seculorum.

Si por anular te refieres a borrar (delete) un registro como se borra de una base de datos no se puede. Debes de generar una factura nueva que rectifique la erronea. El término rectificar no se refiere al significado intuitivo que tenemos de modificar. No es modificar. Es generar un nuevo registro enlazado con el original erroneo que en el conjunto de operaciones lo que hace es "rectificar" la factura original erronea. La aeat no quiere que borres nada, todo se queda grabado, permitiendo en una revisión poder ir hacia atrás per secula seculorum.

Durante el día he estado haciendo pruebas, que si doy de alta, que si ahora anulo, que si ahora (la misma factura) la vuelvo a dar de alta (indicando que es una subsanación), la vuelvo a anular, la vuelvo a dar de alta con otro NIF (indicando que es una subsanación), y así.. ya no sé ni que combinaciones he hecho.

Y Veri*factu se lo come con patatas.

Veri*factu parece ser que está para que se le informe de la actividad que se desarrolla entorno a la facturación, después tu haz lo que quieras que si las huellas no coinciden (y Hacienda pierde el control), ya iran a por ti.

Volviendo a la anulación.

Veri*factu la contempla.

Han dejado toda la responsabilidad a los usuarios que no son 'asesores fiscales'.

Los desarrolladores debemos permitir lo que dice la ley/reglamento, y Veri*factu permite anular.

La acción de facturar la hace el usuario, el desarrollador pone los medios que cumplen la ley/reglamento.

Es un "marrón".

Personalmente creo que hay casos que deben ser anulaciones:

-un cliente que tiene 3 empresas y se le ha facturado a la que no toca.

Por comodidad le haría una rectificativa, pero no es correcto y el cliente me lo puede exigir.

El problema está en cómo validar/controlar estos casos.

Revisando las FAQ del SII que indican e intentando aplicar a la lógica VeriFactu

Ejemplo 1: Disminución de la base imponible, Opcion 2 :
La modificación por sustitución supondría emitir una factura con base imponible de -1000 € y una factura rectificativa en la que se indicará que la base imponible es de 800 €.
* 1a. Factura, TipoFactura = F1
Desglose IVA: se indicará el importe que se rectifica con signo contrario (base imponible: (-1.000), cuota repercutida (-210)
* 2a. Factura, TipoFactura = Rx
TipoRectificativa = S
Desglose IVA: se indicará que la base imponible es de 800, cuota repercutida 168

Pueden indicar la diferencia entre aplicar lo anterior y lo siguiente :
* 1a. Anulacion de factura. Se emite factura por parte del SIF en negativo, pero se informa a VeriFactu como registro de anulación, no de alta (F1)
* 2a. Se emite una nueva factura, como alta inicial (F1) con los datos correctos

El procedimiento sería el mismo que el realizado en el SII. A pesar de que comúnmente se hable de anular una factura cuando estamos emitiendo una factura de abono o negativa para contrarrestar una anterior emitida con errores, lo que realmente se está realizando es emitir una nueva factura de tipo F1 con importes negativos.

Por lo cual, en VERIFACTU se realizaría el mismo proceso que en el SII:

1. Emisión de factura con importes negativos. Su registro de facturación será una alta inicial de tipo F1 con los importes negativos que correspondan.

2. Emisión de factura rectificativa. Su registro de facturación será una alta inicial de tipo RX con los importes que correspondan.


La generación de un RF de anulación está pensado como una forma ágil de dejar constancia que una factura expedida por error (siempre y cuando el ROF no obligue a actuar de otra forma, mediante facturas rectificativas) no debería haberse expedido y, por tanto, que dicha factura no tiene validez y no ha de tenerse en cuenta. Esta forma de actuar (cuando sea posible) no implica la expedición de nuevas facturas que "contrarresten o compensen" la factura expedida por error. No obstante, siempre prima el procedimiento establecido por el reglamento de obligaciones de facturación (un posible factor a tener en cuenta también es si la factura que se plantea anular se ha entregado o no al cliente). Por lo tanto, las anulaciones deberían ser casos excepcionales.

1. El tratamiento que damos en nuestro SIF/ERP, es decir, cualquier factura emitida, entendiento por emitida cuando ya se ha numerado/fechado y no son modificables. El reglamento de facturación especifica que hay que conservar las facturas incluso si son erróneas
2. La información enviada a la AEAT, que puede ser en forma de registro en negativo o de anulación. Para determinar que sea una anulación, personalmente voy a considerar estos 2 criterios :
   • No se ha impreso/generado PDF, no se ha entregado al cliente
   • No ha transcurrido más de 1 dia desde la fecha factura a la fecha de anulación. Es decir, la anulacion sólo para casos de errores inmediatos (el cliente rechaza la venta en el mismo momento de realizarse, la venta nunca ha existido, etc) casos muy puntuales y excepcionales

Verhoven wrote: 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.

Verhoven wrote: Te dejo el enlace de la propia aeat: https://sede.agenciatributaria.gob.es/Sede/procedimientoini/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: 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.

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

paquitohm wrote: 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.

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: verifactu@correo.aeat.es

[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]