What is e-invoicing? The five compliance models explained

Sending a PDF invoice by email is not e-invoicing. Generating a PDF from your accounting software and attaching it to a message is not e-invoicing. Scanning a paper invoice and emailing the scan is definitely not e-invoicing.

This surprises many finance teams, because they've been doing these things for years and calling it "electronic invoicing." In common usage the term is loose. In a regulatory context, it means something very specific.

E-invoicing is the structured, machine-readable exchange of invoice data in a standardised format — transmitted through a specific channel, with tax authority validation or notification as part of the workflow. The invoice data can be processed automatically by the recipient's system without manual re-entry, and the tax authority has visibility into the transaction in real time or near-real time.

The key words are structured (machine-readable XML, not a rendered document) and validated by the tax authority. In most e-invoicing mandates, a PDF is not legally valid even if it's generated perfectly — the invoice must pass through the required channel in the required format.


Why governments are mandating it

The EU VAT gap — the difference between what tax authorities expect to collect in VAT and what they actually receive — was estimated at €89 billion in 2022. A significant portion comes from invoice fraud, phantom companies, carousel fraud schemes, and simple under-reporting.

E-invoicing closes this gap by giving tax authorities real-time visibility into B2B transactions. When the authority sees every invoice as it's issued — before payment, before the VAT return is filed — cross-referencing and audit become automated. Italy made it mandatory for all B2B transactions in 2019 and has seen measurable VAT gap reduction since.

Now every major European economy is following. Poland's KSeF mandate applies from February 2026. France begins phased rollout in September 2026. Germany's B2B receiving obligation is live from January 2025. Belgium, Romania, and Greece all have active mandates at various stages. This is not a trend — it's a permanent change to how tax compliance works.


The five compliance models

Not all countries implement e-invoicing the same way. The approach a country takes determines what your compliance obligation actually looks like. Understanding the model is the first step to understanding what's required.


1. Clearance Model

Countries: Italy, Spain, Romania (upcoming), Saudi Arabia

In the clearance model, you cannot legally deliver an invoice to your buyer until the tax authority has validated and approved it.

The workflow: Supplier generates invoice → sends to tax authority portal → authority validates and returns signed clearance → only then can invoice be delivered to buyer.

Italy's SDI (Sistema di Interscambio) is the most established example. Every Italian B2B invoice must pass through SDI in FatturaPA XML format. SDI returns a signed receipt (Ricevuta di Consegna) — that receipt is the invoice's proof of legal validity. An invoice that has not passed through SDI has no legal standing.

Spain's VeriFactu system, introduced in 2024, works similarly: all invoice data is transmitted to the AEAT at the point of issue. Saudi Arabia's ZATCA Phase 2 clearance follows the same pattern.

Implication: You cannot issue an invoice and figure out compliance later. The compliance step is part of the issuance workflow — your invoicing system must be integrated with the tax authority's system before you can invoice at all in these countries.

In Eastern Europe, this real-time invoice registration requirement is often called fiscalization — Romania, Hungary, and Croatia all operate fiscalization mandates, where billing software must register each invoice with the national authority at the point of issuance.


2. Central Repository Model

Countries: Poland (KSeF), India (IRP)

Poland's KSeF (Krajowy System e-Faktur) is the most complete implementation of this model in Europe. Every B2B invoice from February 2026 must be submitted to KSeF, which assigns a unique KSeF number — the legal identifier for that invoice. Buyers do not receive the invoice directly from the supplier; they retrieve it from KSeF using the KSeF number.

The workflow: Supplier submits invoice to KSeF → KSeF assigns number and stores invoice → Buyer retrieves from KSeF → KSeF number required on all payments and correspondence.

This creates a government-held record of every B2B transaction in the country. The KSeF number must appear on payment remittances and is how the tax authority cross-references payments against invoices during VAT return review.

Implication: The KSeF number becomes a required field in your ERP or accounting system. Missing KSeF numbers will block VAT reconciliation and may trigger audits.


3. Peppol Network

Countries: Belgium, Norway, Denmark, Finland, Sweden, Netherlands, Singapore, Australia

Peppol (Pan-European Public Procurement Online) is an open, standards-based network for exchanging business documents. Unlike a government portal, Peppol is a decentralised network of accredited Access Points — registered service providers that route documents between participants. Think of it like email, but for structured business documents with guaranteed delivery and format validation.

The workflow: Supplier (via their Access Point) → Peppol network (routes via SML/SMP lookup) → Buyer's Access Point → Buyer's ERP.

Buyers register their Peppol ID — a combination of a scheme identifier and their business identifier (often their VAT number or company registration). When a supplier sends an invoice, their Access Point looks up the buyer's registered endpoint in the Peppol SML directory and routes the document there automatically.

The document format is UBL 2.1 (Universal Business Language), standardised as BIS Billing 3.0 within Europe. Belgium mandates Peppol for all B2B e-invoicing from 2026.

Implication: To send Peppol invoices, you need an accredited Access Point. Clearvo is a testbed-certified Peppol Access Point — you send us structured invoice data, we route it to the buyer's registered endpoint.


4. Post-Audit / Direct Exchange

Countries: Germany, Netherlands B2B

In the post-audit model, invoices are exchanged directly between supplier and buyer in a structured format. The tax authority doesn't intercept the invoice in real time — instead, it receives transaction data separately, either periodically or via a mandatory reporting mechanism.

Germany's B2B e-invoicing mandate (from 2025) requires all businesses to be able to receive structured e-invoices in EN 16931-compliant formats — XRechnung or ZUGFeRD. For public sector invoicing, XRechnung has been mandatory since 2020.

Implication: The invoice exchange itself may be straightforward, but a parallel reporting obligation adds a separate compliance step. Missing the reporting element while getting the format right still leaves you non-compliant.


5. Hybrid / Reporting Models

Countries: Portugal (ATCUD), Greece (myDATA), Spain (SII)

These models require invoices to carry a unique identifier issued or validated by the tax authority, and transaction data must be reported in real time or near-real time.

Portugal (ATCUD): Each invoice must carry an ATCUD code — a unique sequential code generated from an AT series registered with the tax authority. The ATCUD proves the invoice is part of an authorised sequence and enables the AT to verify completeness of a company's invoice series.

Greece (myDATA): Businesses must report all invoice data to the AADE myDATA platform within specific timeframes. myDATA returns a MARK identifier that must appear on the invoice. The MARK is used for reconciliation against VAT returns.

Greece's myDATA (My Digital Accounting and Tax Application) is the most established hybrid model in the EU — businesses must report invoice summaries to AADE within 24 hours of issue. The MARK identifier returned by AADE must appear on the invoice.

Spain (SII): All larger businesses must report invoice data to the AEAT within 4 business days of issue. VeriFactu, the newer system, extends real-time reporting to a broader set of businesses.

Implication: Invoice generation is two-step. You generate the invoice, send it to the authority's system to get the identifier, then include that identifier on the invoice you send to your buyer. Any invoice without the required identifier is potentially invalid.


A practical comparison

Model Invoice goes to authority When Blocks delivery? Key countries
Clearance Yes — before buyer At issuance Yes Italy, Spain, Romania, Saudi Arabia
Central Repository Yes — to national platform At issuance Effectively yes Poland, India
Peppol Network No — peer to peer At delivery No, but registration required Belgium, Norway, Denmark, Singapore
Post-audit / Direct Via separate report Periodically No, but reporting mandatory Germany, Netherlands
Hybrid / Reporting Yes — for identifier At issuance Partially Portugal, Greece, Spain

What this means for businesses selling across borders

If you sell to business customers in more than one of these countries, you may be subject to multiple compliance models simultaneously. An Italian SaaS company invoicing German, Polish, and Belgian customers needs to:

Each has a different format, a different technical channel, and a different response identifier to capture and store. Managing them as separate integrations is technically possible but operationally expensive. The practical alternative is a platform that handles all of them from a single integration, normalising the differences and returning a consistent status and audit trail regardless of which country's system processed the invoice.


The EN 16931 standard

While formats differ by country, most European e-invoicing systems are based on — or compatible with — EN 16931, the European standard for electronic invoicing. EN 16931 defines a common semantic data model: the meaning of invoice fields, how tax is calculated, what a credit note looks like. Country-specific formats (XRechnung, UBL BIS 3.0, FatturaPA) are implementations or extensions of this standard.

This matters in practice: the underlying invoice data you need to collect is largely consistent across countries. The differences are in how that data is packaged and where it goes, not in what data you need to hold.


Where things are heading

The ViDA (VAT in the Digital Age) directive, adopted by the European Council in 2024, mandates digital reporting for all intra-EU B2B transactions by 2030. By that date, any business selling to another EU business will be required to report transaction data to an EU-wide system. The country-specific mandates being implemented now are the stepping stones to a single EU-wide digital transaction reporting layer.

Investing in e-invoicing compliance now is not just about meeting today's mandates — it's building the infrastructure that will be required for every EU B2B transaction within the next five years.


Clearvo handles all five compliance models across 31 countries from a single integration. You send structured invoice data once — Clearvo generates the required XML format, submits it to the right authority or Peppol endpoint, and returns the clearance status and identifier.

Ready to handle e-invoicing in 31 countries?

One API, all 31 countries. Sign up and get your API key within 24 hours.

Get started free →