E-invoicing, Explained from the Ground Up
What makes an invoice “electronic”, why governments are making it compulsory, the four models countries use, what is inside the file, and one invoice followed through four different countries to show what actually changes.
Concepts · October 2026 · For anyone new to e-invoicing
XML
the usual carrier: a structured file with a defined place for every piece of data
EN 16931
the European standard defining what an e-invoice must contain, revised in 2026
2030
structured e-invoices for cross-border B2B trade inside the EU
is not an e-invoice under the new rules: it is a picture of one
What an E-invoice Is, and Is Not
Data, not a document. An e-invoice is issued, sent and received in a structured format a computer can read without human help. The test is not whether it travelled by email, but whether the receiving system understands every field automatically, from the tax number to the last line item.
Printed and posted, then keyed in by the customer.
A digital picture of a paper invoice, usually emailed.
Data in an agreed format, exchanged system to system.
A PDF with the structured file embedded inside it.
An analogy
A PDF invoice is like a photograph of a spreadsheet: a person can read it, but to use the numbers someone has to type them in again. A structured e-invoice is the spreadsheet itself: the numbers arrive ready to be matched, posted and paid.
What changes when invoices become data
- No re-keying: the buyer's system reads the invoice directly, faster and with fewer errors.
- Automatic checks: missing tax numbers or wrong totals can be rejected before anyone looks at them.
- A copy for the state: once invoices are data, a tax authority can receive them, in real time if it wants.
Three common misconceptions
| What people think | What is actually true |
|---|---|
| “We already email PDFs, so we do e-invoicing” | Under the new mandates a PDF alone is not an e-invoice |
| “It only affects the invoices we send” | Most mandates also change how supplier invoices arrive |
| “Once it is live, it is done” | Formats and rules are updated every year, in every country |
E-invoicing is a VAT topic
The invoice is the document that gives a buyer the right to deduct VAT. That is why governments care about its format, and why every e-invoicing mandate is, underneath, a VAT control measure. The tax itself is covered in <a href='#vat-explained'>VAT, Explained from the Ground Up</a>.
Why It Is Spreading
For decades, tax authorities saw a company's VAT only as a total on a periodic return, months after the fact; fraud and error hid inside those totals. E-invoicing lets the authority see each transaction as it happens, which is why it has spread from Latin America to Europe, the Middle East and Asia in twenty years.
The pioneers
Chile, Mexico and Brazil pioneer mandatory electronic invoices.
The EU public sector
Public bodies must accept e-invoices.
Italy
Clears every B2B invoice centrally.
The wave
Mandates across Europe, the Gulf and beyond.
ViDA
EU cross-border digital reporting.
The problem it targets
- Missing trader: VAT charged, collected and never paid over.
- Fake invoices: deductions claimed on sales that never happened.
- Under-reporting: sales left out of the return.
What real-time data allows
- Matching the seller's output VAT to the buyer's deduction.
- Refusing invoices from unregistered or suspended sellers.
- Spotting anomalies within days instead of years.
Who gains, and how
| Party | What it gains |
|---|---|
| Tax authorities | Visibility of each transaction, faster fraud detection, a smaller VAT gap and, increasingly, pre-filled VAT returns |
| Buyers | No manual keying, faster approval, automatic matching to orders and receipts, earlier payment discounts |
| Sellers | Invoices delivered and confirmed instantly, fewer disputes, faster payment |
| Everyone | Less paper, fewer errors, and a single format instead of hundreds of layouts |
Swipe to see the whole table →
The European turning point
Until 2025, EU countries needed special permission from Brussels to make B2B e-invoicing compulsory, which is why only Italy had done it. The VAT in the Digital Age package, adopted in 2025, removed that need: since April 2025 any member state can mandate domestic e-invoicing, and from 1 July 2030 structured e-invoices and digital reporting become the rule for cross-border B2B trade inside the EU. Systems that predate 2024 must converge with the EU model by 2035.
Four questions to ask of any new mandate
- Who is in scope: which taxpayers, transactions and thresholds, and from what date?
- Which model and format: clearance, network or reporting, and which specification?
- How do we connect: directly, through a certified provider, or both?
- What must the buyer do: receive, accept, report or reject within a deadline?
The cost of doing nothing is changing
Voluntary e-invoicing was a business case about efficiency. Mandatory e-invoicing is different: an invoice in the wrong format is, legally, not an invoice, so the customer cannot deduct the VAT and may not pay until it is reissued.
The Four Models
Who sees the invoice, and when. Every country's regime is a variation on four models, which differ on one question: where does the tax authority sit, outside the exchange, in the middle of it, or beside it?
Invoices go directly from seller to buyer in a structured format; the authority sees them only in an audit or through periodic files.
The invoice goes to a government platform first, which validates it; only then is it a valid invoice, delivered to the buyer. A rejected invoice does not exist.
Seller and buyer each use an access-point provider; invoices travel over a shared network such as Peppol.
A network exchange, with invoice data also sent to the authority: the fifth corner.
Four-corner
- Corner 1: the seller
- Corner 2: the seller's access point
- Corner 3: the buyer's access point
- Corner 4: the buyer
Five-corner
The same four corners, plus corner 5: the tax authority, receiving the tax data of each exchange, usually from the access points.
How to tell which model a country uses
- Must the invoice get a number or approval from the state before the buyer sees it? Clearance.
- Must you use a certified provider on a shared network? Network; five-corner if data also goes to the state.
- Does it go straight to the buyer, with nothing sent to the state? Post-audit.
The trend is towards convergence
Clearance countries are adding networks, network countries are adding reporting, and the EU is standardising the content. The models are converging on “structured invoice, plus data to the state”, which is why a design built for one country increasingly transfers to the next.
Inside the File
An e-invoice has two layers: the semantic model (what information it contains) and the syntax (how it is written in a file). Europe standardised the first with EN 16931 and allows a few syntaxes for the second.
The format terms
| Term | What it means |
|---|---|
| EN 16931 | The European semantic standard: the core data every e-invoice must be able to carry |
| UBL | The most widely used XML syntax, used by Peppol and many national systems |
| CII | The UN/CEFACT syntax, used notably in Germany and France |
| CIUS | A national specialisation of the standard: extra rules or fields a country requires |
| Hybrid formats | A PDF with the XML embedded, such as ZUGFeRD or Factur-X |
| National formats | Country-specific XML, such as Italy's FatturaPA or Poland's FA(3) |
What the file carries
- Header: number, date, type, currency, references to order or contract.
- Parties: names, addresses, tax numbers, network identifiers.
- Lines: description, quantity, unit, price, discounts, classification codes.
- Tax: category, rate and amount per line and in total, exemption reasons.
- Totals and payment: amounts due, terms, bank details.
- Security: signatures, hashes, QR codes or authority identifiers, depending on the country.
What it looks like, heavily simplified
<Invoice>
<ID>INV-2026-0142</ID>
<IssueDate>2026-09-28</IssueDate>
<DocumentCurrencyCode>EUR</DocumentCurrencyCode>
<AccountingSupplierParty> … tax number, name, address … </AccountingSupplierParty>
<InvoiceLine>
<InvoicedQuantity unitCode="C62">1</InvoicedQuantity>
<LineExtensionAmount currencyID="EUR">1000.00</LineExtensionAmount>
</InvoiceLine>
<TaxTotal>
<TaxAmount currencyID="EUR">210.00</TaxAmount>
</TaxTotal>
</Invoice>Illustrative UBL-style fragment; a real invoice carries many more elements and namespaces.
The security layer varies by country
| Mechanism | Used, for example, in |
|---|---|
| Authority identifier after clearance | Poland (KSeF number), India (IRN), Mexico, Brazil |
| Digital signature by the seller | Chile, Türkiye, Saudi Arabia |
| Hash chain and counter | Saudi Arabia, Spain's Verifactu |
| QR code on the visual copy | Portugal, India, Poland (offline), Saudi Arabia |
Format is the easy part
Producing valid XML is a solved problem. Filling every mandatory field from real data (tax numbers, classification codes, units of measure, exemption reasons) is where projects spend their time, because that data lives in master records nobody has checked in years.
One Invoice, Four Countries
The same sale, four different journeys. Take the dining table from our VAT article, sold to a business customer for €1,000 plus VAT. The content is identical everywhere; what changes is the route, and the moment the invoice becomes legally valid.
The same invoice in four countries
| Germany | Belgium | Italy | UAE (from 2027) | |
|---|---|---|---|---|
| Model | Post-audit | Network | Clearance | Five-corner |
| Format | XRechnung or ZUGFeRD | Peppol BIS (UBL) | FatturaPA | PINT AE (UBL) |
| Route | Seller to buyer directly | Via two access points | Via the state platform | Via two providers, data to the authority |
| Valid when | Issued in the right format | Issued and delivered over the network | Accepted by the platform | Exchanged through accredited providers |
| Authority sees it | Only in an audit | From 2028, via reporting | Immediately | Immediately, as tax data |
| If it fails | Buyer may reject | Undeliverable; not an invoice | Rejected; resend in five days | Rejected by the provider |
Swipe to see the whole table →
Billing
The seller's system creates the invoice and converts it to the national format.
Submission
It is sent to the government platform, which checks the format and the content.
Validation
If accepted, the platform records it and returns an identifier or receipt; if not, it is rejected.
Delivery
The platform makes the invoice available to the buyer, whose system imports it.
Status
The buyer's acceptance, rejection and sometimes payment are recorded and returned.
The same invoice, step by step, in a clearance country.
The exceptions that take the time
| Situation | What usually has to happen |
|---|---|
| Invoice rejected | Correct the data at source and resend, often within a legal deadline |
| Price or quantity wrong | A credit note, itself an e-invoice, referencing the original |
| Platform unavailable | An offline or contingency procedure, then submission when it returns |
| Buyer not found | Check the identifier on the network; agree a fallback route |
What stays the same everywhere
The tax (€210 of VAT on a €1,000 table) does not change with the model. E-invoicing changes how the invoice travels and who sees it, not how much tax is due. The effort lies in the data, the connection and the handling of exceptions.
The Receiving Side, and E-reporting
Half of every mandate. Most projects start with sending, but every mandate also changes how invoices arrive, and in several countries the buyer has its own obligations and deadlines. The receiving side is where most unplanned work, and most second projects, come from.
Obligations on the receiving side
| Obligation | Example |
|---|---|
| Be able to receive at all | Belgium penalises the lack of means to receive; Germany requires all businesses to accept e-invoices |
| Accept or reject within a deadline | Chile's eight days; Serbia's platform window; Argentina's SME credit invoices |
| Report what you received | Croatia's recipient fiscalisation; Belgium's dual reporting from 2028 |
| Only deduct what was cleared | Romania's 15% penalty on invoices outside the system, for the buyer too |
| Report payment | Croatia monthly; Spain's B2B mandate when in force |
E-invoicing, e-reporting and SAF-T are different things
| E-invoicing | E-reporting | SAF-T | |
|---|---|---|---|
| What moves | The invoice itself | Data about transactions | An extract of the books |
| To whom | The customer (and maybe the state) | The state only | The state only |
| When | At issue | Near real time or periodic | Periodic or on request |
| Typical use | B2B and B2G sales | B2C, cross-border, payments | Audit and reconciliation |
| Example | Poland's KSeF | France's e-reporting | Romania's D406 |
Swipe to see the whole table →
A buyer's checklist
- Are we registered and findable on every platform or network our suppliers must use?
- Do received e-invoices land in AP as data, matched to orders and receipts, without re-keying?
- Who accepts or rejects, and does it happen inside the legal window?
- Do we deduct VAT only on valid e-invoices, and do we chase suppliers still sending PDFs?
Archiving: the part everyone forgets
- The structured file is the original; a printout or PDF is only a copy.
- Keep it unchanged, readable and retrievable for the legal period.
- Retention periods differ by country, commonly between five and ten years.
- Some platforms keep a copy, but rarely remove the obligation to keep your own.
Where it all leads: the pre-filled return
Once an authority holds every invoice, it can draft the VAT return itself, as Serbia, Romania, Italy, Portugal and Argentina are doing in different ways. The company's role shifts from preparing the return to reconciling with the authority's version of it, and every gap in the invoice data becomes a difference to explain.
The World, Country by Country
A snapshot as of September 2026, simplified. Positions change frequently: confirm them before deciding.
Status by country
| Country | Model | Status |
|---|---|---|
| Italy | Clearance | All B2B invoices through the SdI since 2019 |
| Poland | Clearance | KSeF mandatory since 2026; no fines before 1 January 2028 |
| Romania | Clearance | RO e-Factura for B2B since 2024 |
| Croatia | Exchange + fiscalisation | Mandatory since January 2026; payments reported |
| Serbia | State platform | SEF for B2B since 2023; pre-filled VAT from 2027 |
| Belgium | Network | Peppol mandatory since 2026; e-reporting from 2028 |
| France | Five-corner | Live from September 2026 through approved platforms |
| Germany | Post-audit | Receiving since 2025; issuing phased in 2027–28 |
| Spain | Platforms + public copy | B2B law in force; AEAT calendar from 1 October 2027, ministerial order pending |
| Portugal | Reporting | Certified software and monthly reporting; PDF signature from 2027 |
| Türkiye | Clearance | Long-established, through the revenue administration or integrators |
| Saudi Arabia | Clearance | Wave 25 completes the rollout by February 2027 |
| UAE | Five-corner | Largest taxpayers from January 2027 |
| India | Registration | IRN required above a turnover threshold; 30-day limit |
| Brazil | Clearance | Documents reshaped by the 2026–2033 tax reform |
| Chile, Argentina, Mexico | Clearance | Pioneers; mature, still evolving |
| United States | — | No mandate; voluntary network only |
Swipe to see the whole table →
France
Large and mid-size companies issue.
Germany and the UAE
Issuing for larger firms in Germany; UAE go-live.
France
All companies issue.
Germany and Belgium
All companies issue in Germany; e-reporting in Belgium.
EU
Cross-border reporting under ViDA.
Three patterns in the map
- Europe has flipped: from one mandate in 2019 to most large economies committed by the end of the decade.
- The receiving side comes first: Germany and France both required businesses to receive before they required them to send.
- Mature regimes keep changing: Italy, Chile and Argentina rewrote parts of their rules in 2025–26.
For a multinational, the question is sequencing
A group active in ten countries faces ten timelines, formats and providers. The winning approach is one design (a single framework, one cockpit, one data standard) rolled out country by country in the order the deadlines dictate, rather than ten separate projects.
E-invoicing Inside an SAP System
In SAP, e-invoicing is handled by SAP Document and Reporting Compliance. Its electronic-document framework sits between the billing or purchasing document and the outside world: it decides which documents become e-invoices, builds the file, sends it, and brings the answer back to the document where people work.
Where each concept lives
| Concept | Where it lives in SAP |
|---|---|
| Which invoices are in scope | Determination rules by country, company code, customer and document type |
| The file | Mappings that fill the country format from billing and master data |
| The connection | An integration layer, often SAP's cloud integration, to the platform, network or provider |
| Statuses | Returned to the electronic document and visible in a single cockpit |
| Exceptions | Rejections and errors handled in the same cockpit, with defined actions |
| Inbound | Received e-invoices imported, matched and posted on the purchasing side |
| Periodic files | The statutory reporting side of the same framework, for returns and SAF-T |
Platform notes
- The electronic-document framework exists on SAP S/4HANA and classic SAP ERP.
- Periodic statutory reporting requires S/4HANA or the cloud edition.
- Country content arrives through SAP notes and support packages.
- Always confirm availability for your exact release.
Scope
Countries, entities, document types, volumes and every system that bills.
Data
Tax numbers, units, codes and exemption reasons checked in master data.
Build
SAP notes, DRC configuration, mappings and the connection to the platform or provider.
Test
With the authority's test environment and real customers, including rejections.
Run
A named owner for the cockpit, a daily routine and a watch on legal change.
A typical project, in five steps.
Four questions that reveal a set-up's health
- How many invoices did we issue last month, and how many reached a final status?
- Who looks at rejections, and how quickly?
- How do supplier e-invoices reach AP: as data, or re-keyed?
- Which systems besides SAP issue invoices, and are they covered?
The most common pitfall
Treating go-live as the finish line. Most problems appear in the first month: invoices stuck in an intermediate status, rejections nobody sees, and suppliers still sending PDFs. Plan the run model before the build.
The Words You Will Hear Most
Glossary
| Term | Meaning |
|---|---|
| Access point | A certified provider that connects a business to a network such as Peppol |
| Clearance | Validation by the tax authority before an invoice is valid |
| CIUS | A country's specialisation of the European standard |
| CTC | Continuous transaction controls: the family of real-time models |
| E-reporting | Sending transaction data to the state, without exchanging the invoice |
| EN 16931 | The European standard for e-invoice content |
| Peppol | An international network and set of specifications for e-document exchange |
| Rejection | An invoice refused by a platform or a buyer: often, legally, not issued |
| Status | The lifecycle stage of an e-invoice: sent, delivered, accepted, rejected, paid |
| UBL / CII | The two main XML syntaxes for e-invoices |
| ViDA | “VAT in the Digital Age”: the EU reform bringing digital reporting from 2030 |
Five things to remember
- An e-invoice is data, not a PDF.
- The model decides where the authority sits: outside, in the middle, or beside the exchange.
- The format is easy; the data is hard.
- Receiving is half of every mandate.
- The destination is the same everywhere: every invoice visible to the state, and returns built from that data.
How 30 Advisory Helps
We take each country's e-invoicing from assessment to day-to-day operation in SAP.
Readiness
Scope, data and connection assessed country by country.
Implementation
SAP DRC configured for sending, receiving and exceptions.
Run
Statuses monitored and legal change applied as it arrives.
Sources consulted on 28 September 2026: vatcalc and the European Commission on ViDA and the revised EN 16931; 30 Advisory country briefings (September 2026) and the sources cited in them. Updated on 1 October 2026 with the latest Poland and Spain dates from our tracker. All examples are illustrative.
Prepared by 30 Advisory. Educational material only; not tax, legal or accounting advice. Country positions are simplified and change frequently. Confirm the treatment of any real case with a qualified adviser.