EU E-Invoicing Formats 2026: UBL 2.1, XRechnung, Factur-X and FatturaPA

What Counts as an E-Invoice in the EU

An e-invoice is not a PDF attached to an email. It is a structured document: data in a machine-readable format that the recipient's accounting system can import, validate and archive without a single manual keystroke. A flat PDF, a scan or a printout is a digital document, not an e-invoice, because someone must retype it. That distinction is the entire point of the incoming mandates: tax authorities want transaction data they can reconcile, and businesses want invoices that land directly in their ERP.

The national deadlines make the definition operational. Italy has required structured invoices through SDI since 2019. Poland's KSeF becomes mandatory in February 2026. France switches to e-invoicing through certified platforms from September 2026 for large taxpayers and September 2027 for everyone else. From those dates, sending a conventional PDF where a structured file is required means the invoice does not legally exist for the recipient.

There is one accepted bridge between the paper world and the data world: a hybrid file. A PDF/A-3 document with an EN 16931 XML invoice embedded inside it - Factur-X, also known as ZUGFeRD in its German profile - is a true e-invoice, because the structured data travels within the readable page. Everything else is either a plain document or a plain XML file, never both.

EN 16931: the Standard Behind Every Format

EN 16931-1 is the European semantic standard for e-invoicing. It defines a common data model: which fields an invoice must contain, what each field means, and how totals must reconcile. National formats do not reinvent this model - each one is a CIUS, a Core Invoice Usage Specification, which is a country profile of EN 16931 with local extensions where a ministry needs them.

Two XML syntaxes express the standard. UBL 2.1, the Universal Business Language from OASIS, is a general-purpose business document schema. CII, the Cross Industry Invoice from UN/CEFACT, is the German-origin alternative. Both can carry a fully compliant EN 16931 invoice; the choice depends on the country profile, not on the semantics.

The core elements every compliant invoice must carry:

If any core element is missing, national validators reject the file before it reaches the recipient. This is why generating invoices by hand fails the moment volume grows: the schema is unforgiving by design.

The Four Format Families

UBL 2.1 - the dominant European syntax

UBL 2.1 is an OASIS XML standard covering invoices, credit notes, orders and despatch advices. It is the base syntax of Peppol BIS Billing 3.0, the cross-border network standard, and it underpins the largest national systems: Poland's KSeF accepts UBL 2.1 with Polish FA(2) and FA(3) schema extensions, and France defines its CIUS-FR profile on UBL 2.1. A UBL 2.1 invoice is plain XML: no wrapper, no PDF, importable by any modern ERP. If you can generate UBL 2.1 correctly, you are one transport step away from most European markets.

XRechnung - Germany's public-sector standard

XRechnung is the German CIUS of EN 16931, developed by KoSIT, the municipal data centre of Duisburg, Essen and Dortmund, using UBL 2.1 as its syntax. It is mandatory for German public procurement and has been the required B2G format through the central receiving portals since January 2025, delivered either via Peppol or the national portals ZRE and OZG-RE. The B2B obligation follows later: from January 2028 it phases in by company size under the German VAT Act. Any invoice addressed to a German public authority must be XRechnung - a branded PDF will be refused at the portal.

Factur-X - the hybrid PDF with embedded data

Factur-X is a single file that is both: a normal PDF/A-3 page a human can read and sign, with the complete EN 16931 invoice embedded as CII XML inside it. It was created jointly by French and German associations - FNFE-Mouvement and Neuregio - and the German profile is published as ZUGFeRD 2.x, so the two names describe the same hybrid architecture. For teams whose approval workflow still depends on a visual document but whose partner requires structured data, Factur-X satisfies both sides in one attachment. France accepts it alongside UBL-based files, and it is the practical answer wherever a mandate is coming but PDF habits are hard to break.

FatturaPA - Italy's national format

FatturaPA is Italy's own XML schema, in mandatory use for every B2B and B2G invoice since 2019. Files travel through SDI, the Sistema di Interscambio, routed to each recipient by a seven-character Codice Destinatario or a registered PEC address. Italy applies the hardest penalties in the EU for non-compliance - between 90 and 180 percent of the VAT due - and invoices must be archived for ten years. There is no hybrid option: an Italian invoice is a FatturaPA file or it is not an invoice.

Country Formats and Mandate Dates

The table reflects the national status verified in September 2026. Dates are the B2B obligations unless noted.

All of this sits on top of the ViDA package: Directive (EU) 2025/516, adopted on 11 March 2025, which every Member State must transpose by 31 December 2026. Its Digital Reporting Requirements begin real-time reporting for cross-border B2B in 2029 and extend to all cross-border B2B transactions by July 2030. National dates above come first; the EU-wide reporting layer follows them.

Cross-Border Invoicing: Peppol BIS 3.0

Peppol is a transport network, not a format - it is the postal system for structured documents, and the standard letter it carries is Peppol BIS Billing 3.0: an EN 16931 invoice in UBL 2.1. The network runs a four-corner model. The sender creates the invoice in their ERP and hands it to their own Access Point; the Access Point validates, signs and routes it; the recipient's Access Point receives and delivers it into the recipient's ERP; the recipient gets structured data, not an attachment. Access Points are certified providers - think of them as the email servers of the e-invoicing world, each knowing how to address participants on the network.

For cross-border intra-EU invoicing, Peppol is increasingly the expected route: countries such as France and Italy connect their domestic platforms to Peppol for foreign counterparties. Practically, you register a participant ID through your Access Point once, and every counterparty on the network becomes reachable without exchanging portal credentials one by one.

Which Format Should You Send?

• Domestic invoice in Poland: KSeF API with the FA(3) schema - no KSeF number on the invoice means the recipient cannot deduct the VAT.
• Invoice to a German public authority: XRechnung via Peppol, ZRE or OZG-RE.
• Domestic invoice in France: UBL 2.1 with the CIUS-FR extensions through your PDP platform from the applicable phase date.
• Invoice in Italy: FatturaPA through SDI, with the recipient's Codice Destinatario.
• Cross-border B2B anywhere in the EU: Peppol BIS 3.0 through a certified Access Point.
• Your partner insists on a readable document: Factur-X, which keeps the PDF and embeds the same structured data.

If you only generate one file type, make it UBL 2.1 - it is the common denominator of Peppol, KSeF and the French profile, and conversion into country-specific wrappers is mechanical from there.

How to Generate a Compliant Invoice

The UBL E-Invoice Kit turns a simple data entry - supplier, customer, lines, rates, totals - into a structurally valid UBL 2.1 document you can download and inspect before it goes anywhere. The workflow that works in practice: build the invoice, validate the structure, confirm the customer's VAT number on VIES, then hand the file to your ERP, your PDP or your Access Point for delivery. For recurring invoices, keep the same validated template and change only the data - schema errors hide in manual rebuilds.

Rejection Triggers: What Makes Validators Say No

• Wrong schema version: Poland migrated schemas over time - a FA(2) file submitted after the FA(3) cutover is refused.
• Missing or invalid VAT IDs: validate every counterparty number on VIES before sending; a dead VAT number invalidates the reverse-charge treatment.
• Wrong type or currency codes: code 380 for invoices, 381 for credit notes, ISO currency codes exactly.
• A PDF where structured data is required: after the national mandate date, a flat PDF is simply not an invoice.
• Missing routing identifiers: no Codice Destinatario in Italy, no KSeF number in Poland - the file never reaches the recipient's account.
• Absent signature where national rules require one: some platforms expect a qualified electronic seal on top of the structured payload.

Frequently Asked Questions