VeriFactu in Spain: obligation, 2027 deadlines
VeriFactu in Spain: what German companies with a subsidiary or branch need to prepare now
VeriFactu is mandatory for Spanish companies that create their invoices using software: companies subject to corporate income tax must use compliant invoicing systems from 1 January 2027, all others from 1 July 2027. This also affects Spanish subsidiaries and branches of German corporate groups.
Many corporate groups headquartered in Germany have legally independent companies in Spain, such as a subsidiary, a permanent establishment with its own invoicing or a local sales company. It is precisely these Spanish companies that are affected by the Spanish regulations for invoicing IT systems, even if the ERP is operated centrally in Germany. What matters is that the Spanish company issues invoices under Spanish law and uses software to do so.
At the heart of this are the Sistemas Informáticos de Facturación, or SIF for short. These are invoicing IT systems that create invoices and, in doing so, must generate standardised invoicing records, including mechanisms for integrity and traceability. VeriFactu is an operating mode within this framework in which the generated invoicing records can be transmitted to the Spanish tax authority AEAT. (Source: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html)
Deadlines: obligation postponed by one year, now 2027
The most important planning change for 2026 projects is the one-year postponement. Following the publication of Real Decreto-ley 15/2025, the adjustment deadlines for using SIF that meet the requirements were postponed to 2027. The AEAT names two key dates:
- 1 January 2027 for taxpayers who file Impuesto sobre Sociedades (corporate income tax)
- 1 July 2027 for all other taxpayers
(Source: https://sede.agenciatributaria.gob.es/Sede/todas-noticias/2025/diciembre/3/ampliacion-plazo-adaptacion-sistemas-informaticos-facturacion.html)
(Source: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-24446)
Important: the postponement is not an invitation to put the topic on hold. It merely reduces the time pressure. Technically, it remains an intervention in core invoicing processes. Anyone using non-compliant software risks a fine of 50,000 euros per financial year under Article 201 bis of the Ley General Tributaria. The article E-invoicing in the EU: deadlines and sanctions by country offers a comparison with the sanctions in other EU countries.
Legal basis: what specifically applies in Spain
For a robust compliance argument, you should be able to cite the legal basis precisely:
- Real Decreto 1007/2023
This decree approves the regulations that define requirements for systems and programs supporting invoicing processes, and it standardises the formats of the invoicing records. (Source: https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840) - Orden HAC/1177/2024
This ministerial order specifies technical, functional and content requirements and also points out that the AEAT publishes details of the specifications on its electronic platform. (Source: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2024-22138) - Real Decreto-ley 15/2025
This law postpones the adjustment deadlines by amending the relevant transitional provisions in the context of RD 1007/2023. (Source: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-24446)
In addition, the AEAT refers to Ley 58/2003, Ley General Tributaria, in particular to formal obligations and offences relating to non-compliant systems. (Source: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html)
Concept and system logic: what SIF and VeriFactu are about
The regulations are not aimed at a company simply submitting an additional report. The core idea is that the invoicing IT system is operated in such a way that invoicing events are technically traceable and subsequent manipulation is either prevented or clearly detectable.
To this end, standardised registros de facturación, i.e. invoicing records, are generated. For these records, there is a concept of capture, chaining and proof. In the VeriFactu operating mode, the records are transmitted to the AEAT. In the mode without transmission, often referred to as No VeriFactu, they remain in the system and must meet the requirements for retention, immutability and auditability there.
On its project page, the AEAT also describes that there are records for registration as well as records for cancellation, which is important from a process perspective because cancellations and corrections must be mapped correctly. (Source: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/cuestiones-generales.html)
What the AEAT developer FAQ clarifies technically
For technical depth, it is worth looking at the document ACLARACIONES A DUDAS DE LOS DESARROLLADORES. It is not marketing, but a practical collection of clarifications that are directly relevant in projects. (Source: https://sede.agenciatributaria.gob.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf)
In brief, the points that are particularly reliable for architecture and operations:
- The AEAT confirms that the VeriFactu services have been available in production since 23 April 2025, including for voluntary transmission and for verification mechanisms such as QR matching.
- The document explicitly names the new key dates of 1 January 2027 and 1 July 2027 and assigns them to the groups of taxpayers.
- It describes how an SIF is identified in practice, including concepts such as installation and unique identifiers, which is crucial for rollouts in branch structures.
- It warns against typical errors such as reusing invoice numbers after deletion, because this leads to conflicts in the invoicing records.
- It explains that multi-component architectures are permitted, but only if the process chain is mandatory, immutable and cleanly certifiable.
What German companies with a Spanish entity should check now
1. Which Spanish company issues invoices, and with what
Create a system map for each Spanish company: which application generates the invoice, which application writes the number ranges, which application stores documents, and who is the manufacturer or operator of the invoicing software. This is the basis for any subsequent proof.
2. Process for cancellation and correction
Spanish invoice cancellations are not just a PDF issue. You need a clearly defined process logic that fits the idea of the registros de facturación, including the mapping of cancellation records. (Source: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/cuestiones-generales.html)
3. Decision: operation with or without transmission to the AEAT
Put precisely, this is a decision about the SIF operating mode:
- Operation as VeriFactu with transmission of the invoicing records to the AEAT
- Operation without transmission, in which the requirements for retention, proof and auditability lie entirely within your own system
In many corporate landscapes, operating with transmission reduces the complexity of internal proof and speeds up audits, because a clear reconciliation channel exists. The final decision, however, depends on IT governance, data protection, operating models and risk position.
4. Rollout planning with realistic test cases
Do not just test happy paths, but also cancellation, correction, number range changes, system updates, offline scenarios and restarts after transmission errors. It is precisely these cases that determine whether operations are stable.
Implementation with our UI and API: two paths, one goal
We support VeriFactu both via a user interface and via our API. This is practical for German corporate groups because it covers two typical situations:
- Integration into existing systems via API
The group ERP remains the leading system. Invoice data is transferred via API. We take care of the technical creation of the required invoicing records, the operating logic for VeriFactu and the handling of statuses and responses. The result is a clear integration point without deep intervention in legacy systems. - Standalone use via the UI for local teams
If a Spanish company needs a working solution at short notice, the UI can be used as a standalone process. This makes sense if local teams do the invoicing but ERP integration follows later, or if different systems exist at each location.
The page E-invoicing in Europe shows how faktoora covers further country formats such as FatturaPA, KSeF and Factur-X; you can find technical details on integration on the faktoora API page.
The added value for customers is not having yet another tool, but integrating the Spanish mandatory requirement into the group process in a controlled way, including uniform rules, traceable proof and clear operational responsibility.
Conclusion: the postponement to 2027 buys time, but is no all-clear
The obligation has been postponed, not abolished. German companies with a Spanish subsidiary or branch should use 2026 to firmly establish their architecture, numbering logic, cancellation processes and operating model. This way, you avoid 2027 ending up as a pure firefighting project.