Per-country e-invoicing models, formats, transport methods, and compliance rules.
Last updated: 2026-03-02
| Country |
Model |
Format |
Government System |
Network |
Deadline |
Phase |
Sites |
| Malaysia |
Clearance (Single) |
MyInvois JSON/XML |
MyInvois / LHDN |
Direct API |
Phased (Jan 2027 for Chart MY) |
1a |
1 |
| France |
Exchange + Reporting |
Factur-X (CII/UBL) |
Chorus Pro |
PA (Approved Platform) + PPF |
Sep 2026 |
1b |
4 |
| Germany |
Private Exchange |
XRechnung (CII/UBL) |
-- |
Peppol |
Jan 2027 |
1c |
5 |
| Belgium |
Private Exchange |
Peppol BIS 3.0 |
-- |
Peppol |
Jan 2026 |
1c |
1 |
| Denmark |
Private Exchange |
Peppol BIS 3.0 |
-- |
Peppol / NemHandel |
Jul 2026 (capability required) |
1c |
2 |
| Attribute |
Value |
| Model |
Clearance (Single) |
| Government System |
MyInvois (LHDN -- Lembaga Hasil Dalam Negeri) |
| Government Role |
Pre-approval required before customer delivery |
| Deadline |
Phased: Aug 2024 (>RM100M), Jan 2025 (>RM25M), Jul 2025 (>RM5M), Jan 2027 (RM1M-5M). Below RM1M: EXEMPT |
| Complexity |
HIGH -- requires ID+QR callback, two-push model |
¶ Mandate Timeline (Phased by Revenue)
| Phase |
Date |
Threshold |
Grace |
| Phase 1 |
Aug 2024 |
Turnover >RM100M |
6 months |
| Phase 2 |
Jan 2025 |
Turnover >RM25M |
6 months |
| Phase 3 |
Jul 2025 |
Turnover >RM5M |
6 months |
| Phase 4 |
Jan 2027 |
Turnover RM1M–RM5M (delayed from Jul 2026) |
12-month transition |
| Phase 5 |
CANCELLED |
Below RM1M: EXEMPT |
— |
| Provision |
Detail |
| Statute |
Section 120(1)(d) Income Tax Act 1967 |
| Fine |
RM200 – RM20,000 per offence |
| Imprisonment |
Up to 6 months |
| Combined |
Fine AND imprisonment possible |
| Scope |
Per instance — multiple violations = multiple penalties |
| Attribute |
Value |
| AR Format (to government) |
MyInvois JSON/XML (EDICOM transforms from UCF) |
| AR Format (to customer) |
MyInvois JSON/XML + embedded PDF (with Gov ID + QR) |
| Transport (government) |
EDICOM REST API -> MyInvois API |
| Transport (customer) |
EDICOM -> customer (after clearance) |
| Callback |
EDICOM webhook -> Middleware (Gov ID + QR code) |
| API Rate Limit |
100 RPM (MyInvois submit) |
| Callback Signing |
HMAC-SHA256 |
| Customer Delivery |
User-defined — Chart obligated to send directly to customer |
| AP Format (inbound) |
Intercompany only — direct UCF (no EDICOM inbound). Self-bill type 11 |
| AP Transport |
Interco source → Middleware → SFTP → COR360 → JDE. Self-bill then submitted to EDICOM for clearance only |
PHASE 1 -- Clearance (ERP push #1):
ERP pushes UCF JSON (no PDF) -> Middleware -> EDICOM -> MyInvois
Government validates -> returns ID + QR code (near real-time)
EDICOM callback -> Middleware -> writes ID+QR back to ERP
ERP regenerates PDF with embedded ID + QR
InvoiceRegister Record 1: RecordType=CLEARANCE, terminal state = CLEARED
PHASE 2 -- Delivery (ERP push #2):
ERP pushes UCF JSON + PDF (with ID+QR) -> Middleware -> EDICOM -> Customer
Standard delivery pipeline (identical to DE/FR/BE)
InvoiceRegister Record 2: RecordType=DELIVERY, linked to Record 1
- All Malaysia AP is intercompany — invoices come from other Chart entities, NOT external suppliers
- Self-billing: Chart MY (buyer) issues the e-invoice, not the seller — type code 11
- EDICOM role is clearance ONLY — not for receiving the original AP invoice
- Foreign supplier TIN for self-billing:
EI00000000030
- Self-billed e-invoice must be issued by end of month following receipt of invoice
- Customers on COR: Companies 111, 223, 226, 7326
- Only a CLEARANCE record is created (no DELIVERY record)
| Site Code |
ERP |
AR |
AP |
AP Tool |
| Chart MY |
JDE |
Yes |
Yes |
COR360 |
| # |
Requirement |
Status |
| 1 |
Register with MyInvois |
NOT STARTED |
| 2 |
Tax ID validation |
NOT STARTED |
| 3 |
Invoice format mapping (EDICOM) |
NOT STARTED |
| 4 |
Clearance callback handling |
NOT STARTED |
| 5 |
PDF regeneration with ID+QR (JDE) |
NOT STARTED |
| 6 |
Rejection handling process (business) |
NOT STARTED |
| 7 |
End-to-end testing |
NOT STARTED |
| 8 |
Activity Description field in JDE (BUSACT text attachment, max 35 chars) — needed for AR and self-billing AP (interco) |
NOT STARTED |
| 9 |
Business Classification / MSIC code in JDE (SIC code field — conflicts with company code usage, needs resolution) |
NOT STARTED |
| Issue |
Impact |
Status |
| Rejection handling process undefined |
High |
OPEN |
| JDE SIC code conflict: currently used for company code, needed for MSIC classification (Tino, 3 Mar 2026) |
Medium |
OPEN |
| Attribute |
Value |
| Model |
Private Exchange |
| Government System |
None -- B2B direct |
| Government Role |
None |
| Deadline |
Jan 2025 (receive), Jan 2027 (send >€800K), Jan 2028 (send ALL) |
| Complexity |
LOW |
¶ Mandate Timeline
| Date |
Requirement |
Notes |
| Jan 2025 |
All businesses must ACCEPT e-invoices (receive) |
Already active |
| Jan 2027 |
Companies >€800K turnover must SEND e-invoices |
Growth Opportunities Act (Wachstumschancengesetz) |
| Jan 2028 |
ALL businesses must send e-invoices |
No exemptions |
Transition period (2025–2027): Paper invoices still valid. EDI formats accepted if EN 16931 extractable. ZUGFeRD (hybrid PDF+XML) accepted alongside XRechnung.
| Penalty |
Detail |
| Administrative fine |
Up to €5,000 per offence |
| VAT impact |
Input VAT deduction denied if buyer does not receive compliant e-invoice |
| Criminal |
None (enforcement via existing invoice rules) |
- Domestic = Non-Domestic: same Peppol path, no distinction
- No government portal involvement
- EN 16931 compliance required for all formats
- Growth Opportunities Act (Wachstumschancengesetz) is the enabling legislation
| Attribute |
Value |
| AR Format |
XRechnung (CII or UBL 2.1) or ZUGFeRD 2.x (PDF/A-3 + embedded XML) — EN 16931 compliant. EDICOM transforms from UCF |
| Transport |
Peppol network via EDICOM as Access Point |
| Network |
Peppol eDelivery (AS4) |
| Peppol ID |
0088:{GLN} or 9930:{VAT-ID} per recipient |
| AP Format (inbound) |
UCF JSON via EDICOM |
| AP Transport (JDE sites) |
EDICOM -> Middleware -> SFTP -> COR360 -> JDE |
| AP Transport (SAP sites) |
EDICOM -> Middleware -> SFTP -> OpenText -> SAP |
Germany requires format routing based on customer capability:
| Customer Capability |
Format |
Route |
| Peppol registered |
XRechnung (UBL) |
Peppol network |
| Peppol NOT registered |
ZUGFeRD (CII) + PDF |
Email / portal |
Format determination is handled by the FormatRouter component in the middleware.
mandated_network = NO → intercompany invoices delivered directly by middleware (no EDICOM)- No government submission required
- Format mandated (XRechnung / EN 16931) but network NOT mandated — Peppol is available, not required
- Caveat: if LTA (Long-Term Archiving) turns out to be mandatory for Germany (ACT-062 pending), intercompany would need to go through EDICOM for certified archival
| Site Code |
ERP |
AR |
AP |
AP Tool |
| GOFA |
JDE |
Yes |
Yes |
COR360 |
| FLOW |
JDE |
Yes |
Yes |
ERP Direct |
| VCT |
JDE |
Yes |
Yes |
ERP Direct |
| HDE |
SAP S/4H |
Yes |
Yes |
OpenText |
| HTO |
SAP S/4H |
Yes |
Yes |
OpenText |
| # |
Requirement |
Status |
| 1 |
XRechnung format mapping (EDICOM) |
NOT STARTED |
| 2 |
Peppol network registration (EDICOM) |
NOT STARTED |
| 3 |
FormatRouter logic (XRechnung vs ZUGFeRD) |
NOT STARTED |
| 4 |
JDE integration testing |
NOT STARTED |
| 5 |
SAP integration testing |
NOT STARTED |
| Issue |
Impact |
Status |
| SAP AP tool "X1" is undocumented |
Medium |
OPEN |
| Attribute |
Value |
| Model |
Exchange + Reporting |
| Government System |
PPF (Portail Public de Facturation) / Chorus Pro |
| Government Role |
Receives a copy of every invoice (real-time reporting) |
| Deadline |
Sep 2026 (large/ETI send, ALL receive). Sep 2027 (SME/micro send) |
| Complexity |
HIGH — most complex country (4 ERPs, 3 AP tools, dual paths) |
¶ Mandate Timeline
| Date |
Requirement |
| Sep 2026 |
Large & ETI must SEND e-invoices. ALL sizes must RECEIVE. |
| Sep 2027 |
SMEs & micro-enterprises must SEND. Non-established VAT-registered entities. |
| Type |
Amount |
| Failure to issue e-invoice |
€50 per invoice (cap €15,000/year) |
| e-Reporting failure |
€500 per transmission (cap €15,000/year) |
| Grace period |
None (proposed 2026–2028 tolerance was rejected) |
| First-offence waiver |
Waived if remedied within 30 days of notice ('droit à l'erreur') |
| Scenario |
e-Invoice Required? |
e-Reporting Required? |
Format |
| French → French (domestic B2B) |
YES (via PA) |
YES (automatic via PA) |
Factur-X / UBL / CII |
| French → International |
NO |
YES (transaction data to PPF) |
Any agreed format |
| International → French (domestic AP) |
YES (via supplier's PA) |
YES (automatic) |
Factur-X |
| International → French (non-domestic AP) |
NO |
YES (Chart must report to PPF) |
Any format (email/PDF) |
- PA (Approved Platform) replaces PDP terminology
- PPF role: directory + data hub (NOT invoice exchange)
- SIRET validation required for French entities
- Most complex country: 4 ERPs, 3 AP tools, domestic vs non-domestic paths differ significantly
- EDI customers exist (both domestic and international)
| Attribute |
Value |
| AR Format |
Factur-X (PDF/A-3 with embedded CII XML) — EN 16931 compliant. EDICOM transforms from UCF |
| Transport (customer) |
EDICOM -> customer (direct or via Peppol) |
| Transport (government) |
EDICOM -> Chorus Pro (reporting copy, simultaneous) |
| Network |
PA (Plateforme Agreee — Approved Platform). PPF = directory + data hub only, NOT invoice exchange |
| AP Format (inbound) |
UCF JSON via EDICOM |
| AP Transport (AX sites) |
EDICOM → Middleware → Email (PDF+UCF) → Basware → AX |
| AP Transport (IFS site) |
EDICOM -> Middleware -> ERP Direct |
| AP Transport (Epicor site) |
EDICOM -> Middleware -> ERP Direct |
mandated_network = YES (PA platform) → intercompany invoices go through EDICOM (via PA network)- French domestic intercompany: e-invoice via PA is legally required — same as external customer
- Government e-Reporting copy to PPF is mandatory for all domestic invoices (including intercompany)
- International intercompany (FR → non-FR): e-Reporting to PPF is still required (transaction data)
- International inbound (non-FR → FR): e-Reporting IS mandatory — Chart must report to PPF
Source: Tino Di Natali, 3 Mar 2026 (Teams note). Ref: Article 290, I French General Tax Code.
French overseas territories have different e-invoicing obligations. The middleware must route these correctly:
| Territory |
VAT applies? |
E-invoicing required? |
E-reporting required? |
Notes |
| Mainland France |
Yes |
Yes |
Yes (automatic via PA) |
Standard domestic rules |
| Guadeloupe, Martinique, Réunion (DOM) |
Yes |
Yes (services only) |
Yes (VAT-exempt goods) |
Services = e-invoicing; goods deliveries = e-reporting only |
| French Guiana, Mayotte |
No |
No |
Yes |
VAT not applicable — all transactions are e-reporting |
| COM (New Caledonia, French Polynesia, etc.) |
No |
No |
Yes (for the mainland FR party) |
Operators there are not taxable persons. Mainland FR party must report to PPF |
Key rules:
- Services between mainland France and Guadeloupe/Martinique/Réunion (either direction) → e-invoicing required
- VAT-exempt goods between mainland France and Guadeloupe/Martinique/Réunion (either direction) → e-reporting only (not e-invoicing)
- All transactions with French Guiana or Mayotte → e-reporting only (no VAT there)
- COM territories → e-invoicing not mandatory, but the mainland France party must submit transaction data to PPF via e-reporting
Impact on middleware: The supplier lookup is unaffected — DOM-TOM suppliers use standard French identifiers (FR-prefixed VAT, SIRET). The routing logic in the middleware must classify transactions as e-invoicing or e-reporting based on the buyer/seller territories and transaction type. This classification is determined after supplier lookup, during AR/AP routing.
| Site Code |
ERP |
AR |
AP |
AP Tool |
AP OCR |
| HSV |
AX |
Yes |
Yes |
Basware |
SmartPDF (SSC manual) |
| HBC |
AX |
Yes |
Yes |
Basware |
SmartPDF (SSC manual) |
| HMP FR |
IFS → JDE |
Yes |
Yes |
COR360 |
ABBYY |
| CPI FR |
Epicor |
Yes |
Yes |
Ancora → DocStar |
Ancora |
| # |
Requirement |
Status |
| 1 |
Register with Chorus Pro |
NOT STARTED |
| 2 |
Factur-X format mapping (EDICOM) |
NOT STARTED |
| 3 |
Government reporting flow |
NOT STARTED |
| 4 |
Multi-ERP integration testing |
NOT STARTED |
| 5 |
DOM-TOM territory routing (e-invoicing vs e-reporting) |
NOT STARTED |
| Attribute |
Value |
| Model |
Private Exchange |
| Government System |
None — B2B direct (no clearance, no real-time reporting) |
| Government Role |
None (SAF-T on demand only — see below) |
| Deadline |
Jan 2025 (medium/large on certified systems), Jul 2026 (>300K DKK turnover) |
| Complexity |
LOW |
¶ Mandate Timeline
| Date |
Requirement |
Notes |
| 2005 |
B2G e-invoicing mandatory |
Via NemHandel — already active |
| Jan 2025 |
Medium/large companies on certified bookkeeping systems |
Bogføringsloven (2022 Bookkeeping Act) |
| Jul 2026 |
All companies >300K DKK turnover on certified systems |
E-invoice capability required |
Bookkeeping Act 2022 (Bogføringsloven) — three obligations:
- Certified digital bookkeeping system — ERP must be registered with the Danish Business Authority (Erhvervsstyrelsen)
- E-invoice capability — system must be capable of sending/receiving Peppol BIS 3.0 via NemHandel/Peppol. Not mandatory for every B2B transaction yet, but capability must exist
- SAF-T on demand — must produce Danish SAF-T XML when SKAT (tax authority) requests it. Not periodic — on demand only, but must be ready at all times
OIOUBL 3 CANCELLED (confirmed 14 Jan 2026 by Danish Business Authority). Denmark is moving to Peppol BIS 3.0 only — single standard, not dual.
| Penalty |
Detail |
| Administrative fine |
Up to DKK 1.5 million (~EUR 200K) |
| Qualified opinion |
On the annual report |
| Scope |
Non-compliance with certified system / SAF-T readiness |
- Peppol / NemHandel: NemHandel is Denmark's national e-invoicing infrastructure, interconnected with Peppol. Same network, same AS4 transport
- OIOUBL 3 cancelled: only Peppol BIS 3.0 going forward
- B2B not fully mandated yet — capability required, actual use by mutual agreement between trading partners
- B2G already mandated since 2005
- SAF-T is an ERP concern, not middleware — but middleware invoices contribute to the data SKAT may request
- Danish Business Authority (ERST) is the Peppol Authority in Denmark
| Attribute |
Value |
| AR Format |
Peppol BIS 3.0 (UBL 2.1) — EDICOM transforms from UCF |
| Transport |
Peppol network via EDICOM as Access Point |
| Network |
Peppol eDelivery (AS4) / NemHandel (interconnected) |
| Peppol ID |
0184:{CVR} (8-digit CVR number, no prefix) or 0088:{GLN} |
| AP Format (inbound) |
UCF JSON via EDICOM |
| AP Transport (SAP site) |
EDICOM → Middleware → SFTP → OpenText → SAP |
| AP Transport (AX site) |
EDICOM → Middleware → TBD (D365 + COR360 project underway) |
| Scheme |
EAS Code |
Format |
Example |
Usage |
| CVR (Central Business Register) |
0184 |
8 digits |
0184:12345678 |
Primary — mandatory for NemHandel registration |
| ERSTORG |
0198 |
variable |
0198:DK12345678 |
Alternative (allowed) |
| GLN |
0088 |
13 digits |
0088:5790000123456 |
Alternative (if registered) |
CVR number = Danish company registration number from the Central Business Register (Centrale Virksomhedsregister). Only companies with a CVR can register in NemHandel.
mandated_network = NO → intercompany invoices delivered directly by middleware (no EDICOM), same as Germany- No government submission required
- Peppol capability required but network not yet mandated for every B2B transaction
- Caveat: if LTA mandatory for Denmark (ACT-062 pending), intercompany would need EDICOM
| Site Code |
ERP |
AR |
AP |
AP Tool |
Notes |
| HTO DK |
SAP S/4H |
Yes |
Yes |
OpenText |
Same SAP instance as HTO DE (company 7471) |
| HAX DK |
AX / D365 |
Yes |
Yes |
TBD |
D365 + COR360 project underway. AR needs development |
| # |
Requirement |
Status |
| 1 |
Peppol BIS format mapping (EDICOM) |
NOT STARTED |
| 2 |
Peppol/NemHandel registration (EDICOM) |
NOT STARTED |
| 3 |
Confirm SAP certified with Danish Business Authority |
NOT STARTED (ACT-054) |
| 4 |
Confirm AX/D365 certified with Danish Business Authority |
NOT STARTED |
| 5 |
HAX DK AR extraction development |
NOT STARTED |
| 6 |
HAX DK AP tool confirmation |
NOT STARTED |
| 7 |
SAF-T readiness (ERP team) |
NOT STARTED |
| 8 |
Integration testing |
NOT STARTED |
| Issue |
Impact |
Status |
| HAX DK AR — no extraction mechanism exists yet |
High |
OPEN |
| HAX DK AP tool TBD (COR360 project underway) |
Medium |
OPEN |
| Karsten Aarestrup (FD) not yet consulted on e-invoicing |
High |
OPEN (ACT-054) |
| ERP certification status with Danish Business Authority unknown |
Medium |
OPEN |
| Attribute |
Value |
| Model |
Private Exchange (Peppol MANDATORY) |
| Government System |
None — B2B direct (e-reporting from Jan 2028) |
| Government Role |
None until 2028 (5-corner e-reporting planned) |
| Deadline |
January 2026 (B2B mandatory) |
| Complexity |
LOW |
¶ Mandate Timeline
| Date |
Requirement |
| Jan 2026 |
Mandatory B2B e-invoicing via Peppol |
| Q1 2026 |
3-month tolerance / grace period (no sanctions if reasonable steps taken) |
| Jan 2028 |
5-corner e-reporting to tax authority |
| Offence |
Fine |
| 1st offence |
€1,500 |
| 2nd offence |
€3,000 |
| 3rd offence |
€5,000 |
Penalties minimum 3 months apart. Q1 2026 grace: no sanctions if reasonable steps taken. Non-compliant invoices may be denied for VAT deduction.
- Peppol is MANDATORY — no PDF fallback, no alternative channels
- Structured electronic format only (Peppol BIS 3.0, UBL 2.1)
- Foreign suppliers invoicing Belgian customers must also use Peppol
- Exemptions: B2C transactions, Art. 44 exempt (healthcare, education), flat-rate scheme (Art. 56), non-established VAT-registered entities (receive only)
| Attribute |
Value |
| AR Format |
Peppol BIS 3.0 (UBL 2.1) -- EDICOM transforms from UCF |
| Transport |
Peppol network via EDICOM as Access Point |
| Network |
Peppol eDelivery (AS4) |
| AP Format (inbound) |
UCF JSON via EDICOM |
| AP Transport |
EDICOM -> Middleware -> SFTP -> COR360 -> IFS |
mandated_network = YES (Peppol) → intercompany invoices go through EDICOM (via Peppol network)- Peppol is legally mandated for all B2B — no exception for intercompany
- No government submission required (until Jan 2028 when 5-corner e-reporting starts)
| Site Code |
ERP |
AR |
AP |
AP Tool |
| HMP BE |
IFS |
Yes |
Yes |
COR360 |
| # |
Requirement |
Status |
| 1 |
Peppol BIS format mapping (EDICOM) |
NOT STARTED |
| 2 |
Transition from interim solution |
NOT STARTED |
| 3 |
Integration testing |
NOT STARTED |
| Country |
Model |
Government System |
Anticipated |
Notes |
| Italy |
Clearance Central |
SDI (Sistema di Interscambio) |
TBD |
FatturaPA format, complex |
| India |
Clearance (Single) |
IRP / NIC |
TBD |
Similar to Malaysia |
| Poland |
Clearance Central |
KSeF |
TBD |
National e-invoicing system |
| Spain |
Exchange + Reporting |
TBD |
TBD |
|
| Other EU |
Various |
Various |
TBD |
ViDA compliance |
Source of truth: Architecture Reference -- Architecture Rule #12, DEC-008.
Intercompany routing is conditional — based on mandated_network and lta_required flags on the company table for the destination country.
AR invoice → middleware validates → is it intercompany?
├── NO (external customer) → EDICOM (always)
└── YES (intercompany) →
├── MANDATED_NETWORK = YES? → EDICOM (legal requirement)
├── LTA = YES? → EDICOM (certified archival)
├── Clearance required? → EDICOM for clearance only, then direct delivery
└── None of the above → direct delivery (middleware delivers to customer)
| Scenario |
EDICOM? |
Government? |
Delivery Method |
Records Created |
| External → DE |
Yes |
No |
EDICOM → Peppol → Customer |
1 DELIVERY |
| External → DK |
Yes |
No |
EDICOM → Peppol/NemHandel → Customer |
1 DELIVERY |
| External → BE |
Yes |
No |
EDICOM → Peppol → Customer |
1 DELIVERY |
| External → FR |
Yes |
Copy to PPF |
EDICOM → PA → Customer + Gov copy |
1 DELIVERY |
| External → MY |
Yes |
Yes (clearance) |
EDICOM → MyInvois → EDICOM → Customer |
1 CLEARANCE + 1 DELIVERY |
| Intercompany → DE |
No (unless LTA) |
No |
Middleware → direct |
1 DELIVERY |
| Intercompany → DK |
No (unless LTA) |
No |
Middleware → direct |
1 DELIVERY |
| Intercompany → BE |
Yes (mandated network) |
No |
EDICOM → Peppol → Receiving entity |
1 DELIVERY |
| Intercompany → FR |
Yes (mandated network) |
Copy to PPF |
EDICOM → PA → Receiving entity + Gov copy |
1 DELIVERY |
| Intercompany → MY |
Clearance only |
Yes (self-bill) |
EDICOM → MyInvois (clearance), then middleware → direct |
1 CLEARANCE + 1 DELIVERY |
| Country |
mandated_network |
lta_required |
Effect on Intercompany |
| DE |
NO |
TBD (ACT-062) |
Direct delivery (unless LTA turns out to be mandatory) |
| DK |
NO |
TBD (ACT-062) |
Direct delivery (unless LTA turns out to be mandatory) |
| BE |
YES (Peppol) |
TBD |
EDICOM — Peppol network is legally mandated |
| FR |
YES (PA) |
TBD |
EDICOM — PA platform is legally mandated |
| MY |
NO (clearance only) |
TBD |
EDICOM for clearance, direct for delivery |
Note: LTA (Long-Term Archive) status per country is pending — ACT-062 (Kevin Bangert). If LTA is mandatory for a country, intercompany invoices for that country must go through EDICOM even if the network is not mandated.
How EN 16931, CII, UBL, Factur-X, ZUGFeRD, and XRechnung relate to each other.
¶ The Standards Hierarchy
EN 16931 (European semantic standard — defines WHAT data an e-invoice must contain)
│
├── Syntax 1: UN/CEFACT CII (Cross-Industry Invoice)
│ │
│ ├── Factur-X / ZUGFeRD (hybrid: PDF/A-3 container + embedded CII XML)
│ │ Used by: France (mandatory), Germany (B2B option)
│ │
│ └── XRechnung CII (pure CII XML, no PDF)
│ Used by: Germany (B2G mandatory, B2B accepted)
│
└── Syntax 2: ISO 19845 UBL 2.1 (Universal Business Language)
│
├── XRechnung UBL (pure UBL XML, no PDF)
│ Used by: Germany (B2G mandatory, B2B accepted)
│
└── Peppol BIS 3.0 (UBL 2.1 with Peppol constraints)
Used by: Belgium (mandatory), Denmark (mandatory capability)
Key insight: All these formats implement the same semantic model (EN 16931). Conversion between them is feasible because the underlying data elements are identical — only the syntax and container differ.
The European standard EN 16931 defines the semantic data model for a core invoice. It specifies WHAT information an invoice must contain (seller, buyer, line items, taxes, totals, etc.) but does NOT specify HOW to encode it. Two official syntaxes are sanctioned:
| Syntax |
Standard |
Organisation |
Usage |
| CII |
UN/CEFACT Cross-Industry Invoice (D22B) |
United Nations |
Factur-X/ZUGFeRD, XRechnung (CII variant) |
| UBL |
ISO 19845 UBL 2.1 |
OASIS |
Peppol BIS 3.0, XRechnung (UBL variant) |
Factur-X (France) and ZUGFeRD (Germany) are the same technical standard, jointly published by FNFE-MPE (France) and FeRD (Germany). Current version: Factur-X 1.08 / ZUGFeRD 2.4 (effective 15 Jan 2026).
What it is:
| Layer |
Detail |
| Outer container |
PDF/A-3 — a human-readable invoice PDF that complies with the archival PDF standard |
| Embedded attachment |
CII XML file — structured invoice data conforming to UN/CEFACT CII D22B |
| Result |
A single file that works for humans (open the PDF) AND machines (extract the XML) |
The XML file is embedded as an attachment inside the PDF/A-3 container using the PDF Associated Files mechanism. The PDF is the primary document; the XML is metadata.
Profile levels (increasing data completeness):
| Profile |
Content |
EN 16931 Compliant? |
Use Case |
| MINIMUM |
Header data only (invoice number, date, totals, parties) |
No |
Basic automation, Chorus Pro minimum |
| BASIC WL |
Document-level data (no line items) |
No |
Buyer process automation |
| BASIC |
BASIC WL + core line items |
No |
Standard B2B |
| EN 16931 |
Full EN 16931 semantic model |
Yes |
EU-compliant e-invoicing |
| EXTENDED |
EN 16931 + supplementary data (sub-lines, kits, bundles) |
Yes (superset) |
Complex invoices |
For France (Sep 2026 mandate): Minimum profile required is BASIC or EN 16931. MINIMUM alone is not sufficient for the French e-invoicing mandate.
For Germany: ZUGFeRD 2.x at EN 16931 profile or above is accepted as a compliant e-invoice format alongside XRechnung.
XRechnung is Germany's national implementation of EN 16931. It is pure XML — no PDF wrapper.
| Attribute |
Value |
| Format |
Pure XML (no PDF container) |
| Syntax |
Either UBL 2.1 OR CII — both are valid XRechnung |
| Standard body |
KoSIT (Koordinierungsstelle für IT-Standards) |
| Mandatory for |
German B2G (public sector) invoicing since Nov 2020 |
| Accepted for |
German B2B e-invoicing (Jan 2025+ receive, Jan 2027+ send) |
XRechnung and Factur-X/ZUGFeRD are not competing — they serve different purposes:
|
XRechnung |
Factur-X / ZUGFeRD |
| Contains PDF? |
No — pure data |
Yes — PDF/A-3 with embedded XML |
| Human-readable? |
Needs rendering/viewer |
Yes — open the PDF |
| Syntax |
UBL 2.1 or CII |
CII only |
| Primary audience |
Systems (machine-to-machine) |
Humans + systems (hybrid) |
| German B2G |
Mandatory |
Not accepted (pure XML required) |
| German B2B |
Accepted |
Accepted |
| Peppol |
Via Peppol BIS (UBL variant) |
Not native to Peppol |
¶ Peppol BIS 3.0 — Network Standard
Peppol BIS 3.0 is UBL 2.1 with additional Peppol-specific validation rules. It is the format used on the Peppol eDelivery network (AS4 transport).
| Attribute |
Value |
| Syntax |
UBL 2.1 (not CII) |
| Network |
Peppol eDelivery (AS4) |
| Used by |
Belgium (mandatory), Denmark (mandatory capability), Germany (optional) |
| Relationship to EN 16931 |
Compliant — Peppol BIS is a CIUS (Core Invoice Usage Specification) of EN 16931 |
| Country |
Format Sent to EDICOM |
Format EDICOM Delivers |
Why |
| Malaysia |
UCF JSON |
MyInvois JSON/XML |
Clearance — LHDN's own format, not EN 16931 |
| Germany |
UCF JSON |
XRechnung (Peppol-registered customers) or ZUGFeRD (others) |
FormatRouter decides based on customer capability |
| France |
UCF JSON |
Factur-X (PDF/A-3 + CII XML) |
French mandate requires Factur-X via PA platform |
| Belgium |
UCF JSON |
Peppol BIS 3.0 (UBL 2.1) |
Peppol is legally mandated for all B2B |
| Denmark |
UCF JSON |
Peppol BIS 3.0 (UBL 2.1) |
Peppol/NemHandel — same format as Belgium |
In all cases, Chart sends UCF JSON to EDICOM. EDICOM transforms to the country-specific format. Chart does not need to produce Factur-X, XRechnung, or Peppol BIS directly.
| Model |
Countries |
Government Role |
Process |
| Private Exchange |
DE, DK, BE |
None |
ERP -> EDICOM -> Customer (B2B direct via Peppol) |
| Exchange + Reporting |
FR |
Receives copy |
ERP -> EDICOM -> Customer + Government copy (simultaneous) |
| Clearance (Single) |
MY, MX, CO, CL |
Pre-approval |
ERP -> EDICOM -> Gov (approve) -> EDICOM -> Customer |
| Clearance Central |
PL, IT |
Clears via platform |
ERP -> EDICOM -> Gov platform -> Customer |
| Clearance Dual |
GR, HU |
Dual transaction |
ERP -> EDICOM -> Gov (approve + report) |
See Architecture Reference for state machines, component details, and status grids.