Compliance · Electronic Invoicing

E-Invoicing Fundamentals

Why structured electronic invoicing is becoming the global default - and how the underlying networks, models and standards actually work.

In this guide

  1. What is electronic invoicing?
  2. Why is it being mandated globally?
  3. How it works (basic flow)
  4. Network models (4-corner, 5-corner, Y-model, post-audit)
  5. The major networks (Peppol, DBN Alliance, EU DRR)
  6. Standards & formats (EN 16931, UBL, Factur-X)
  7. What this means for ERP / NetSuite teams
01

What is electronic invoicing?

An electronic invoice (e-invoice) is an invoice issued, transmitted and received in a structured digital format that can be processed automatically by both parties' software. A PDF attached to an email is not an e-invoice - it's an electronic copy of a paper invoice. A true e-invoice carries machine-readable data (typically XML, UBL or JSON) that can be validated, reconciled and posted without manual data entry.

Not an e-invoice

  • PDF or scanned image emailed
  • Word document attachment
  • Paper invoice posted
  • Free-text email body

True e-invoice

  • Structured XML (UBL, CII, FatturaPA)
  • JSON via API (e.g. India IRP)
  • EDIFACT or X12 EDI
  • Hybrid PDF/A-3 with embedded XML (Factur-X)
02

Why is it being mandated globally?

Tax authorities worldwide are moving from paper-era audit cycles to continuous, structured oversight of every transaction. The drivers are remarkably consistent:

Closing the VAT gap

The EU VAT gap was estimated at €89bn in 2022. Real-time visibility into invoice flows reduces missing-trader fraud and undeclared revenue.

Faster audits, fewer errors

Structured data eliminates re-keying, lets tax authorities pre-fill VAT returns and dramatically shortens audit cycles.

Process automation

For businesses, e-invoicing unlocks straight-through processing: AP automation, automated reconciliation, faster payment cycles.

Cross-border interoperability

EN 16931 and Peppol create a common semantic layer so an e-invoice issued in Belgium can be understood by a buyer in Australia.

Sustainability

Eliminating paper invoices removes printing, postage and physical archiving from the procure-to-pay chain.

EU ViDA & OECD push

VAT in the Digital Age package and OECD's Tax Administration 3.0 framework formalise digital reporting as the new global baseline.

03

How it works (basic flow)

Every e-invoicing implementation, regardless of country, follows a similar choreography. The supplier produces a structured invoice, transmits it through one or more network nodes, and the buyer's system processes it - while the tax authority either validates, archives or audits the exchange.

1

Generation

Supplier's ERP / billing software creates a structured invoice (UBL, FatturaPA, CFDI, etc.).

2

Validation

Optional digital signature, schema validation, business-rules check (e.g. VAT calculations).

3

Transmission

Sent via Access Point, central portal, certified intermediary or direct API.

4

Clearance / reporting

Tax authority validates and registers the invoice (clearance) or receives reporting data (post-audit).

5

Delivery

Buyer's system retrieves the invoice, sends acknowledgment / lifecycle status, posts to AP.

6

Archiving

Both parties archive electronically (5-11 years depending on jurisdiction) with audit trail.

04

Network models

Different jurisdictions choose different topologies depending on their tax-control philosophy. Below are the four most common models, each visualised with a simple diagram.

Model A

2-corner / Post-audit (bilateral)

Supplier and buyer exchange invoices directly (email, EDI, point-to-point API). The tax authority does not intervene at issuance time but reserves the right to audit later. Historically the default in most countries.

Supplier (issues invoice) Buyer (receives invoice) PDF / EDI / direct exchange Tax Authority (audits later, on request)
Used by: Germany (B2B until 2025), United Kingdom, United States (federal), most pre-mandate jurisdictions.
Pros: Simple, low infrastructure cost. Cons: VAT-fraud risk, slow audit cycles.
Model B

3-corner (centralised platform)

Both supplier and buyer connect to the same central platform operated by a tax authority or government body. Common for B2G mandates.

Supplier Central Platform (e.g. Chorus Pro, FACe) Buyer submit deliver
Used by: France Chorus Pro (B2G), Spain FACe (B2G), early stages of many B2G implementations.
Pros: Centralised governance. Cons: Doesn't scale to B2B without intermediaries.
Model C

4-corner (Peppol interoperability)

Each party connects to its own Access Point (AP) - a certified service provider. Access Points exchange invoices over a common Peppol network using SMP (Service Metadata Publishing) and BIS Billing 3.0 specifications. No central authority sits in the transmission path.

Supplier Corner 1 Access Point (supplier's) Corner 2 Access Point (buyer's) Corner 3 Buyer Corner 4 Peppol network (SMP / AS4) Sender Receiver
Used by: Belgium (2026), Netherlands, Norway, Sweden, Finland, Singapore (foundation), Australia, New Zealand, Japan (PINT).
Pros: Open, interoperable, vendor-neutral. Cons: No tax-authority visibility unless extended (see 5-corner).
Model D

5-corner (Peppol DCTCE / CTC)

Extends the 4-corner Peppol model with a 5th corner: the tax authority. Every invoice flowing between APs is also reported in near real-time to the relevant tax authority. Known as Decentralized CTC and Exchange (DCTCE). France's 2026 mandate and UAE's roadmap follow this design.

Supplier Corner 1 Access Point Corner 2 Access Point Corner 3 Buyer Corner 4 Tax Authority Corner 5 (DCTCE) real-time reporting
Used by: France (2026 PPF/PDP model), United Arab Emirates (2026), Singapore InvoiceNow, planned for several jurisdictions.
Pros: Tax visibility + interoperability. Cons: Higher integration complexity for service providers.
Model E

Y-model (centralised clearance)

All invoices must transit through a single central platform operated by the tax authority. The platform validates, signs and forwards the invoice to the buyer (or makes it available for download). The supplier cannot deliver an invoice that has not been cleared.

Supplier Tax Authority Clearance Hub (SDI, KSeF, FATOORA, IRP) Buyer issue forward Every invoice is validated, signed, registered & forwarded by the central hub.
Used by: Italy (SDI), Poland (KSeF), Romania (RO e-Factura), Saudi Arabia Phase 2 (FATOORA), Mexico (CFDI via PAC), most LATAM countries, India (GST IRP).
Pros: Maximum tax control, full visibility. Cons: Single point of failure, lock-in to national platform.
05

The major networks

A handful of cross-border networks are emerging as de-facto interoperability layers. Knowing their scope and governance is essential when designing a multi-country compliance strategy.

OpenPeppol

Global / EU-rooted

Pan-European Public Procurement Online - originally an EU large-scale pilot, now a global non-profit AISBL operating the Peppol network. Defines BIS Billing 3.0 (based on EN 16931), the SMP/SML registry mechanism, the AS4 transport profile and a network of certified Access Points.

Each country has a Peppol Authority that supervises local APs (e.g. ATO in Australia, IMDA in Singapore, Logius in Netherlands, Agenzia delle Entrate in Italy).

Country profiles (PINT): PINT-AU, PINT-NZ, PINT-SG, PINT-JP, PINT-MY, PINT-AE, PINT-TH - localised extensions of the base specification.

DBN Alliance

North America

Digital Business Networks Alliance - a US not-for-profit launched in 2022 that operates the DBN Exchange Framework, a Peppol-aligned 4-corner network for the US market. Members include service providers, payment networks and accounting platforms.

The framework reuses Peppol BIS semantics but adopts a separate registry (DBN SMP) and governance model adapted to the absence of a federal e-invoicing mandate.

EU ViDA - DRR

European Union

VAT in the Digital Age - Digital Reporting Requirements. The 2030+ EU framework makes structured e-invoices mandatory for intra-EU B2B and introduces near real-time digital reporting to replace recapitulative statements. Member States must align national systems by 2035.

National platforms

Country-specific

Each clearance jurisdiction operates its own centralised hub: SDI (Italy), KSeF (Poland), RO e-Factura / SPV (Romania), FATOORA (Saudi Arabia), SAT/PAC (Mexico), NF-e SEFAZ (Brazil), IRP (India), MyInvois (Malaysia) and many others. They do not interoperate with each other directly - cross-border still requires Peppol or bilateral agreements.

06

Standards & formats

Different jurisdictions accept different formats, but most are converging on a small set of semantic standards.

EN 16931

European semantic standard for the core invoice. Defines the data model that must be supported. Realised through two syntaxes: UBL 2.1 and UN/CEFACT CII.

UBL 2.1

Universal Business Language - XML format used by Peppol BIS Billing 3.0, FACe (Spain), eRacun (Croatia), most Peppol jurisdictions and many LATAM systems.

UN/CEFACT CII

Cross Industry Invoice - alternative XML syntax for EN 16931. Used as one of the accepted formats in France's PPF/PDP framework and in Factur-X.

Factur-X / ZUGFeRD

Hybrid PDF/A-3 with embedded XML (CII). Human-readable PDF + machine-readable XML in a single file. Common in France and Germany.

FatturaPA

Italy's national XML schema, predates EN 16931 but maps to it. Mandatory for any invoice processed by SDI.

CFDI 4.0 / NF-e / DTE

National XML schemas for Mexico, Brazil and Chile. Predate EN 16931 and reflect distinct LATAM clearance practices, with rich complementos (payments, payroll, foreign trade).

JSON / API-based

India's GST e-Invoice (Schema INV-01), Singapore InvoiceNow (Peppol AS4 + JSON reporting), Israel's Allocation Number system - increasingly common in API-first jurisdictions.

07

What this means for ERP / NetSuite teams

From the perspective of a Solution Architect rolling out NetSuite (or any tier-1 ERP) in a multi-country footprint, e-invoicing has three operational consequences:

  1. Localization is no longer optional. Each new jurisdiction means a new connector, a new format mapping, a new authority to integrate with. Vendor SuiteApps (Avalara, Sovos, Storecove, Pagero, Edicom, Comarch, Celigo) cover most cases but the architecture must remain modular.
  2. Master data discipline becomes critical. Tax registration numbers, Peppol IDs, product classifications (HS codes), customer-supplier identifiers - all must be clean in NetSuite to produce a valid e-invoice. Bad master data fails clearance, halts cashflow.
  3. Integration patterns evolve. Real-time API calls (clearance) are now part of the order-to-cash path, not nightly batches. Error handling, retry logic, lifecycle status acknowledgments need to be designed in. SuiteScript 2.1 + Map/Reduce + RESTlets become standard tooling.

When designing a NetSuite footprint that crosses borders, treat e-invoicing compliance as a first-class architectural concern, not a post go-live afterthought.

Continue exploring

Browse the country-by-country atlas or the year-by-year timeline to dive deeper.

Browse the country atlas View the roadmap