With the entry into force of Royal Decree 1007/2023 (RRSIF) and SIF systems adapted to VeriFactu, every invoice issued generates an invoicing record with a hash chained to the previous record. This means any attempt to delete or modify an already-generated invoice breaks the traceability chain and constitutes an infringement under Article 11 of RD 1007/2023.
The rule is clear: a valid invoice cannot be deleted, edited or removed. When something needs correcting, the path is always documentary — through a corrective invoice — or technical — through a cancellation record or remediation. Never through direct modification of the original document.
This principle is not new, but with electronic invoicing it takes on an operational and technical dimension it never had before: a compliant SIF makes it technically impossible to circumvent, and if the software allows it, that software is violating the RRSIF.
Before going into detail, the differences between the three terms must be clear:
Rectification: a new invoice (corrective invoice) is issued that corrects or replaces a valid but erroneous original invoice, or one modified by subsequent circumstances. It has fiscal and accounting effects.
Cancellation: a cancellation record is generated for a previous invoice registration, declaring that the invoice should never have existed. Only valid when the invoice was never a real transaction. It has no VAT effect because no VAT was ever due.
Remediation: an exclusively technical correction of the invoicing record — the hash, the digital signature, the XML metadata — without modifying the invoice content. Carried out by the software, not the user. The invoice itself does not change.
The obligation to issue a corrective invoice is set out in Article 15 of Royal Decree 1619/2012 (Invoicing Regulations) and Article 89 of Law 37/1992 (VAT Act). It applies in the following cases:
1. Error in mandatory invoice data (Art. 6 and 7 of RD 1619/2012): incorrect or missing Tax ID (NIF), errors in issuer or recipient details, insufficient description of goods or services, incorrect date of issue. An error in recipient identification can cause them to lose the right to deduct the VAT borne.
2. Error in VAT charged: incorrect tax rate applied (21% charged when 10% applied, or vice versa), arithmetic error in the quota calculation, incorrect application of the equivalence surcharge, or incorrect reverse charge application.
3. Modification of the VAT taxable base (Art. 80 VAT Act): return of goods, price reduction for quality defects, post-sale discounts, total or partial contract termination, uncollectable debts, or debtor insolvency proceedings.
4. Under B2B e-invoicing (RD 238/2026): Article 10.5 establishes specific rules for debit or credit documents and their relationship to invoice status fields. An electronic corrective invoice must identify the original using the unique invoice code defined in Article 7.5 (issuer NIF + number/series + date of issue).
The corrective invoice must be issued as soon as the error or triggering circumstance is known. The maximum deadline is 4 years from the point at which the tax became due (Art. 89 VAT Act), or from the date the circumstances under Art. 80 VAT Act arose.
For uncollectable debts to recover VAT, the deadlines are stricter: the corrective invoice must be issued within three months of the expiry of six months of non-payment. Once issued, the obligated party has one month to notify the AEAT.
A new invoice is issued showing only the difference between the original and the correct invoice. The amount can be positive (if more was owed) or negative (if less was owed or an amount must be annulled).
Example: original invoice for €1,000 base + €210 VAT (21%). Correct rate was 10%. Corrective invoice by differences: taxable base €0, VAT quota -€110 (difference between €210 and €100).
A new invoice is issued that fully replaces the original. Two records must be generated: the erroneous invoice with negative amounts and the corrective invoice with the correct amounts.
Example: original invoice €1,000 base + €210 VAT. Substitutive corrective: negative record of -€1,000 base / -€210 quota, plus new invoice of €1,000 base / €100 quota (10% VAT).
A corrective invoice is negative when it reduces the original amount (returns, discounts, unpaid debts). It is positive when it increases it (VAT charged at too low a rate, price agreed above what was invoiced). The accounting and tax treatment differs in each case.
Under Article 15 of RD 1619/2012, every corrective invoice must:
Under the RRSIF and VeriFactu, the corrective invoice generates a new invoicing record with its own hash, chained to the preceding ones. The original invoice's hash remains unchanged: the corrective does not modify it but creates a new link in the chain.
Cancellation is an exceptional procedure, valid only when the invoice was generated in error and was never a real transaction nor placed at the recipient's disposal. Valid cases include:
What cancellation does not allow is correcting errors in an invoice that was already delivered to the client, collected or that produced fiscal effects. That is what the corrective invoice is for.
In a SIF adapted to RD 1007/2023, cancellation does not delete the original record: it generates a cancellation record that references the preceding registration record via its hash. The chain remains intact and the AEAT can verify that a registration existed and was subsequently cancelled, with full traceability.
The cancelled invoice number cannot be reused: it remains occupied in the sequence to maintain continuity. This is an important difference from previous practice, where some systems allowed a number to be "freed" after cancellation.
Cancelling an invoice that did have fiscal effects (was collected, VAT was filed, the client deducted it) without issuing the corresponding corrective invoice can result in:
Remediation is the correction of an exclusively technical error in the invoicing record — the hash, the digital signature, the XML metadata — when the invoice content is correct. It does not modify the invoice itself, only the integrity mechanism that accompanies it.
Typical remediation cases are:
Remediation is carried out by the software at the user's request, not by the user directly. Anyone who thinks they can manually "remediate" a content error in the invoice is confusing the concepts — and likely violating the RRSIF.
| Corrective invoice | Cancellation | Remediation | |
|---|---|---|---|
| When used | Valid invoice with error or subsequent change | Invoice was never a real transaction | Technical error in the record (not the content) |
| VAT effect | Modifies taxable base and/or quota charged | None (no tax ever arose) | None |
| Accounting effect | New income/expense entry or adjustment | None (no transaction ever recorded) | None |
| Generates new document | Yes (corrective invoice with own numbering) | No (cancellation record in the SIF) | No (technical correction of the record) |
| Reference to original | Mandatory (number, series, date) | Mandatory (hash of registration record) | Mandatory (hash of record to correct) |
| Maximum deadline | 4 years from tax due date | Before any fiscal effect | As soon as technical error is detected |
| Invoice number | New number in corrective series | Original number cancelled and non-reusable | No effect on numbering |
With mandatory B2B e-invoicing, corrective invoices must also be issued in structured format (Facturae, UBL or CII) and transmitted through interoperable platforms. Article 10.5 of RD 238/2026 sets specific rules for debit or credit documents and their relationship to invoice status fields.
A key point raised by EC-CGE Position Paper No. 3/2026: electronic corrective invoices have direct implications for the periodification and adjustment of income and expenses. Accounting systems must explicitly account for the handling of electronic corrective invoices to avoid mismatches or duplications in the accounting record.
The unique invoice code of Article 7.5 of RD 238/2026 (issuer NIF + number/series + date of issue) will be essential for correctly identifying which invoice corrects which, both in the issuer's and recipient's systems and in the AEAT's records.
No. No compliant SIF allows it. Directly modifying an issued invoice breaks the hash chain and constitutes an infringement of Article 11 of RD 1007/2023. The only path is to issue a corrective invoice or a cancellation record depending on the situation.
No. The corrective invoice must use a specific series and numbering for corrective invoices (e.g. "R-001", "REC-2026-001"), independent of the general invoice series. Using the same numbering is a formal error that can invalidate the corrective invoice.
Yes. In VeriFactu, the cancellation record is transmitted to the AEAT linked to the original registration record. The AEAT can verify that an invoice existed and was cancelled, with full traceability.
No. The cancelled invoice number remains occupied in the sequence to maintain continuity. It cannot be assigned to a new invoice.
A corrective invoice issued outside the deadline has no fiscal effect: it cannot modify the VAT quotas of already-filed returns. It may have internal accounting effects, but fiscally it is considered out of time.
The recipient must reduce the deducted input VAT corresponding to the original invoice. If already deducted, it must be regularised in the return for the period in which the corrective invoice is received. Failure to do so may result in incorrectly deducted quotas and penalties.
Electronic invoicing has not changed when to correct or when to cancel. It has changed how — and it has done so in a way that any irregularity is technically recorded and verifiable by the AEAT.
For advisors, accountants and businesses, this demands two things: knowing precisely when each operation applies, and ensuring that the invoicing software correctly implements corrective and cancellation records in accordance with the RRSIF. Software that allows already-generated invoices to be modified or deleted does not comply with RD 1007/2023, and its use exposes the taxpayer to penalties of up to €50,000 per tax year.
See our technical documentation on InvoSeal's invoicing cycle for details on how we handle corrective invoices and cancellations in accordance with the RRSIF and RD 238/2026.
]]>Both involve invoicing. Both come from the Spanish tax and regulatory environment. And both are coming into force in the near future. That is enough for many businesses and their advisors to treat them as a single requirement.
But they are completely separate legal frameworks. Position Paper No. 3/2026 by Economistas Contables EC-CGE (Consejo General de Economistas de España) makes this explicit: it is necessary to distinguish mandatory B2B e-invoicing from the fiscal reporting obligations known as VeriFactu. While e-invoicing focuses on commercial exchange, VeriFactu has different objectives defined by the AEAT.
Let us look at each one separately.
B2B e-invoicing is governed by Royal Decree 238/2026, which implements the Spanish "Ley Crea y Crece" (Create and Grow Act, Law 18/2022). Its objective is to digitise the Spanish productive sector and reduce late commercial payments by making it mandatory to issue and receive invoices in structured electronic format.
All companies and self-employed professionals who conduct commercial transactions between themselves (B2B) and have their registered address, permanent establishment or habitual residence in Spain. It does not affect transactions with end consumers (B2C).
The deadlines have not started yet. Everything depends on the Ministerial Order from the Ministry of Finance governing the public invoicing solution, which is currently in a public consultation process (deadline: 8 May 2026). Once that Order is published:
For a full breakdown of these deadlines, see our article on the real deadlines of RD 238/2026.
VeriFactu is governed by Royal Decree 1007/2023, which implements Article 29.2.j of Spain's General Tax Act. Its objective is fundamentally different from that of B2B e-invoicing: to guarantee the integrity and immutability of invoicing records generated by invoicing software, preventing tax fraud through the manipulation of accounting data.
All business owners and professionals who use invoicing software in their activity — regardless of whether their customers are businesses or private individuals. This is not an obligation about exchanging invoices between parties: it is an obligation concerning the software system itself that generates the invoices.
The invoicing software must:
The obligation falls not on the business itself, but on the invoicing software provider, which must certify that its product meets the technical requirements of RD 1007/2023.
These dates are independent of the Ministerial Order for B2B e-invoicing.
| B2B E-Invoicing (RD 238/2026) | VeriFactu (RD 1007/2023) | |
|---|---|---|
| Objective | Digitise commercial exchange between businesses | Guarantee the integrity of invoicing software |
| Regulation | RD 238/2026 (Ley Crea y Crece) | RD 1007/2023 (General Tax Act) |
| Transactions | B2B only (business to business or professional) | All: B2B and B2C |
| Obligation on | The exchange of invoices between parties | The software that generates the invoices |
| Required formats | Facturae, UBL, CII (structured) | Chained hash + QR code on the invoice |
| Report to the AEAT | Invoice status (payment, acceptance…) | Invoicing records (optional or automatic) |
| Entry into force — companies | 12 months from Ministerial Order (no date yet) | 1 January 2027 |
| Entry into force — freelancers | 36 months from Ministerial Order | 1 July 2026 (provisional) |
A company can be subject to both regulations at the same time. For example, a company that invoices other businesses must:
Complying with one does not mean complying with the other. They are independent layers of obligation covering different aspects of the invoicing process.
InvoSeal is built to deliver compliance with VeriFactu (RD 1007/2023): it generates invoicing records with a chained digital fingerprint, includes the QR code and the required label, and enables the submission of records to the AEAT.
For B2B e-invoicing under RD 238/2026, the technical platform and interoperability requirements will be defined in detail by the pending Ministerial Order. InvoSeal is closely monitoring these developments to provide full coverage once the deadlines come into force.
You can find our technical documentation on VeriFactu in our verifiable invoicing system documentation.
No. VeriFactu governs the integrity of invoicing software; B2B e-invoicing governs the exchange of invoices between businesses in structured format. They are obligations covering different aspects of the process. Complying with one does not exempt you from the other.
Yes. VeriFactu applies to all business owners and professionals who use invoicing software, regardless of whether their customers are businesses or private individuals. B2B e-invoicing, by contrast, only applies when the recipient is another business owner or professional.
Generally yes, but for different reasons. For VeriFactu, the software must be able to generate records with chained hash values and a QR code. For B2B e-invoicing, it must be able to issue and receive invoices in structured formats (Facturae, UBL, CII) and interact with interoperable platforms.
It depends on your situation. VeriFactu has fixed dates: 1 July 2026 for freelancers and 1 January 2027 for companies. B2B e-invoicing has no start date yet because it depends on the pending Ministerial Order. In practice, VeriFactu will arrive first for the vast majority of businesses.
It is a common mistake. The distinction is explicitly set out in Position Paper No. 3/2026 by Economistas Contables EC-CGE, one of Spain's leading technical reference bodies on accounting matters. It is worth clarifying this before planning your company's technological adaptation.
Confusing VeriFactu and B2B e-invoicing is not a minor detail: it can lead companies to believe they are compliant when they are not, or to invest in solutions that only address one of the two obligations.
The first step is to understand the difference. The second is to verify what software you use, whether it is VeriFactu-compliant, and what steps you need to take to be ready for B2B e-invoicing as well, once its deadlines come into force.
If you have questions, consult your advisor or refer to the official documentation of RD 238/2026, RD 1007/2023 and EC-CGE Position Paper No. 3/2026.
]]>The accrual principle is the governing criterion for accounting recognition under Spain's General Accounting Plan (Plan General Contable, PGC). Income and expenses are recognised in the period in which they arise, regardless of when cash is received or paid. This principle has not been modified by RD 238/2026, nor could it be: it belongs to the accounting framework, not to the invoicing framework.
However, the introduction of invoice status fields into the operational flow of businesses creates a new tension. When invoicing software automatically records the status "paid" and that event triggers an accounting entry, the result can be cash-basis recognition rather than accrual — especially in small and medium-sized businesses without robust internal accounting controls.
EC-CGE warns of this explicitly in its Position Paper No. 3/2026: there is a risk that certain technological automatisms may indirectly and involuntarily induce criteria closer to cash-basis accounting, especially in small and medium-sized enterprises.
RD 238/2026 establishes that issuers and recipients of electronic invoices must report the following invoice status fields to the AEAT within a maximum of 4 calendar days of each event occurring:
The purpose of these status fields is twofold: to combat commercial late payments (the AEAT can cross-reference declared payment dates with actual ones) and to improve traceability of the economic cycle of each transaction.
What invoice status fields do not do — and this is the core of the issue — is determine when an operation must be recognised in accounting terms. They are informational data about the administrative and cash-flow cycle of the invoice, not about the underlying economic event that gives rise to it.
Article 10 of RD 238/2026 introduces a precise definition of "effective payment date" that has direct accounting consequences and deserves specific attention.
The regulation defines the effective payment date as the moment when the supplier actually receives payment for the goods or services. It expressly excludes from that definition the mere making available of a financial mechanism to advance receipt — such as confirming or factoring arrangements.
This has two important practical implications:
First: there can be a difference of several days between the date on which the customer executes the bank transfer and the date on which the funds are actually credited to the supplier's account. The effective payment date for the purposes of RD 238/2026 is the latter, not the former. Software that records the status "paid" at the moment the transfer is sent is being imprecise relative to the regulation's own legal definition.
Second: the effective payment date — even in its most precise definition — remains irrelevant for the accounting recognition of income or expense. A sale is recognised when the goods are delivered or the service is rendered; a purchase, when it is received. The subsequent receipt or payment is a cash flow event that affects the debtor or creditor account, not the recognition of income or expense.
EC-CGE underlines precisely this: the invoice status fields have an informational and monitoring character and in no case condition the moment of accounting recognition.
The risk is not theoretical. In practice, many management systems and ERP solutions for SMEs are designed to simplify operations: when an invoice arrives and is marked as "paid", the system may automatically generate the accounting entries for the transaction. If that process is not correctly configured, the result is accounting that reflects when cash is paid, not when the obligation is incurred.
The consequences can be significant:
EC-CGE frames this in terms of internal control: this risk must be avoided through correct system configuration and adequate accounting training.
A technically sound invoicing software designed with the accountant and advisor in mind cannot limit itself to recording and transmitting invoice status fields. It must design its interface and its automated processes in a way that does not induce — or allow — confusion between the administrative cycle of the invoice and the accounting cycle.
Best practices in software design for this context include:
1. Informational text in the UI alongside invoice status fields. When a user marks an invoice as "accepted" or "paid", the system should display a clear notice: this status is reported to the AEAT for the purposes of the RD 238/2026 obligation, but does not automatically generate or modify the accounting entry. Accounting recognition must follow the accrual principle under the PGC.
2. Explicit separation between the invoice status module and the accounting module. Status fields are fiscal and administrative information flows. The accounting entry is an independent flow governed by PGC criteria. The software must not merge these flows without the user being fully aware.
3. Alerts about the "effective payment date". When a payment is recorded, the system should remind the user that the effective payment date under RD 238/2026 is the date funds are credited to the supplier's account, not the date the transfer order is issued.
4. Explicit configuration of accrual rules. The software must allow the advisor or accountant to define accrual and periodification rules without the invoice status automation overriding or interfering with them.
Most e-invoicing solutions on the market are designed from a purely technological perspective: transmitting the right data in the right format to the AEAT. That is necessary, but insufficient when the end user is an advisor, a certified accountant or a company with internal accounting functions.
InvoSeal is built with awareness of this risk. The invoice status fields it generates and reports under RD 238/2026 are clearly differentiated from the accounting cycle. The interface design includes contextual notices reminding the user of the distinction between the effective payment date (legal definition under Art. 10 RD 238/2026) and the moment of accounting recognition under the PGC.
This approach is aligned with the recommendations of EC-CGE Position Paper No. 3/2026 and with the perspective upheld by the Consejo General de Economistas: e-invoicing must be integrated into the company's financial information system, not substitute accounting judgement.
See our technical documentation on VeriFactu and the accounting cycle to understand how InvoSeal implements these principles in practice.
It should not, although some poorly configured systems do. The "paid" status is informational data reported to the AEAT for late payment monitoring purposes. The accounting entry for cash receipt must be recorded in accordance with the PGC, independently of the invoice status in the electronic system.
Income is recognised when the goods are delivered or the service is rendered, in accordance with the accrual principle. The recipient's acceptance of the invoice does not affect that moment. The invoice may be accepted and the income already recognised beforehand, or recognised after acceptance: the invoice status is not the determining factor.
The effective payment date under RD 238/2026 (Art. 10) is the date on which the supplier actually receives the funds. In accounting, the derecognition of the liability (removal of the creditor) may coincide with that moment, but the expense recognition already occurred at the point of accrual, regardless of when payment is made.
Not for the purposes of RD 238/2026. The regulation expressly excludes from the definition of effective payment date the mere making available of a financial mechanism to advance receipt. The effective payment date remains the moment the supplier actually receives the funds.
EC-CGE recommends reviewing the entire accounting circuit of the invoice before implementation: from issuance or receipt through to the accounting close. In particular, verifying that the software's automated processes do not confuse invoice status with the point of accrual, and that accrual periodification is correctly configured.
Mandatory e-invoicing is an opportunity to improve the quality of financial information. But that improvement only materialises if the software implementing it respects fundamental accounting principles, rather than replacing them with administrative automatisms.
Invoice status fields are valuable data. The effective payment date is a precise legal definition. And accrual is the accounting principle that continues to govern the recognition of income and expenses. All three exist on separate planes and must be kept separate.
For advisors and certified accountants accompanying their clients through this transition, correct software configuration and administrative team training are tasks as important as the choice of invoicing platform itself.
]]>Before looking at individual countries, the common context needs to be established.
The VAT in the Digital Age (ViDA) initiative, adopted by the EU Council in March 2025, sets the framework guiding the digitalisation of VAT across Europe through to 2035. Its three pillars are B2B e-invoicing, real-time digital transaction reporting and an expanded VAT One Stop Shop.
Since the implementation of the eInvoicing Directive 2014/55/EU in April 2020, all public administrations across the EU are required to accept electronic invoices compliant with the European Standard for contracts above EU public procurement thresholds. With ViDA, that obligation is progressively extending to B2B.
A key ViDA milestone: from 2024-2025, member states gain the right to mandate domestic e-invoicing without needing individual EU derogations. In July 2030, mandatory digital reporting for all intra-EU B2B transactions comes into force.
EN 16931 is the European semantic data model standard for electronic invoices. It defines which fields are mandatory, their format and structure. If you invoice businesses or government entities in any EU country with an e-invoicing mandate, your invoice format must conform to EN 16931. National formats such as XRechnung (Germany), Factur-X (France), FatturaPA (Italy) or Facturae (Spain) are national implementations of this standard or formats compatible with it.
Spain has a particularly distinctive framework because it has developed two parallel, independent obligations:
1. VeriFactu / RRSIF (RD 1007/2023): governs invoicing computer systems (SIF). All invoicing software must generate records with chained hash and a QR code, guaranteeing the integrity and immutability of records. Deadline: companies by 1 January 2027; freelancers by 1 July 2027.
2. B2B e-invoicing (RD 238/2026): requires issuing and receiving invoices in structured formats (Facturae, UBL or CII) for all transactions between businesses and professionals. Deadlines run from the pending Ministerial Order: 12 months for companies with more than €8M turnover, 24 months for all others and 36 months for freelancers and income-attribution entities with turnover ≤ €8M.
Primary format: Facturae (Spain's native XML format, already mandatory for B2G transactions for many years). UBL and CII are also accepted.
Platform: public solution managed by the AEAT (free for freelancers and SMEs), plus private platforms interoperable with each other.
Key differentiator: Spain is the only EU country combining a software integrity system (VeriFactu/RRSIF) with a structured exchange obligation (B2B e-invoice). Most countries have only one of the two.
Italy was the first EU country to impose mandatory universal B2B e-invoicing. Italy has operated a mandatory B2B e-invoicing system since 2019, using the FatturaPA format and a centralised clearance model through the Sistema di Interscambio (SDI) platform.
The Italian model is the most interventionist in Europe: every invoice (B2B, B2C and B2G) must mandatorily pass through the SDI (Sistema di Interscambio), the Tax Agency's centralised platform. The SDI validates the invoice before it reaches the recipient. If the SDI rejects it, the invoice has no legal validity.
Format: FatturaPA, Italy's own XML format. Invoices in other formats (UBL, CII) must be converted to FatturaPA before transmission to the SDI.
Archiving: mandatory for 10 years in digital format.
Consequence of non-compliance: an invoice not sent through the SDI is treated as if it were never issued — with all the VAT and payment enforcement consequences that entails.
The Italian model has proven effective in reducing tax fraud. The EU Council extended Italy's mandate through 2027, after which it must align with ViDA standards. Germany, France and Spain have all studied the Italian model, though none has replicated its total clearance approach exactly.
Germany has adopted a more gradual and decentralised approach than Italy. As of 1 January 2025, reception of electronic invoices became mandatory: no company can refuse an e-invoice from its supplier. Mandatory issuance begins for companies with turnover above €800,000 in January 2027, and for all companies in January 2028.
Unlike Italy (centralised SDI) and France (PA/PPF), Germany has no national centralised platform for B2B. Invoices are exchanged directly between parties or through private operators and the Peppol network.
Accepted formats: two formats coexist and are accepted:
Both are EN 16931 compliant.
Key differentiator: Germany is the only major European market without a central B2B exchange platform. The model relies on Peppol and direct bilateral agreements. This offers more flexibility but also more complexity for businesses issuing in many formats.
Leitweg-ID: mandatory identifier on B2G invoices for routing to the correct authority.
France has had one of the most complex implementation processes in Europe, with multiple postponements from the original July 2024 date. The confirmed final date: from 1 September 2026, all businesses must be able to receive e-invoices, with mandatory issuance for large and medium companies from September 2026 and for SMEs from September 2027.
France has designed a system called the "Y-model" that requires all invoices to pass through a Plateforme Agréée (PA) — formerly known as PDP (Plateforme de Dématérialisation Partenaire). PAs are private service providers accredited by the tax authority to intermediate data flows between trading partners and the public portal (PPF). They act as the interface between businesses and the government.
Important: following the French government's announcement in October 2024, the PPF (public portal) will act only as a directory and e-reporting platform. All companies must partner with a PA. It is not possible to exchange invoices directly between businesses without going through a certified PA.
Accepted formats: Factur-X (hybrid PDF+XML format, equivalent to Germany's ZUGFeRD), UBL and CII. All EN 16931 compliant.
Additional e-reporting: France also requires e-reporting for B2C transactions, international sales and cross-border operations — data that PAs automatically transmit to the PPF for tax control.
Archiving: e-invoices must be archived for six years for VAT compliance and ten years for accounting and commercial law compliance.
Poland has implemented KSeF (Krajowy System e-Faktur), a centralised clearance system similar to Italy's but stricter. Poland implements the KSeF clearance system from February 2026 for large taxpayers (turnover above PLN 200 million) and from April 2026 for all other VAT-registered businesses.
Model: all B2B invoices pass through KSeF, which validates them and assigns a unique identification number. Without that number, the invoice has no legal validity in Poland.
Format: Poland's own FA_VAT XML format, specific to KSeF. FatturaPA and XRechnung cannot be submitted directly.
Key differentiator: Poland has opted for the model closest to Italy's clearance approach, but with an even more exhaustive level of control. Paper and PDF invoices have lost legal validity for B2B transactions between Polish companies.
Belgium has adopted the most open model of those analysed. Belgium launched mandatory B2B e-invoicing on 1 January 2026, using the Peppol network with UBL 2.1 format. All Belgian businesses conducting B2B transactions must be capable of sending and receiving e-invoices.
Model: no centralised national platform. Invoices are exchanged through the Peppol network (Pan-European Public Procurement On-Line), a network of interoperable access points.
Format: UBL 2.1, EN 16931 compliant.
Advantage of the Peppol model: any company on the Peppol network can exchange invoices with any other company on the network, regardless of which European country they are in. This makes Belgium one of the countries with the greatest cross-border interoperability potential.
| Country | Model | Primary format | Platform | B2B mandatory | Key feature |
|---|---|---|---|---|---|
| Spain | Post-audit + SIF integrity | Facturae / UBL / CII | AEAT (public) + private | 2026-2027 (B2B), 2027 (VeriFactu) | Only EU country with dual SIF + B2B system |
| Italy | Centralised clearance | FatturaPA (XML) | SDI (Tax Agency) | Since 2019 (B2B+B2C) | Every invoice passes through SDI before reaching recipient |
| Germany | Decentralised post-audit | XRechnung / ZUGFeRD | No central platform (Peppol) | Reception 2025 / Issuance 2027-2028 | No national central platform; ZUGFeRD is hybrid PDF+XML |
| France | Y-model with certified PAs | Factur-X / UBL / CII | PA (certified) + PPF (directory) | Reception Sept. 2026 / Issuance Sept. 2026-2027 | Every invoice must go through a certified PA |
| Poland | Centralised clearance (KSeF) | FA_VAT (Polish XML) | KSeF (Polish Tax Authority) | Feb-Apr. 2026 | KSeF number mandatory; without it the invoice does not exist |
| Belgium | Decentralised post-audit | UBL 2.1 | Peppol network | Since Jan. 2026 | Most open model; Peppol as infrastructure |
The clearance model (Italy, Poland/KSeF) requires the invoice to be validated by the tax authority before it reaches the recipient. The tax authority acts as a real-time intermediary. The post-audit model (Germany, Belgium, Spain B2B) allows invoices to be exchanged directly between businesses, with the authority reviewing them after the fact through reports or audits.
Spain is an intermediate case: the RRSIF (VeriFactu) is a software integrity system (closer to post-audit), but records can be transmitted to the AEAT in real time in VeriFactu mode.
Italy and Poland use state centralised platforms (SDI, KSeF). France uses mandatory certified private platforms (PA). Belgium uses the open Peppol network. Germany has no central platform for B2B. Spain will use the AEAT's public solution plus interoperable private platforms.
Italy accepts only FatturaPA (mandatory conversion from other formats). Poland accepts only FA_VAT. France accepts Factur-X, UBL and CII. Germany accepts XRechnung and ZUGFeRD. Spain accepts Facturae, UBL and CII. The European trend points towards convergence on EN 16931, but specific national formats will persist for years.
The ViDA initiative is the EU's comprehensive plan to modernise the VAT system through digitalisation. It introduces a standardised framework for real-time transaction reporting, making e-invoicing the default invoicing system, while allowing countries to align national models with the new rules.
The key milestone: in July 2030, mandatory digital reporting for all intra-Community B2B transactions (between businesses in different EU countries) comes into force. By 2035, all national regimes must be harmonised with ViDA.
What this means in practice: if a Spanish company today invoices a German company, the invoice can be a PDF. From 2030, it will need to be in structured format, with real-time reporting to the tax authorities of both countries.
For a Spanish SME or company with activity in other EU countries, the implications are concrete:
Multiple simultaneous formats: a company invoicing in Spain, Germany and France needs to generate Facturae (or UBL/CII) for Spain, XRechnung/ZUGFeRD for Germany and Factur-X/UBL/CII for France. The ERP must be able to generate all of them.
Multiple platforms or access points: Italy requires the SDI, France requires a certified PA, Belgium requires Peppol. There is no single platform covering all countries.
Non-coinciding timelines: each country's deadlines are different and not synchronised with each other. A company may already be obligated in Italy (since 2019) and Belgium (since 2026) but still in the transitional period in Spain and Germany.
Additional e-reporting in some countries: France requires e-reporting for B2C and cross-border sales. Portugal requires monthly SAF-T. These obligations go beyond simply issuing structured invoices.
Not directly. Each country requires its national formats. A Spanish invoice in Facturae does not meet German formal requirements (XRechnung or ZUGFeRD). To invoice in Germany, the invoice must be generated in a format Germany accepts. EN 16931 guarantees semantic compatibility, but format conversion may be necessary.
Peppol (Pan-European Public Procurement On-Line) is an electronic document exchange network using an infrastructure of interoperable access points. Several countries (Belgium, Nordic countries, Netherlands) use it as the de facto infrastructure for e-invoicing. Spain admits it but does not impose it as the only infrastructure.
It depends what aspect is measured. On software integrity (VeriFactu/RRSIF), Spain is ahead of most European countries, which have nothing equivalent. On B2B e-invoicing, it arrives later than Italy (2019), Belgium (2026) or Poland (2026), but earlier than Ireland or some Nordic countries.
Today, the invoice can be sent in any format accepted by both parties (even PDF). When the RD 238/2026 deadlines enter force in Spain and ViDA in 2030, intra-Community invoices will need to be in structured format conforming to EN 16931 and reported digitally to both tax administrations.
InvoSeal is designed specifically for compliance with the Spanish framework (VeriFactu/RRSIF and RD 238/2026). For invoicing in other EU countries, the specific national requirements of each market need to be verified. See our technical documentation on the verifiable invoicing system for full details on InvoSeal's scope.
Mandatory e-invoicing is a reality across Europe, but each country has made different design decisions on format, platform, validation model and timeline. Spain has opted for a relatively flexible model (multiple formats, interoperable platforms, free public solution) that contrasts with Italy and Poland's centralised clearance, or France's system of certified PAs.
By 2030, ViDA will converge all these systems into a common framework for intra-Community transactions. Until then, businesses operating across multiple European countries must simultaneously manage disparate national requirements.
The key is to treat it for what it is: a digital transformation project, not a simple invoice format change.
]]>Royal Decree 238/2026 (RD 238/2026), which implements Spain's "Ley Crea y Crece" (Create and Grow Act), establishes that the obligation to issue and receive electronic invoices in B2B operations (between businesses and professionals) will be rolled out in stages. The key condition: the deadlines do not begin from the date the Decree was published, but from the date the Ministry of Finance's Ministerial Order governing the public invoicing solution enters into force.
On 16 April 2026, the Ministry of Finance opened a public consultation on the draft Ministerial Order. The consultation period closes on 8 May 2026. Until that Order is approved and comes into force, no deadline is running.
Source: Position Paper No. 3/2026 by Economistas Contables EC-CGE (Consejo General de Economistas de España) and RD 238/2026.
If your company or professional activity generates annual turnover above €8 million, you must issue and receive electronic invoices for all B2B transactions within 12 months of the Ministerial Order entering into force.
Important transitional note: during that first year of obligation, you must accompany each electronic invoice with a readable PDF — unless the recipient expressly accepts the original electronic format.
Most Spanish SMEs fall into this group. If your annual turnover is €8 million or below, the deadline extends to 24 months from the Ministerial Order entering into force.
This applies to both natural and legal persons carrying out a business or professional activity who have their registered address, permanent establishment or habitual residence in Spain.
Self-employed professionals and entities under the income-attribution regime (civil partnerships, co-ownership arrangements, etc.) with turnover at or below €8 million receive an additional 12 months on top of Deadline 2, for a total of 36 months from the Ministerial Order entering into force.
This longest deadline is specifically designed to give groups with less technological capacity more time to adapt.
| Who | Deadline from Ministerial Order |
|---|---|
| Annual turnover above €8 million | 12 months |
| All other companies and professionals | 24 months |
| Freelancers and income-attribution entities with turnover ≤ €8 million | 36 months |
Once the deadlines kick in, the obligation includes:
The AEAT will also provide a free public platform for freelancers and small businesses without private software. This public solution must be available at least two months before the first mandatory application date.
This is a common source of confusion that is worth clarifying.
The mandatory e-invoicing regulated by RD 238/2026 concerns the exchange of invoices between businesses and professionals. Its main objectives are the digitisation of the productive sector and the reduction of late payment.
VeriFactu is a different system: it governs the reporting of invoicing records directly to the AEAT for tax control purposes. It is expected to come into force on 1 January 2027 for companies.
InvoSeal is designed for VeriFactu compliance. For B2B e-invoicing under RD 238/2026, the software and platform requirements are different and will be defined in detail by the pending Ministerial Order. You can find out more about VeriFactu in our documentation on the verifiable invoicing system.
No. The 12, 24 and 36-month deadlines do not begin until the Ministry of Finance's Ministerial Order enters into force. As of today, that Order is in a public consultation process that closes on 8 May 2026.
No. The e-invoicing obligation under RD 238/2026 applies exclusively to B2B transactions — meaning the recipient of the invoice must also be a business owner or professional with a registered address, permanent establishment or habitual residence in Spain. Invoices to private consumers are not covered.
Transactions documented through simplified invoices (the Spanish equivalent of till receipts) are exempt from the obligation, with the exception of so-called qualified simplified invoices.
It is not yet mandatory, but it is strongly advisable to start evaluating your options now. The Ministerial Order will define the exact technical requirements, and once published, the timelines are tight. Companies in the first tier will have only 12 months to adapt from that point.
Yes. RD 238/2026 establishes a free public solution managed by the AEAT, specifically designed for freelancers and small businesses. It must be available at least two months before the first mandatory application date.
The deadlines are clear, but the starting point remains uncertain as everything depends on when the Ministerial Order is approved. What is certain is that once it is published, time will be short — 12 months is very little to adapt systems, train teams and test platforms.
The preparation window is now. Review your invoicing systems, identify which tier you fall into, and if you have questions about how RD 238/2026 or VeriFactu affect your activity, consult your advisor or refer to the official decree documentation and EC-CGE Position Paper No. 3/2026.
]]>Confusing these three concepts has practical consequences: businesses that believe they are compliant when they are not, advisors planning adaptation on a wrong basis, and software providers selling compliance with one regulation when the client also needs to comply with another.
All three changes will coexist. But they apply independently, covering different aspects of the invoicing process. Let us look at each one.
A SIF is, according to the AEAT's definition, the set of hardware and software used to issue invoices that accepts invoicing data input by any method, stores that information and processes it to generate derived documents (standard and simplified invoices).
In practical terms: if your business uses any computer programme to issue invoices — whether an ERP, management software, a point-of-sale system or even a spreadsheet with formulas that allow alterations — that system is a SIF.
The SIF is governed by Royal Decree 1007/2023 (RRSIF), which sets out the technical requirements these systems must meet. The main objective is to eliminate so-called "dual-use software": programmes that allow businesses to conceal sales, delete invoices or manipulate accounting records without leaving a trace.
To comply with the RRSIF, a SIF must:
All business owners and professionals established in Spain who use a computer system to issue invoices — to both businesses and private individuals. Also producers and distributors of invoicing software.
Excluded are those who invoice manually (without software), contributors to the SII (Immediate Information Supply system) and certain special tax regimes.
VeriFactu (also written VERI*FACTU) is a compliance mode of the RRSIF — not an independent regulation. It is the option in which the SIF, in addition to generating invoicing records with chained hash, transmits them in real time to the AEAT's electronic headquarters at the moment each invoice is issued.
In other words: a SIF that complies with the RRSIF can operate in two modes:
Not necessarily. The regulation requires that the SIF has the technical capacity to transmit records to the AEAT, but actual real-time transmission is an option — highly recommended as it simplifies compliance and reduces storage obligations. Non-VeriFactu mode is also valid if the system meets all the RRSIF integrity requirements.
InvoSeal operates in Non-VeriFactu mode: it generates all records with chained hash, QR code and the required integrity guarantees under the RRSIF, without automatic transmission to the AEAT. This is the mode chosen by those who want full control over their records before any submission.
The objective of VeriFactu (and the RRSIF in general) is to eliminate tax fraud derived from dual-use software. It does not modify the substantive invoicing obligations: it does not change who must invoice, what an invoice must contain or when it must be issued.
B2B e-invoicing is the obligation to issue and receive invoices in structured electronic format (Facturae, UBL or CII) in all commercial transactions between businesses and professionals. It is governed by Royal Decree 238/2026, which implements the Ley Crea y Crece (Create and Grow Act, Law 18/2022).
Its objective is completely different from that of the SIF and VeriFactu: it is not about controlling the integrity of the software, but about digitising commercial exchange between businesses and combating late payment through payment traceability.
All business owners and professionals carrying out B2B operations (between businesses or professionals) with a registered address, permanent establishment or habitual residence in Spain. It does not affect sales to end consumers (B2C).
The deadlines have not yet started. Everything depends on the Ministerial Order from the Ministry of Finance governing the public invoicing solution (currently in a public consultation process with a deadline of 8 May 2026). Once published:
See the full breakdown in our article on the real deadlines of RD 238/2026.
| SIF (RD 1007/2023) | VeriFactu (RRSIF mode) | B2B E-Invoicing (RD 238/2026) | |
|---|---|---|---|
| What it is | The computer system that issues invoices | SIF mode with real-time transmission to the AEAT | Obligation to issue invoices in structured format |
| Objective | Eliminate dual-use software / tax fraud | Automatic submission of records to the AEAT | Digitise B2B exchange and combat late payment |
| Regulation | RD 1007/2023 (RRSIF) | RD 1007/2023 (optional/voluntary mode) | RD 238/2026 (Ley Crea y Crece) |
| Affects | All who use software to invoice | Those opting for automatic AEAT transmission | Only B2B transactions between businesses |
| Transactions | B2B and B2C | B2B and B2C | B2B only |
| Invoice format | Any (the regulation governs the system, not the format) | Any (same) | Structured mandatory: Facturae, UBL, CII |
| Deadline — companies | Before 1 January 2027 | Same | 12 months from Ministerial Order (no date yet) |
| Deadline — freelancers | Before 1 July 2027 | Same | 36 months from Ministerial Order |
| Who certifies | Software producer (responsible declaration) | The system itself (transmits to AEAT) | Exchange platforms |
Imagine a limited company that sells office supplies to other businesses. From 2027 it must:
Use a RRSIF-compliant SIF: its invoicing software must generate records with chained hash and QR code. It can do so in VeriFactu mode (transmitting to the AEAT) or in Non-VeriFactu mode (storing locally with all required guarantees).
Issue invoices to its business customers in structured format (Facturae, UBL or CII) through an interoperable platform, in accordance with RD 238/2026, once its deadlines come into force.
These are two distinct obligations covering two distinct aspects of the same invoicing process. Complying with one does not exempt from the other.
InvoSeal delivers compliance with the RRSIF (RD 1007/2023) in Non-VeriFactu mode: it generates invoicing records with chained hash, includes the regulatory QR code and guarantees the integrity and immutability of records in accordance with the Royal Decree's technical requirements.
For B2B e-invoicing under RD 238/2026, the platform and interoperability requirements will be defined by the pending Ministerial Order. InvoSeal is closely following these developments to offer full coverage when the deadlines come into force.
See our technical documentation on the verifiable invoicing system for details on how InvoSeal implements the RRSIF requirements.
Both modes are valid. The regulation requires that the SIF has the technical capacity to transmit records, but does not mandate VeriFactu mode. Non-VeriFactu mode complies with the RRSIF if the system generates records with chained hash and all required integrity guarantees.
No. The RRSIF governs the integrity of the system that generates invoices. B2B e-invoicing governs the format in which those invoices are exchanged between businesses. They are independent layers of obligation.
The SIF: freelancers have until 1 July 2027 and companies until 1 January 2027. B2B e-invoicing has no start date yet as it depends on the pending Ministerial Order. In practice, SIF and VeriFactu requirements arrive first for most businesses.
Software programmes that allow businesses to conceal sales, delete invoices or manipulate accounting records without leaving a trace. By requiring invoicing records to be immutable and chained with a hash, the RRSIF makes any subsequent modification detectable.
Yes. Using software that does not comply with the RRSIF requirements can result in penalties of up to €50,000 per tax year for the user, and up to €150,000 per tax year for the producer or distributor.
The regulatory map of Spanish invoicing in 2026-2027 is complex but manageable once the structure is understood. There are three real changes: adapting software to the RRSIF (SIF), deciding whether to operate in VeriFactu or Non-VeriFactu mode, and preparing to issue and receive invoices in structured format when B2B e-invoicing comes into force.
The key for businesses and advisors is not to treat these three changes as one. Each has its own regulation, its own timeline and its own specific technical requirements. Addressing them separately and in a planned manner is the most efficient way to reach 2027 with all systems in order.
]]>To understand exemptions properly, we must start from the structure of the tax. VAT covers the supply of goods and services carried out by businesses and professionals in the course of their economic activity (Article 4 of Law 37/1992). But not all transactions carried out by a business or professional are taxed the same way — not all of them are even taxed.
There are three basic categories:
Taxable and non-exempt transactions: within the scope of VAT, subject to the applicable rate (21%, 10% or 4%). The business charges VAT to the customer, declares it and has the right to deduct input VAT on its purchases.
Taxable but exempt transactions: within the scope of VAT — the taxable event occurs — but the law releases them from payment of the tax. The business does not charge VAT to the customer, but with important consequences for its right to deduct.
Non-taxable transactions: outside the scope of VAT by definition. No taxable event arises. The tax simply does not exist for that transaction.
This distinction is not merely academic. It has very concrete practical consequences.
Non-taxable transactions are regulated in Article 7 of Law 37/1992. These are transactions that, even when carried out by a business or professional, do not constitute a taxable event under VAT because the law expressly excludes them from its scope. Key examples include:
For these transactions, no VAT invoice is issued because the tax does not exist. If the business issues an invoice, the absence of VAT must be reflected with the notice: "Transaction not subject to VAT under Article 7 of Law 37/1992."
Exempt transactions are within the scope of VAT — the taxable event does occur — but the law, for reasons of fiscal or social policy, releases them from payment. The main regulation is in Articles 20 to 27 of Law 37/1992.
This distinction has a direct impact on the partial exemption (pro-rata rule): if a business simultaneously carries out both taxable non-exempt operations and exempt operations, its right to deduct input VAT is reduced proportionally. If a transaction were non-taxable (Art. 7), it would not enter the pro-rata calculation at all. Misclassifying the two can distort the VAT return.
Article 20 of Law 37/1992 governs exemptions on domestic transactions. These are restricted exemptions: the business does not charge VAT, but nor can it deduct the input VAT on goods and services it acquires to carry out those exempt operations.
The exemptions fall into broad categories:
Exempt: hospitalisation and healthcare services, medical and health services provided by medical or healthcare professionals, and social welfare services. Includes hospitals, clinics, doctors, dentists (with nuances), social workers and day care centres.
Exempt: education of children and young people, childcare and custody, school, university and postgraduate education, and vocational training and retraining provided by public-law bodies or authorised private entities. The key is that the entity must be authorised or recognised: a freelancer providing non-subsidised training generally charges VAT unless they fall within a specific exception.
Exempt: cultural services provided by public bodies or non-profit entities, theatrical, musical and circus performances by these entities, and sporting and recreational services provided to natural persons by non-profit entities or sports federations.
Exempt: insurance and reinsurance operations, brokerage services in financial transactions, and a wide range of financial operations including deposits, loans, guarantees, transfers, foreign exchange transactions and securities transactions. This exemption is broad but has exceptions (portfolio management, for instance, may be taxable).
Exempt: the second and subsequent sale of buildings (the developer's first sale is taxed at the reduced 10% rate), the rental of residential property for use as a home, and the creation and transfer of rights of use over non-buildable land. The rental of commercial premises is taxable and non-exempt (21% rate).
Important: the taxpayer may waive the exemption for transfers of land and buildings (Art. 20.Two VAT Law), converting the transaction into taxable and non-exempt, triggering the reverse charge mechanism.
These are a fundamentally different type of exemption. Exports (Art. 21) and intra-Community supplies of goods (Art. 25) are exempt, but the business retains the right to deduct input VAT. For this reason they are called "full exemptions": the effect is equivalent to a 0% rate applied at destination, rather than a restriction on the right to deduct.
This is the practical core of the issue. Article 6.1.j) of Royal Decree 1619/2012 (Invoicing Regulations) is unambiguous:
Every invoice must contain, among its mandatory items: "Where the transaction documented on the invoice is exempt from Value Added Tax, reference to the applicable legal provisions."
This means that writing "VAT exempt" or simply omitting the tax is not enough. The invoice must identify the specific legal provision that justifies the exemption.
The correct practice — and what the AEAT requires in its reviews — is to include the reference as precisely as possible. Examples:
| Type of transaction | Correct invoice wording |
|---|---|
| Medical service | "VAT exempt. Art. 20.One.3.º Law 37/1992" |
| Educational service | "VAT exempt. Art. 20.One.9.º Law 37/1992" |
| Residential property rental | "VAT exempt. Art. 20.One.23.º Law 37/1992" |
| Financial operation (loan) | "VAT exempt. Art. 20.One.18.º Law 37/1992" |
| Insurance | "VAT exempt. Art. 20.One.16.º Law 37/1992" |
| Export | "VAT exempt. Art. 21 Law 37/1992" |
| Intra-Community supply | "VAT exempt. Art. 25 Law 37/1992" |
| Non-taxable transaction (Art. 7) | "Transaction not subject to VAT. Art. 7 Law 37/1992" |
Where the VAT Law refers to a European Directive, it is also admissible to cite the relevant article of Directive 2006/112/EC alongside the domestic provision.
Omitting the legal reference on an exempt invoice has direct consequences:
1. The invoice is formally invalid as a supporting document, for non-compliance with Art. 6.1.j) of RD 1619/2012. This may prevent the recipient from using it as accounting and fiscal support.
2. Risk of inspection and penalty: the AEAT has systematically identified this error in reviews of subsidised training files (where the issuer invoices as exempt under Art. 20.One.9.º but without citing the provision) and in property transactions. The absence of the reference can be interpreted as a sign that the issuer was uncertain whether the exemption applied.
3. Impact on the recipient: if the recipient has recorded the invoice as supporting an exempt transaction and the invoice turns out to be formally invalid, they may be required to regularise their tax position.
With the entry into force of RD 238/2026 (mandatory B2B e-invoicing), exempt invoices must also be issued in structured format (Facturae, UBL or CII). The exemption reference field (or non-taxable reason) has a specific element in the XML schema of these formats with predefined values.
Under the RRSIF and VeriFactu (RD 1007/2023), the invoicing record generated by the SIF includes the type of transaction, and the correct classification between exempt and non-taxable operations directly affects which records are transmitted (or retained) for the AEAT. A SIF that does not correctly distinguish between exemption and non-taxable status may generate incorrect records that lead to information requests from the Tax Authority.
This is the most important distinction from the business's tax management perspective:
Restricted exemptions (most of those under Art. 20: healthcare, education, insurance, second-transfer buildings, residential rental): the business does not charge VAT, but cannot deduct input VAT on purchases related to those exempt activities. Where both exempt and non-exempt operations are carried out, the pro-rata rule applies to determine what proportion of input VAT can be deducted.
Full exemptions (exports, intra-Community supplies): the business does not charge VAT, but can deduct input VAT. These are "exemptions with the right to deduct", effectively zero-rating at destination. Economically, the effect for the business is equivalent to a 0% rate.
It depends. If the tuition falls within the scope of children's or young people's education, school, university or vocational training provided by an authorised entity, the Art. 20.One.9.º exemption may apply. If the classes are general private tuition not covered by those categories, the service is taxable and non-exempt. The key is whether the activity and the entity meet the exemption's requirements.
Generally no, if the services are healthcare provided by a medical professional (Art. 20.One.3.º VAT Law). But if the doctor provides expert reports, judicial assessments or activities not strictly of a healthcare nature, those services may be taxable and non-exempt. The exemption is not automatic simply by virtue of being a doctor: it depends on the type of service provided.
No. The rental of premises for business activities is taxable and non-exempt at the standard 21% rate. Only the rental of residential property for use as a home (Art. 20.One.23.º VAT Law) is exempt. The error of issuing invoices without VAT for commercial premises is common and has consequences for declared VAT.
The difference is that only the latter satisfies the legal obligation. Article 6.1.j) of RD 1619/2012 requires reference to the applicable legal provisions, not a generic note. Writing only "VAT exempt" without citing the provision makes the invoice formally incomplete.
Yes, although Art. 6.1.j) specifically mentions exemptions. The recognised best practice — and what the AEAT's models require — is to include the reference to Article 7 of Law 37/1992 when the transaction is non-taxable. Without that reference, the invoice is insufficiently informative for the recipient and for any potential inspection.
Only in specific prescribed cases. The most relevant is the waiver of the exemption for property transactions (Art. 20.Two VAT Law): it allows the seller of a second-transfer building to opt to charge VAT (with reverse charge), which is advantageous when the buyer has full right to deduct. Outside this specific case, the exemptions under Art. 20 are non-waivable.
Issuing an invoice without VAT because the transaction is exempt is not sufficient on its own. The law requires knowing why it is exempt and stating it on the invoice, citing the specific article of the VAT Law that justifies the exemption.
This obligation, in force since RD 1619/2012, gains new relevance with e-invoicing and the RRSIF: in structured formats, the exemption basis is a field with predefined values, not free text. If the software does not handle it correctly, the invoicing record may be incorrect.
For advisors, accountants and businesses, periodically reviewing whether the exempt invoices issued or received comply with Art. 6.1.j) of RD 1619/2012 is a basic internal control task that can prevent major problems in an inspection.
See our technical documentation on InvoSeal's invoicing cycle for details on how we manage the classification of exempt and non-taxable transactions in the RRSIF records.
]]>Royal Decree 1007/2023, of 5 December, published in the Spanish Official Gazette (BOE) on 6 December 2023, is the regulation that develops Article 29.2.j) of the General Tax Law, introduced by Law 11/2021 (known as the Anti-Fraud Law). In plain English: it is the regulation that sets out how invoicing software programs must work.
Its goal is not to complicate your life. It is to put an end to so-called "dual-use software": programs that allowed users to keep two sets of accounts, modify already-issued invoices or delete records without leaving a trace. The Spanish Tax Agency (AEAT) estimates that this practice resulted in significant revenue losses, and the regulatory response has been to require any invoicing program (what the regulation calls a Sistema Informático de Facturación or SIF) to guarantee four non-negotiable principles: integrity, conservation, traceability and immutability of records.
For you, as a freelancer or SME, the translation is simple: from the date that applies to you, you will not be able to keep invoicing with Excel, Word, homemade templates or programs that are not adapted to RD 1007/2023. And if you do, the fines are fixed, not graduated, and apply even when there is no fraud whatsoever.
Article 3 of Royal Decree 1007/2023 defines the subjective scope. The regulation applies to all individuals and legal entities carrying out economic activities and issuing invoices through a computer system, including:
There are, however, important exclusions worth knowing:
If you have doubts about your specific case, it is best to consult your tax advisor before making decisions.
RD 1007/2023 obliges you, from the date that applies to you, to use a SIF that complies with the regulation's requirements. In practice, this means:
There are two modalities for compliance: VeriFactu (you send records to the AEAT in near real time) or No-VeriFactu (you keep them locally with reinforced security measures). If you want to dive deeper into the differences, we have a dedicated article: VeriFactu vs No-VeriFactu: Key Differences, 2027 Deadlines and Which to Choose.
For an invoicing program to be considered compliant with RD 1007/2023, it must meet the following eight requirements (essentially set out in Articles 7 and 8 of the regulation):
In addition, on the visible invoice, the tax QR code in accordance with the ISO/IEC 18004 standard, with a size between 30 and 40 millimetres, which the recipient can scan to verify the invoice.
If you want the exhaustive detail of the fields each record must contain, we break it down in this complementary article: Complete Checklist: What an Invoice and a SIF Must Contain Under RD 1007/2023.
This is probably the most important section for you, because it has changed twice in the past year and much content online remains outdated. The dates currently in force (as of April 2026), following the latest modification introduced by Royal Decree-Law 15/2025, of 2 December (BOE of 3 December 2025), are:
| Milestone | Date | Status |
|---|---|---|
| Publication of RD 1007/2023 | 6 December 2023 | ✅ In force |
| Publication of Order HAC/1177/2024 (technical specifications) | 28 October 2024 | ✅ In force |
| Deadline for software manufacturers (9 months from the Order) | 29 July 2025 | ✅ Met |
| AEAT free application available | October 2025 | ✅ Available |
| Obligation for companies (Corporate Income Tax) | 1 January 2027 | 🟡 Upcoming |
| Obligation for freelancers and other obliged parties | 1 July 2027 | 🟡 Upcoming |
In other words: if you are a freelancer, you have until 1 July 2027 to have your invoicing system adapted. If you are a company, your deadline is 1 January 2027.
There is an additional relevant detail: throughout 2026, a testing environment is maintained on the AEAT's website where obliged parties can submit test records without consequences. It is the ideal time to adapt at a calm pace.
The penalty regime is set out in Article 201 bis of the General Tax Law, introduced by Law 11/2021. It distinguishes between two types of offence:
End-user offence (freelancer or SME): the mere possession of a non-certified SIF, when it should be certified, or the use of a certified system that has been modified to bypass controls. The penalty is a fixed pecuniary fine of €50,000 per fiscal year.
Software manufacturer offence: producing, manufacturing or marketing systems that do not comply with the regulation. The penalty rises to €150,000 per fiscal year and per type of software, plus €1,000 for each system marketed without certification when this is required.
The most delicate detail, as confirmed by the AEAT itself in its FAQ, is that the penalty applies for the mere possession or use of non-compliant software, without the inspection having to prove fraud or hidden income. It is enough for the system to be installed and operational. There is a reasonable exception: if you keep the old program only to consult historical invoices but cannot invoice with it, the offence might not be considered committed — always with assessment of the obliged party's behaviour.
The operational recommendation is clear: when you reach your obligation date, uninstall or disable the invoicing function of any old program, export its records and keep them as a historical archive.
These are the concrete steps you can take from today, ordered from least to most effort:
Step 1 — Audit your current situation. What do you invoice with today? If the answer is Excel, Word, a homemade template or an old program, take note that you will need to change before July 2027. If you use a commercial invoicing program, move to step 2.
Step 2 — Ask your provider for the Responsible Declaration. This is the key document, your legal shield. Any legitimate invoicing software provider should be able to deliver it within days. If they stall or do not know what you are talking about, consider changing providers; that is a sign of non-compliance.
Step 3 — Verify the visible elements on your invoices. An invoice issued by a compliant SIF must include, in addition to traditional data: a tax QR code, and — if you work in VeriFactu mode — the mention "Invoice verifiable on the AEAT electronic portal" or the word "VERI*FACTU".
Step 4 — Decide your modality: VeriFactu or No-VeriFactu. This is not a minor decision. The VeriFactu modality is operationally simpler (you send and forget) but implies immediate visibility of your invoices for the AEAT. No-VeriFactu requires more technical responsibilities (event logging, electronic signature) but keeps data local until requested.
Step 5 — If you are a freelancer with few invoices, evaluate the AEAT free application. The Tax Agency has made available since October 2025 a free application for issuing invoices compliant with the regulation. It is functional for low volumes and without integration needs.
Step 6 — If you need integration with accounting, POS, e-commerce or other systems, look for a professional solution. The market for adapted SIFs is already wide and there are solutions for all budgets and verticals.
Step 7 — Take advantage of the testing environment during 2026. Configure your system in test mode, issue some invoices, verify that QRs work, that records are generated correctly. It is free and without consequences.
Step 8 — Keep your tax advisor informed. Compliance with RD 1007/2023 has tax and accounting implications. Your advisor must be aware of the software you use and the chosen modality.
Does RD 1007/2023 require the use of electronic invoicing?
No. RD 1007/2023 regulates the requirements of invoicing software, not the document format. You can keep issuing paper invoices (with QR code) if your activity allows it. The electronic invoicing obligation is a different regulation, coming from RD 238/2026 and the Crea y Crece Law, with different deadlines. They are two obligations that coexist.
What if I am under SII?
If your company is registered under SII (mandatorily or voluntarily), you fall outside the scope of RD 1007/2023. If at any point you exit SII, the regulation would apply to you from that moment.
What if I issue all my invoices by hand, on paper?
Technically, if you do not use any computer system, you are not obliged by RD 1007/2023. In practice, this option is very residual and, with the upcoming mandatory B2B electronic invoicing, will be unfeasible for most activities.
Can I be fined even if my invoicing is correct?
Yes. The penalty under Article 201 bis LGT applies for the mere possession of non-compliant software when it should be certified, without the need to prove fraud. That is why it is so important to adapt before the deadline.
Do I have to change software if I already use one?
It depends on whether your current program is adapted to RD 1007/2023 or not. Ask your provider for the Responsible Declaration: if they have it and it is up to date for your version of the software, you do not need to change. If they do not have it or do not update it, yes you do.
How much does an adapted SIF cost?
There are free options (the AEAT application, valid for freelancers with low volume), options from €5-10 per month for freelancers with medium volume, and enterprise solutions with accounting integration and multi-user functionality in higher ranges. We have a comparative analysis: VeriFactu Invoicing Software 2027: 21 Programs Compared.
Do simplified invoices (tickets) also need to carry the QR?
Yes. Both complete and simplified invoices issued through a SIF must include the tax QR code.
What happens if my system fails and I cannot issue the QR?
The regulation contemplates the possibility of technical incidents. In that case, you must register the event in the system (it is one of the requirements of the event log in No-VeriFactu mode) and issue the pending invoices as soon as the system is operational again. The AEAT does not penalise documented occasional incidents; it does penalise the possession of non-compliant software.
RD 1007/2023 is one of the most relevant invoicing reforms in recent years. For you, freelancer or SME, the keys are three:
Do not wait until June 2027 to start. In the last months before entry into force, providers become saturated, support channels collapse and prices rise. The cost of preparing today is minimal. The cost of not being ready, €50,000.
Related reading:
InvoSeal is a SIF adapted to RD 1007/2023 and Order HAC/1177/2024, with dual VeriFactu / No-VeriFactu modality, SHA-256 hash, chaining, tax QR and Responsible Declaration. If you want to reach 2027 without setbacks, check our documentation or get in touch.
]]>RD 1007/2023 operates at two levels that should not be confused:
Level 1: the Invoicing Information System (SIF). These are the requirements that the invoicing program must meet as software: how it generates records, how it protects them, how it chains them and how it preserves them. Regulated mainly in Articles 7, 8, 10, 11 and 12 of RD 1007/2023 and developed in Order HAC/1177/2024.
Level 2: the invoice as a document. These are the additional elements that the issued invoice must include in its visible representation (paper or electronic): the QR code, the VeriFactu legend (if applicable) and the minimum data under the Invoicing Obligations Regulation (RD 1619/2012), which remains in force and is complementary.
The information system must guarantee six essential characteristics of invoicing records:
For every invoice issued (full or simplified), the SIF must generate — simultaneously with or immediately before the invoice — a record containing at minimum:
| Field | Description |
|---|---|
| Issuer's tax ID (NIF) | Tax identification number of the person required to issue the invoice |
| Issuer's name/company name | Full name or company name |
| Recipient's tax ID (NIF) | When required under RD 1619/2012 |
| Recipient's name/company name | When required |
| Invoice issuer | Indication of whether issued by the obliged party, the recipient or a third party |
| Third party/recipient issuer ID and name | If applicable (Art. 5 and 6 of RD 1007/2023) |
| Invoice number | And series, if applicable |
| Date of issue | Of the invoice |
| Date of transaction | If different from the date of issue |
| Invoice type | Full or simplified |
| Regime key | Applicable VAT regime |
| Description of the transaction | Invoice concept |
| Tax base | By tax rate |
| Tax rate | VAT percentage applied |
| Tax charged | VAT amount |
| Total amount | Of the invoice |
| Exempt base | If the transaction is VAT-exempt, with indication of the cause |
| Non-subject base | If the transaction is not subject to VAT, with indication of the cause |
| Equivalence surcharge | If applicable |
| Withholding | When income tax or other withholding exists |
| Previous record data | Number, series, date and first 64 characters of the hash of the immediately preceding record (chaining) |
| SIF identification | System identification code, name, version and producer's tax ID |
| Generation date and time | Of the record itself (date, hour, minute and second) |
| Fingerprint (hash) | SHA-256 hash calculated over the record's fields |
When an invoice is cancelled, the SIF must generate a cancellation record linked to the original registration record. It contains:
A cancellation record does not delete the original registration record — it supplements it. The original record remains intact and immutable in the system.
Every invoicing record (registration or cancellation) must include a digital fingerprint calculated using the SHA-256 function over defined fields. This fingerprint ensures that any subsequent modification of the content is detectable.
Additionally, each new record must include the first 64 characters of the hash of the immediately preceding record, together with its invoice number, series and date. This creates a cryptographic chain where each record depends on the previous one — if a record is altered or deleted, the chain breaks and the system must trigger an alert.
Before generating a new record, the SIF must verify that the last existing record is correctly chained. If it detects a breach in the integrity chain, it must log an anomaly event.
In No-VeriFactu mode (when records are not sent to the AEAT), the SIF must maintain an immutable event log documenting:
In VeriFactu mode, the event log is not mandatory, as record custody lies with the AEAT.
The SIF manufacturer or producer must issue a Responsible Declaration certifying that the system complies with all requirements of RD 1007/2023 and Order HAC/1177/2024. This declaration must:
Without this declaration, the software cannot be considered compliant and its use may carry fines of up to €50,000 per fiscal year.
Every invoice issued through a SIF adapted to the RRSIF must include a QR code containing:
Technical specifications:
The QR allows the recipient (customer or consumer) to verify the invoice on the AEAT's electronic portal by scanning it with a mobile device or the AEAT app.
Invoices issued by a SIF operating in VeriFactu mode (with record submission to the AEAT) must include the phrase:
"Invoice verifiable at the AEAT Electronic Portal" or simply "VERI*FACTU"
Invoices issued in No-VeriFactu mode must not include this legend.
RD 1007/2023 does not replace the Invoicing Obligations Regulation (RD 1619/2012). Invoices must still contain the data that was already mandatory: sequential number, issuer and recipient details, description, tax base, VAT rate, tax charged, date, etc. What the RRSIF adds is the layer of system requirements (hash, chaining, QR) and software product obligations (Responsible Declaration, event log).
From 2027, using a SIF that does not comply with these requirements is punishable with up to €50,000 per fiscal year for the user, without the AEAT needing to prove fraud. The manufacturer faces fines of up to €150,000 per fiscal year for each non-compliant program sold.
The recommendation is clear: request the Responsible Declaration from your provider, verify it is up to date for the version you use, and if in doubt, consult your tax adviser before the compliance deadline.
Related reading: VeriFactu vs No-VeriFactu: Key Differences, 2027 Deadlines and Which to Choose
Related reading: VeriFactu Invoicing Software 2027: 21 Programs Compared
Related reading: E-Invoicing in Europe 2026-2030: How It Is Being Implemented Country by Country
InvoSeal complies with all requirements of RD 1007/2023 and Order HAC/1177/2024: SHA-256 hash, chaining, tax QR, event log, electronic signature and Responsible Declaration. It also offers dual mode (VeriFactu / No-VeriFactu) so the choice is yours. Check our documentation or get in touch.
]]>A third-party credit seizure is a mechanism whereby the tax authority, faced with an unpaid tax debt, orders the taxpayer's customer to pay directly to the treasury instead of to the taxpayer. The money never reaches the debtor: it goes straight from the customer to the tax authority.
In practice it works like this:
This mechanism is not new. What is new is the speed and precision with which tax authorities can execute it thanks to real-time e-invoicing data.
Italy was the first EU country to mandate B2B e-invoicing in 2019. Since then, the Agenzia delle Entrate has had complete access to all invoices issued and received by every taxpayer through the Sistema di Interscambio (SdI) — structured data, in real time, with full details of amounts, dates, issuer and recipient.
The Manovra 2026 (Italian Budget Law for 2026) went further: it expressly authorises the Agenzia delle Entrate-Riscossione to use e-invoice data from SdI to locate trade receivables and initiate faster, more targeted third-party seizures (pignoramenti presso terzi).
Until now, the main bottleneck was finding the right third party — the correct customer with an interceptable receivable. Of roughly 600,000 third-party seizures executed annually in Italy, only 22.5% succeeded, with an average collection of €10,500. With access to e-fatture data, the tax authority can analyse a taxpayer's last six months of invoicing and detect recurring customers, stable commercial relationships and predictable cash flows. The stated goal is to collect over €1 billion in additional annual revenue.
The consequences for Italian business owners are direct: if they have outstanding tax debts and issue invoices to customers, the Agenzia can block collection of those invoices before the money reaches their account. And the customer who receives the seizure notice finds themselves in a difficult position: they must decide whether to pay the tax authority or their supplier, with legal consequences either way.
In Spain, the third-party credit seizure mechanism is regulated under the General Tax Law (Art. 171) and the General Collection Regulation (RD 939/2005). The AEAT can directly notify seizure orders to a debtor's customer, requiring payment to the treasury.
With VeriFactu in submission mode, the AEAT receives invoicing records in real time. This means it can technically know the moment a taxpayer with outstanding debts issues an invoice to a customer, identify the commercial relationship and act on that receivable.
What about No-VeriFactu? In No-VeriFactu mode, the AEAT does not receive invoicing records in real time. It only gains visibility of a taxpayer's transactions when Form 347 is filed in February of the following fiscal year, or when records are formally requested during an inspection. This means the window for executing targeted seizures based on invoicing data is considerably narrower.
This difference is not accidental: it is one of the reasons why RD 1007/2023 expressly offers both modes. The taxpayer who chooses No-VeriFactu breaches no rule — they simply do not provide real-time access to their invoicing data.
With KSeF operational since 2026, the Polish tax authority (KAS) has real-time access to all invoices issued and received by any taxpayer. The technical capability to identify trade receivables and execute seizures exists, just as in Italy.
However, unlike Italy, Poland has not explicitly regulated the use of KSeF data for enforcement purposes as directly. Polish fiscal enforcement laws allow third-party credit seizures, but the formal link to e-invoicing data has not been established with the same clarity as in the Italian Manovra.
That does not mean it cannot happen. The Italian precedent sets the path, and any country with a centralised clearance system has the infrastructure to do the same.
In countries using exchange (Peppol) or post-audit models, the tax authority does not have real-time access to invoicing data on a transaction-by-transaction basis. Information arrives through periodic VAT declarations, annual lists or SAF-T files upon request.
This significantly limits the ability to execute targeted credit seizures based on recent invoicing data. Seizures still exist, but they rely on older, less granular information.
| Country | Real-time access to invoices | Seizures based on invoice data | Specific legal framework |
|---|---|---|---|
| Italy | Yes (SdI, since 2019) | Yes, formalised in Manovra 2026 | Art. 72-bis DPR 602/73 + SdI access |
| Spain | Yes (VeriFactu submission) / No (No-VeriFactu) | Yes, operational capability active | Art. 171 LGT + VeriFactu data |
| Poland | Yes (KSeF, since 2026) | Technical capability, not specifically regulated | Fiscal enforcement laws + KSeF |
| France | From Sep 2026 (PDP/PPF) | To be determined (system deploying) | Pending |
| Romania | Yes (RO e-Factura) | Probable (centralised clearance) | Romanian fiscal legislation |
| Belgium | Partial (Peppol decentralised) | Limited (no central clearance) | General procedures |
| Germany | No (post-audit → 2027) | No (no real-time data) | Judicial procedures |
| Nordics | Partial (Peppol B2G) | Limited | General procedures |
When the tax authority seizes a trade receivable, the person directly affected is not only the tax debtor — it is also their customer. The customer receives a notification ordering payment to the treasury instead of to their supplier. Ignoring it can lead to their own penalties. Paying it can create a conflict with their supplier. If the invoice is in dispute, the situation becomes exponentially complex.
A credit seizure can freeze a business's cash flow immediately. If a business depends on monthly collections from a few large customers (common in construction, professional services, distribution), a single seizure can leave it without liquidity for payroll, suppliers or rent. With real-time e-invoicing, that seizure can arrive hours after issuing the invoice.
The customer who receives a seizure order does not merely learn that their supplier has tax debts — the seizure notice itself discloses the exact amount of the debt: the sum not paid during the voluntary period, the enforcement surcharge, interest and procedural costs. In other words, the AEAT shares detailed fiscal data about the debtor taxpayer with a third party (the customer), without the debtor's consent for that disclosure.
This amounts to a direct breach of the spirit of the LOPD and GDPR that the General Tax Law grants itself. Article 95 of the LGT establishes the confidential nature of tax data. Yet the seizure notice includes the exact amount of the taxpayer's debt — principal, enforcement surcharge, interest and costs — even though that information is not necessary to execute the seizure.
The seizure mechanism does not require it: the AEAT orders the customer to withhold all pending payments to the supplier and asks the customer how much they owe and when those payments are due. That is all it needs to execute the withholding. It does not need to tell the customer how much the supplier owes the treasury. Yet it does. The result is that the customer learns the detailed fiscal situation of their supplier — information they are not entitled to, did not request, and which data protection regulation would prohibit in any other context.
So why does the AEAT do it? The only operational explanation is pressure. A customer who knows their supplier owes a specific amount to the treasury changes their behaviour: they may tighten payment terms, demand additional guarantees, seek alternative suppliers, or simply lose trust. Disclosing the debt amount does not help execute the seizure; it helps create an environment of social and commercial pressure on the debtor. And the taxpayer can neither prevent it nor was consulted about it.
How long has this been happening? Third-party credit seizures are not a novelty of the digital age. The AEAT has been executing this mechanism since the General Tax Law of 2003 (Law 58/2003), which formalised the procedure in Articles 170 and 171, and the General Collection Regulation (RD 939/2005), which developed it in Article 81. But the precedents go further back: the former General Collection Regulation of 1990 (RD 1684/1990) already provided for third-party credit seizures as a collection tool. What changes with real-time e-invoicing is not the legal instrument but the ability to select the target: previously the AEAT needed to actively investigate the debtor's commercial relationships; now, with VeriFactu or Italy's SdI, that information arrives on its own.
Know your tax situation. Before choosing between VeriFactu and No-VeriFactu, check whether there are outstanding tax debts. If so, real-time visibility multiplies the risk of targeted seizures.
Consciously choose your software mode. If your invoicing software only allows VeriFactu, you have no option to limit the visibility you give the tax authority. Dual software (VeriFactu / No-VeriFactu) allows you to make that decision informed.
Keep instalment plans up to date. Spanish law provides that while a taxpayer is current on an instalment plan, the AEAT cannot initiate new enforcement actions — including credit seizures.
Involve your tax adviser. The choice between VeriFactu and No-VeriFactu is not just technical: it has direct implications for enforcement risk. Your tax adviser should participate in that decision.
Related reading: VeriFactu vs No-VeriFactu: Key Differences, 2027 Deadlines and Which to Choose
Related reading: E-Invoicing in Europe 2026-2030: How It Is Being Implemented Country by Country
InvoSeal offers dual mode (VeriFactu and No-VeriFactu) precisely so the business owner, together with their adviser, can decide the level of visibility they give to the tax authority. If you want to understand how this affects your business, check our documentation or get in touch.
]]>On 11 March 2025 the EU Council formally adopted the ViDA (VAT in the Digital Age) package, the most ambitious reform of the European VAT system since its creation. Published in the Official Journal on 25 March 2025, ViDA sets out a progressive timeline culminating in 2035:
ViDA's message is clear: the structured electronic invoice will become Europe's single standard. PDFs, paper invoices and unstructured formats will no longer be valid for intra-Community transactions.
Not all countries implement e-invoicing the same way. There are three broad models:
Clearance model: the invoice passes through a centralised tax authority system that validates it before it becomes legally valid. Italy pioneered this with the Sistema di Interscambio (SdI) in 2019. Poland has followed with KSeF. Spain's VeriFactu in submission mode comes close to this model.
Exchange model (Peppol/networks): invoices are exchanged between businesses through certified networks such as Peppol, without necessarily passing through a central fiscal validator. Belgium and the Nordic countries use this approach. Invoices are reported to the tax authority in parallel or afterwards.
Post-audit model: invoices are freely issued and the tax authority reviews them later, typically through SAF-T files or periodic reporting. Germany and several Eastern European countries are transitioning from this model towards more active ones.
In practice, many countries combine elements of several models. France, for example, uses certified platforms (PDP) in a "five-corner" model that blends private exchange with centralised reporting.
Italy was the first EU country to mandate B2B e-invoicing, in January 2019. All domestic invoices (B2B, B2C and B2G) must be issued in FatturaPA format (a proprietary XML schema) and transmitted through the Sistema di Interscambio (SdI), which acts as a centralised validation platform. Any other format must be converted to FatturaPA before submission. It is Europe's most mature clearance model.
Poland has launched its KSeF (Krajowy System e-Faktur) system in phases: from February 2026 for large taxpayers (turnover >PLN 200M) and from April 2026 for all others. It uses the FA(3) XML format, a proprietary schema, and a centralised clearance model where every invoice must pass through KSeF and receive an identifier before being sent to the customer. The legal invoice is always the XML; the PDF is merely a visualisation.
Since 1 January 2026 all Belgian VAT-registered businesses must exchange B2B invoices in structured format via the Peppol network using Peppol BIS (UBL 2.1) format. It is the first EU country to make Peppol mandatory for B2B — a decentralised approach without a central fiscal platform.
France begins its rollout in September 2026. All businesses must be able to receive e-invoices. Large and medium-sized companies must also issue them. SMEs and micro-businesses will join in September 2027. The model uses certified private platforms (PDP) connected to a public central platform (PPF) acting as a directory and data concentrator. It accepts three formats: UBL, CII and Factur-X (a Franco-German hybrid format).
Germany has required the ability to receive e-invoices since January 2025. The obligation to issue them will come in stages: January 2027 for companies with turnover above €800,000 and January 2028 for all others. No single format is mandated — any format compliant with the EN 16931 standard is accepted (the most common being XRechnung and ZUGFeRD). Germany's approach is pragmatic, with extended transition periods.
Spain is implementing two parallel regulations. On one hand, VeriFactu (RD 1007/2023), which governs the technical requirements of invoicing software (hash, chaining, QR, optional submission to AEAT) with a deadline of January 2027 for corporations and July 2027 for freelancers. On the other, mandatory B2B e-invoicing (Law 18/2022, Crea y Crece), developed by RD 238/2026, which sets the following dates:
The public e-invoicing solution will be available on the AEAT's electronic portal at least 2 months before the first application date.
What makes Spain distinctive is that VeriFactu offers two modes (VeriFactu and No-VeriFactu), and it is the taxpayer who chooses — a flexibility rarely found in the European landscape.
In addition, the Resolution of 18 December 2024 (BOE-A-2024-27600) approved standardised representation documents for submitting VeriFactu records through third parties. This defines how software companies and tax professionals (accountants, advisers) can act as representatives of the taxpayer before the AEAT, establishing three models: direct representation from taxpayer to software provider (Annex I), from taxpayer to tax professional (Annex II), and from tax professional to software provider (Annex III). It is a key piece of infrastructure that enables accountancy firms and SaaS platforms to submit records on behalf of their clients.
Portugal already requires structured format (CIUS-PT) for B2G and QR codes on B2B invoices. Mandatory B2B e-invoicing is planned for January 2027 via the Peppol network.
Romania has its RO e-Factura system active with B2B mandates since 2024, expanding to simplified B2C invoices in 2025. It is another clearance model where invoices pass through a centralised validation system.
Sweden, Norway, Denmark and Finland have been using Peppol for B2G for years and have mature infrastructure. Denmark will require digital accounting systems compatible with e-invoicing and SAF-T from January 2026. Norway plans mandatory B2B e-invoicing in 2027 and digital bookkeeping by 2030.
Greece has an active electronic tax reporting system and offers financial incentives to businesses that adopt e-invoicing early: 100% additional depreciation on technology and 100% increase in deductible expenses for creating and managing e-invoices.
| Country | B2G mandatory | B2B mandatory | Model | Main format |
|---|---|---|---|---|
| Italy | Yes (since 2014) | Yes (since 2019) | Clearance (SdI) | FatturaPA (XML) |
| Poland | Yes | Yes (2026, phased) | Clearance (KSeF) | FA(3) (XML) |
| Belgium | Yes | Yes (January 2026) | Exchange (Peppol) | Peppol BIS / UBL 2.1 |
| France | Yes | Sep 2026 (receipt) / Sep 2027 (SME issuance) | Hybrid (PDP + PPF) | UBL, CII, Factur-X |
| Germany | Yes | 2027-2028 (issuance) | Post-audit → transition | XRechnung, ZUGFeRD (EN 16931) |
| Spain | Yes | Oct 2027 (>€8M) / Oct 2028 (rest) | VeriFactu (clearance/local) | Facturae + VeriFactu XML |
| Portugal | Yes | Planned 2027 (Peppol) | Exchange (Peppol) | CIUS-PT |
| Romania | Yes | Yes (2024) | Clearance (RO e-Factura) | XML |
| Denmark | Yes | 2026 (digital systems) | Post-audit + SAF-T | EN 16931 |
| Norway | Yes (2019) | Planned 2027 | Exchange (Peppol) | EHF / Peppol BIS |
| Greece | Yes | Partial (incentives) | Reporting + incentives | myDATA XML |
Despite the differences, several elements recur across all countries:
Paper and PDF are disappearing as legal formats. In all advanced models the legally valid invoice is the structured XML file. The PDF, if it exists, is merely a visual representation. A mismatch between XML and PDF can entail serious fiscal risks (as seen in Poland with KSeF).
The EN 16931 standard is emerging as the common foundation. It is the European reference standard for electronic invoices, revised in 2025 for B2B transactions. Each country may add its CIUS (national usage specification), but the core is the same.
The trend is towards real-time reporting. Whether through clearance (Italy, Poland), voluntary submission (Spain with VeriFactu) or parallel reporting (France), the direction is for tax authorities to have access to invoicing data almost at the moment of issuance.
Penalties for non-compliance are significant everywhere. From €50,000 per fiscal year in Spain to proportional fines based on turnover in other countries.
There is an aspect of real-time e-invoicing that rarely appears in official guides but has a direct impact on business operations: the use of invoicing data to accelerate credit seizures.
When a tax authority has real-time access to all invoices issued by a taxpayer, it can not only verify VAT compliance — it can also quickly identify which customers owe money to the taxpayer and act on those receivables if the taxpayer has outstanding tax debts.
Italy has already formalised this. The Manovra 2026 (Italian Budget Law) expressly authorises the Agenzia delle Entrate-Riscossione to use e-invoice data from the Sistema di Interscambio (SdI) to locate receivables from customers and initiate faster, more targeted pignoramenti (seizures). The stated goal is to collect over €1 billion in additional annual revenue. Of roughly 600,000 third-party seizures executed each year in Italy, only 22.5% succeed; with e-fatture data, the tax authorities expect to significantly improve that success rate by identifying the right third party — the customer where an interceptable receivable exists.
Spain has the same capability. With VeriFactu in submission mode, the AEAT receives invoicing records in real time and can cross-reference data to issue credit seizure notifications on recently registered invoices if the issuer has outstanding debts. This is precisely one of the reasons why RD 1007/2023 offers No-VeriFactu as an alternative: the taxpayer who does not send records in real time does not expose that information until they file Form 347 in February of the following fiscal year, or until the AEAT formally requests it in an inspection.
Poland (KSeF) grants the tax authority (KAS) real-time access to all invoicing data. Although the explicit use for credit seizures has not been regulated as openly as in Italy, the technical capability is there: KAS can see every invoice issued and received by any taxpayer the moment it is issued.
Belgium, Germany and the Nordic countries operate with exchange (Peppol) or post-audit models where the tax authority does not have immediate access to invoicing data on a transaction-by-transaction basis. Information arrives through periodic declarations or upon request. This limits the tax authorities' ability to act in real time on the taxpayer's receivables.
This difference is relevant and should be a factor in the evaluation of any invoicing system. It is not just about regulatory compliance, but about understanding the practical consequences of each model for the taxpayer's relationship with their tax authority.
Spain occupies a middle position. It is not a pioneer like Italy nor does it have a system as advanced as Poland's KSeF, but it is not lagging either: VeriFactu is a technically robust system that covers the requirements of integrity, traceability and immutability, and offers the taxpayer something few European systems offer — the option to choose between sending records to the tax authority in real time or keeping them locally with equivalent security measures.
That flexibility is a distinguishing feature. In Italy there is no choice: everything goes through SdI. In Poland there is no choice: everything goes through KSeF. In Belgium there is no choice: everything goes via Peppol. In Spain, the taxpayer decides.
The question is whether that flexibility will survive once B2B e-invoicing (Ley Crea y Crece) comes into force and ViDA requires alignment with the European standard by 2035. Businesses that prepare now with systems capable of operating in both modes will be best positioned for whatever comes next.
Related reading: VeriFactu vs No-VeriFactu: Key Differences, 2027 Deadlines and Which to Choose
Related reading: VeriFactu Invoicing Software 2027: 21 Programs Compared
InvoSeal is designed to comply with both VeriFactu requirements and European e-invoicing standards. If you want to prepare your invoicing for European regulatory convergence, check our documentation or get in touch.
]]>Before getting into the comparison, it is worth understanding a distinction that the Tax Agency itself draws in its official FAQ. According to the AEAT, invoicing information systems (SIF) on the market can be of two types:
This matters because not all programs on the market offer the same flexibility. Some force you to send your records to the tax authorities in real time with no option to choose No-VeriFactu mode; others give you the ability to choose based on your business needs.
Is there an official list of approved software? No. The AEAT does not certify or publish an official list of authorised programs. It is the manufacturers themselves who must guarantee compliance through a Responsible Declaration, which must be visible in the software and updated with each version. What you should ask your provider for is that declaration — not a supposed "approval" that does not exist.
The following table lists the main invoicing programs available on the Spanish market as of April 2026, organised by mode: dual systems first (those that respect the choice the law grants to taxpayers), then VeriFactu-only, and finally non-compliant tools. The information has been obtained from each product's official pages and their public statements on RRSIF adaptation.
| Software | Mode | Type | Target profile | Indicative price |
|---|---|---|---|---|
| Holded | Dual (VeriFactu / No-VeriFactu) | Cloud (ERP) | Freelancers, SMEs, startups | From €7.50/month |
| Sage 50 | Dual (configurable) | Hybrid (desktop + cloud) | SMEs, accountancy firms, retail | From €35/month |
| Wolters Kluwer (a3) | Dual (configurable) | Desktop + cloud | Accountancy firms, SMEs, freelancers | From €9.95/month |
| InvoSeal | Dual (VeriFactu / No-VeriFactu) | Cloud (web app) | Freelancers, SMEs, companies | On request |
| ClassicGes (AIG) | Dual (VeriFactu / No-VeriFactu) | Desktop | SMEs, retail, distribution | On request |
| ClaveiPro / ClaveiGes | Dual (toggle-configurable) | Desktop (ERP) | Industrial SMEs, distribution, agri-food | On request |
| SAP Business One + Inforges | Dual (VeriFactu module) | Desktop (ERP) | Medium and large enterprises | On request |
| Software | Mode | Type | Target profile | Indicative price |
|---|---|---|---|---|
| AEAT free app | VeriFactu only | Cloud (AEAT web) | Freelancers with few invoices | Free |
| Quipu | VeriFactu (active submission) | Cloud | Freelancers, micro-businesses, accountancy firms | From €11/month |
| TeamSystem Factusol | VeriFactu (adapted with submission) | Desktop + cloud | SMEs, retail, distribution | From €0 (basic version) |
| TeamSystem Facturas Billin | VeriFactu (active submission) | Cloud | Freelancers, micro-businesses | From €9/month |
| STEL Order | VeriFactu (adapted) | Cloud | Service SMEs, mobile workforce | From €19.90/month |
| SeniorConta / SeniorFactu | VeriFactu only | Desktop + cloud | SMEs, freelancers | On request |
| Contasimple | VeriFactu (adaptation plan announced) | Cloud | Freelancers with accounting knowledge | From €0 (basic version) |
| Declarando | VeriFactu (adapted) | Cloud | Freelancers | From €29.99/month |
| Alegra | VeriFactu (ES version adapted) | Cloud | Freelancers, micro-businesses | From €9/month |
| FacturaDirecta | VeriFactu (active mode) | Cloud | Freelancers | From €6/month |
| Facturavia | VeriFactu only | Cloud | Freelancers, SMEs | From €12/month |
| B2Brouter | VeriFactu (as a service/API) | Cloud (API/portal) | Developers, companies with own ERP | Volume-based |
| Verifacti (API) | VeriFactu only (API) | Cloud (API) | Software developers | Volume-based |
| Software | Mode | Type | Target profile | Indicative price |
|---|---|---|---|---|
| Excel / Word / templates | Non-compliant | — | — | Fines of up to €50,000 |
Important note: this table reflects information published by manufacturers as of April 2026. Terms, prices and modes may change. Always verify directly with the provider and request the Responsible Declaration before purchasing.
There is a fact that often goes unnoticed in this debate: RD 1007/2023 expressly recognises two legal operating modes — VeriFactu and No-VeriFactu — and leaves the choice in the hands of the taxpayer. This is not a matter of complying more or less; both modes are equally valid and regulated in equal detail. The AEAT itself confirms this in its FAQ by distinguishing between "VeriFactu-only" and "dual" SIFs.
Yet when you look at the market, most invoicing programs only offer VeriFactu. Of the 21 systems covered in this comparison, only 7 are dual. The rest have chosen to implement only the automatic submission mode, effectively eliminating an option that the law grants to taxpayers.
Why does this happen? Because developing a dual system is technically more demanding: it requires implementing both the AEAT submission layer and the local electronic signature, event log and immutable custody layer. And because the AEAT, understandably, encourages the use of VeriFactu — a system where the tax authorities receive all information in real time is more convenient for fiscal control.
What is the problem? Software that only offers VeriFactu takes away from the taxpayer a decision that the law recognises as theirs. And that decision is not trivial:
These are real implications for the taxpayer's relationship with the tax authorities, and it should be the taxpayer and their tax adviser who decide — not the software provider by default.
Dual-mode software is not a luxury; it is respect for the taxpayer's right to choose. If your invoicing program only allows VeriFactu, it is not because the law requires it — it is because the manufacturer decided not to implement the other option. And that, at the very least, is something you should consider before signing up.
These are the most flexible and the ones that respect the choice the law grants to taxpayers. They allow the user to choose the operating mode and, in some cases, to switch from one to the other (with the restriction that, once VeriFactu is activated, the option remains in effect at least until 31 December of the year in which the first submission was made).
Holded is one of the best known in this category. In its settings panel (Compliance > Invoicing) it allows you to select "Yes VeriFactu", "No VeriFactu" or "Exempt". Once VeriFactu is activated, approved invoices are locked and sent with a verifiable QR. If No-VeriFactu is chosen, the system still guarantees integrity and immutability but does not perform automatic submission.
Sage 50, with its hybrid desktop + cloud model, also offers dual configuration. It is particularly strong in environments where accounting precision and fiscal depth are priorities: accountancy firms, retail with complex inventory, multi-activity businesses.
Wolters Kluwer (a3) offers dual mode with a clear settings screen where the user indicates whether they want to send records via VeriFactu or not. If No-VeriFactu is chosen, the system generates signed records and an exportable event log for any request from the tax authorities. It includes a Responsible Declaration and is especially popular among accountancy firms and professional practices.
InvoSeal is a cloud-based web application designed from its architecture to offer dual mode. The user can configure whether to operate in VeriFactu (with automatic submission to the AEAT) or No-VeriFactu (with local custody, electronic signature and event log), and switch modes as needed while respecting the time restrictions set by the regulation.
Specialised ERPs such as ClaveiPro, ClaveiGes and the Inforges integrations for SAP Business One also offer dual mode, generally activated via a configuration toggle. They are the natural choice for industrial SMEs, distributors or agri-food companies that may have operating centres with and without connectivity.
ClassicGes (AIG) is another interesting dual option for retail and distribution, with its Responsible Declaration updated in each Service Pack.
These programs only allow operation in VeriFactu mode. Every invoice you issue generates a record that is automatically sent to the AEAT. You have no option to retain records locally.
Advantage: maximum simplicity. There is nothing to decide: everything is sent. Ideal if you have no objection to the tax authorities having immediate and complete visibility of your invoicing.
Drawback: no flexibility. If at any point you need to operate in an environment without connectivity or prefer not to give the AEAT real-time access (for example, given the possibility of the tax authorities issuing credit seizure notifications on recently registered invoices if you have outstanding debts), you will not have that option. The software provider has made that decision for you.
The AEAT's free application is the most obvious case: it operates exclusively in VeriFactu, does not allow exporting records to another SIF and has functional limitations (no simplified invoices, no accounting integration). But for a freelancer with few invoices per month, it does the job perfectly.
Others such as Facturavia, SeniorConta / SeniorFactu (by DSG Software) or Verifacti also operate exclusively in VeriFactu. SeniorConta is a desktop program with a cloud option, aimed at SMEs and freelancers, combining invoicing and accounting with automatic submission to the AEAT. Verifacti works as an API for developers who want to integrate AEAT submission into their own software without developing the communication layer.
Several popular programs have announced their VeriFactu adaptation and offer record submission to the AEAT, but do not explicitly document a configurable No-VeriFactu mode. This does not mean they lack it internally — they may simply not highlight it commercially because the AEAT encourages VeriFactu — but it is worth asking the provider directly before assuming the option exists.
Quipu has completed its adaptation and issues invoices with an AEAT stamp, QR and verifiable URL. Its approach is clearly VeriFactu-oriented, with powerful banking integration (OCR, reconciliation).
TeamSystem Factusol and TeamSystem Facturas Billin (formerly Billin) are adapted with automatic submission, QR and immutable records. Factusol has the advantage of integrating inventory management, collections and payments in a very complete environment for SMEs.
STEL Order targets service companies with mobile workforces (plumbers, electricians, maintenance), with a native app and field invoicing.
Declarando combines VeriFactu invoicing with tax planning and deduction management, making it attractive for freelancers looking to optimise their income tax.
From 2027 onwards, it will no longer be valid to invoice with Excel, Word, editable PDF templates or any program that does not meet the RRSIF requirements. The fine for merely using non-compliant software is up to €50,000 per fiscal year, without the AEAT needing to prove fraud.
If you currently invoice with any of these tools, 2026 is the year to migrate. The AEAT's recommendation for those using non-compliant software is to export historical records and uninstall the program before the compliance deadline.
Before choosing invoicing software, ask the provider these questions:
Does it have a published Responsible Declaration? This is the only document that certifies compliance. If it does not have one, it is not legally compliant. Remember: the AEAT does not certify software; it is the manufacturer who self-certifies.
Does it support dual mode (VeriFactu and No-VeriFactu)? If you value being able to choose, make sure the option exists and is documented. If it only offers VeriFactu, understand what that implies in terms of visibility to the tax authorities.
What happens if I want to change mode? The regulation allows switching from No-VeriFactu to VeriFactu at any time. But once VeriFactu is activated, the option remains in effect at least until 31 December of the following year. The reverse switch has restrictions.
How does it handle submission incidents? In VeriFactu mode, if the connection to the AEAT fails, the system must retry periodically. Ask whether it has an automatic send queue and error handling.
Does it integrate with my accounting, bank or ERP? Invoicing does not exist in a vacuum. Consider whether the program connects with your actual workflow.
What does it cost and what is included? Some basic plans do not include VeriFactu or offer it as an add-on. Verify that compliance functionality is included in the plan you are purchasing.
There is no universally "best software". The choice depends on your invoicing volume, your technical infrastructure, your comfort level with tax authority visibility, and the degree of integration you need with other systems.
What is universal: from 2027, the software you use must comply with RD 1007/2023. If it does not, the financial consequences can be severe. And if you are still invoicing with Excel or templates, the clock is ticking.
Related reading: VeriFactu vs No-VeriFactu: Key Differences, 2027 Deadlines and Which to Choose
Related reading: E-Invoicing in Europe 2026-2030: How It Is Being Implemented Country by Country
InvoSeal is a dual invoicing system designed from the ground up to comply with the requirements of RD 1007/2023, giving users the choice between VeriFactu and No-VeriFactu mode according to their business needs. If you want to find out how InvoSeal can fit into your operations, check our documentation or get in touch.
]]>To understand VeriFactu you need to go back to Law 11/2021 on the prevention and fight against tax fraud (known as the Anti-Fraud Law). This law introduced a new obligation in Article 29.2.j) of the General Tax Law: all invoicing information systems (SIF, for their Spanish acronym) must guarantee the integrity, preservation, accessibility, legibility, traceability and immutability of invoicing records.
The goal was clear: to put an end to so-called "dual-use software" — programs that allowed invoices to be altered or deleted in order to conceal income from the tax authorities.
The detailed regulation came with Royal Decree 1007/2023 of 5 December, which enacted the Regulation on Requirements for Invoicing Information Systems (RRSIF). This regulation sets out the technical requirements that every invoicing program must meet, regardless of whether VeriFactu or No-VeriFactu mode is chosen.
Subsequently, Ministerial Order HAC/1177/2024 of 17 October developed the detailed technical, functional and content specifications that SIFs must implement. And RD 254/2025 together with RDL 15/2025 adjusted the implementation deadlines, as we will see below.
The complete regulatory chain is as follows:
Before getting into the differences, it is worth understanding what the regulation requires of every invoicing information system, whether VeriFactu or No-VeriFactu. RD 1007/2023 establishes that any SIF must meet these requirements:
Invoice registration record: for every invoice issued (full or simplified), the system must generate — simultaneously with or immediately before the invoice — a record containing mandatory minimum data. This record is not the invoice PDF but a structured summary in XML format.
Cancellation record: when an invoice is cancelled, a cancellation record must be generated and linked to the original registration record.
Digital fingerprint (SHA-256 hash): every record must include a hash calculated over key fields, ensuring that the content has not been altered.
Record chaining: each new record includes data from the previous record (issuer's tax ID, invoice number, date and the first 64 characters of the previous hash). If the chain breaks, the system must trigger an alert.
Tax QR code: every invoice issued through a SIF must include a readable QR code containing basic information for verification.
Legal preservation: records must be kept for the period required by the General Tax Law (generally 4 years, extendable in certain cases).
Producer's Responsible Declaration: the software manufacturer must issue a document certifying that its program complies with all requirements of RD 1007/2023 and Order HAC/1177/2024. Without this declaration, the software cannot be considered compliant.
From this point on the two modes diverge: one sends records to the tax authorities in real time and the other stores them locally with additional security measures.
VeriFactu mode (or "verifiable invoice issuance system") means that each invoicing record is automatically and immediately submitted to the AEAT's electronic portal at the moment it is generated.
When you issue an invoice with a VeriFactu system, the following happens:
No-VeriFactu mode (or "non-verifiable invoice issuance system") meets all the technical requirements of RD 1007/2023 but does not send records to the AEAT automatically. Instead, it stores them securely on the taxpayer's own systems.
| Aspect | VeriFactu | No-VeriFactu |
|---|---|---|
| Record submission to AEAT | Automatic, in real time | Only upon express request |
| Local electronic signature | Not required for each record | Mandatory (qualified) for each record |
| Event log | Not required | Mandatory and immutable |
| Record custody | AEAT + local (shared responsibility) | 100% taxpayer's responsibility |
| Hash and chaining | Mandatory | Mandatory |
| QR code on invoice | Yes, verifiable at AEAT portal | Yes, but not verifiable at AEAT portal |
| Legend on invoice | "Invoice verifiable at the AEAT Electronic Portal" | No verifiability legend |
| Internet dependency | High (with offline fallback) | Low |
| Technical complexity of SIF | Lower | Higher |
| Pre-filled VAT drafts | Yes (future) | No |
| Legal validity | Fully valid | Fully valid |
Both modes are legally valid. The AEAT recommends VeriFactu, but the choice lies with the taxpayer. Here are some practical guidelines:
Yes. In mixed environments (for example, a company with offices in urban areas and points of sale in rural zones), it is possible to use VeriFactu systems in some channels and No-VeriFactu in others. Each SIF must individually meet the requirements corresponding to its mode.
Since October 2025 the Tax Agency has had a free invoicing application available on its electronic portal that operates in VeriFactu mode. It is aimed at freelancers and small businesses with a low volume of invoices.
Key features:
It is a good starting point, but businesses with higher volumes or needs for integration with accounting systems will need specialised software.
The Immediate Supply of Information (SII) is a pre-existing system through which certain companies (generally large ones, with turnover exceeding 6 million euros) already send the AEAT data on their issued and received invoices in near real time.
Companies enrolled in the SII — whether mandatorily or voluntarily — are exempt from implementing VeriFactu. They are two different systems, with different obligations, for different audiences. They are neither compatible with nor complementary to each other.
If a company ever decides to leave the SII, the RRSIF rules would then apply and it would need to adapt its system to one of the two modes (VeriFactu or No-VeriFactu).
The regulation has undergone several postponements. These are the definitive deadlines under RDL 15/2025:
| Milestone | Date |
|---|---|
| Publication of RD 1007/2023 (RRSIF) | 7 December 2023 |
| Publication of Order HAC/1177/2024 (technical specifications) | 28 October 2024 |
| RD 254/2025: first deadline extension | 1 April 2025 |
| Deadline for software producers (9 months from the Order) | 29 July 2025 |
| AEAT free application available | Since October 2025 |
| RDL 15/2025: second deadline extension | 2 December 2025 |
| Mandatory for corporations (Corporate Tax) | 1 January 2027 |
| Mandatory for freelancers and other taxpayers | 1 July 2027 |
| AEAT inspection campaigns expected | Second half of 2027 |
The current period (2026) is a transition and preparation year. The AEAT allows testing with records in its external testing environment, and you can stop submitting test records at any time without consequences.
The penalty regime is severe and distinguishes between different types of infringement:
From 2027 onwards, it will no longer be valid to use Excel, Word, manual templates or any program that does not meet the RRSIF requirements. Anyone invoicing through a SIF must ensure that the system is compliant.
A common source of confusion is mixing up VeriFactu with the B2B electronic invoicing obligation. They are distinct — though complementary — regulations:
Software can comply with VeriFactu and still issue invoices on paper (with a QR code). And an electronic invoice in Facturae format does not necessarily comply with VeriFactu if the system that generated it lacks hashing, chaining and a Responsible Declaration.
The ideal approach is to prepare for both obligations simultaneously, as many software providers are integrating both sets of requirements into a single update.
The obligation is real, the deadlines are set and the penalties are significant. Here is what you can do now:
Related reading: Invoicing Software Comparison: Which Ones Offer VeriFactu, No-VeriFactu, or Both?
Related reading: E-Invoicing in Europe 2026-2030: How It Is Being Implemented Country by Country
InvoSeal is designed from the ground up to comply with the requirements of RD 1007/2023. If you want to find out how InvoSeal can help you prepare your invoicing for 2027 — whether in VeriFactu or No-VeriFactu mode — check our documentation or get in touch.
]]>