E-invoicing standards explained: EN 16931, UBL, CII, Peppol BIS and the national formats

When people ask for “the e-invoicing standard”, they are usually asking about at least three different things at once: what data an invoice must carry, which file format expresses it, and which national rules apply on top. Those are separate layers, and a compliant invoice has to satisfy all of them. Get the layers straight and most of the confusion disappears.

This guide walks the stack from the semantic model down to the country-specific formats, and explains where the widely used names — EN 16931, UBL, CII, Peppol BIS, XRechnung, Factur-X, ZUGFeRD, FatturaPA — actually sit.

The four layers of an e-invoicing standard

Any structured e-invoice can be described by four independent choices:

• Semantic model — what information the invoice contains and what each field means (seller VAT ID, line net amount, tax category, and so on).
• Syntax — the XML grammar that encodes those fields into a file.
• Profile (CIUS / extension) — a national or network-specific narrowing of the model: which optional fields become mandatory, which code lists are allowed.
• Transport — how the file actually moves (the Peppol network, a national clearance portal, a tax-authority API).

Two invoices can share a semantic model but use different syntaxes; two can share a syntax but follow different national profiles. That is why “we support UBL” on its own does not tell you whether an invoice is accepted in Belgium, Germany or Singapore.

EN 16931: the European semantic standard

EN 16931 is the European standard that defines the core semantic model of an electronic invoice. It was developed by the European standards body CEN at the request of the European Commission, to support Directive 2014/55/EU — the directive that requires public-sector bodies across the EU to be able to receive and process electronic invoices.

The key point that trips people up: EN 16931 is not a file format. It is a list of the roughly 160 business terms an invoice can carry and the rules that relate them. It deliberately does not pick a single XML syntax. Instead it is bound to two syntaxes, either of which can carry an EN 16931-compliant invoice.

When a query asks “what is the EN e-invoicing standard” or “the European standard for e-invoicing”, EN 16931 is the answer — it is the common denominator that most European mandates build on.

The two syntaxes: UBL 2.1 and UN/CEFACT CII

EN 16931 is bound to exactly two XML syntaxes:

• UBL 2.1 (Universal Business Language, maintained by OASIS) — the more widely deployed of the two across Europe, and the syntax underneath Peppol.
• UN/CEFACT CII (Cross Industry Invoice) — used heavily in France and Germany, and the XML that sits inside hybrid PDF formats.

Both express the same semantic model. An invoice that is valid EN 16931 in UBL contains the same business information as the same invoice in CII — the tags are just different. A receiving system built for one syntax will not automatically read the other, which is why cross-border senders often need both.

National and network profiles (CIUS)

A CIUS — Core Invoice Usage Specification — is a profile that restricts EN 16931 for a particular country, network or sector: it can make optional fields mandatory or limit code lists, but it stays inside the EN 16931 model. The two you will meet most often:

Peppol BIS Billing 3.0 is a CIUS of EN 16931, expressed in UBL 2.1, and governed by OpenPeppol. It is the format exchanged over the Peppol network and the basis of mandates in Belgium, Norway, Denmark, the Netherlands and others. If a mandate says “Peppol”, this is almost always the document format meant. See what a Peppol Access Point is for how it is transmitted.

XRechnung is the German CIUS of EN 16931, mandatory for invoicing German public-sector buyers (B2G) and a reference format inside Germany's wider B2B receiving obligation. XRechnung can be expressed in either the UBL or the CII syntax. Our XRechnung guide covers it in depth.

Hybrid formats: Factur-X and ZUGFeRD

Factur-X (the French name) and ZUGFeRD (the German name) are the same idea and are technically aligned: a PDF/A-3 document with an EN 16931-compliant CII XML file embedded inside it. A human reads the PDF; a machine reads the embedded XML. This hybrid approach is popular because it lets a supplier keep sending something that looks like a normal invoice while still shipping structured data underneath.

At its EN 16931 profile, the embedded XML carries the full core invoice model, so a Factur-X or ZUGFeRD file can be processed as a genuine structured e-invoice — not just a PDF with an attachment. France's upcoming mandate explicitly allows Factur-X alongside plain UBL and CII.

Formats outside the EN 16931 family

Not every mandate is built on the European standard. Several major markets run their own national schema, and treating them as “just another UBL” is a common integration mistake:

• FatturaPA (Italy) — Italy's own national XML schema, exchanged through the SDI clearance platform. It predates EN 16931 and is not based on it; an EN 16931 UBL file is not a valid FatturaPA document.
• FA(2) / FA(3) (Poland) — the KSeF schema. Poland's central-hub model uses its own XML, not Peppol BIS. See the KSeF guide.
• Legacy national formats — older country formats such as Sweden's Svefaktura are being retired in favour of Peppol BIS, but you may still encounter them in existing systems during migration.

myDATA in Greece and comparable real-time reporting systems are a related but distinct obligation: they govern reporting invoice data to the tax authority, layered on top of whatever document format you exchange.

Beyond Europe: Peppol PINT

Peppol started in Europe but is now used well outside it, and the base European billing specification does not fit every jurisdiction's tax rules. To handle that, OpenPeppol introduced Peppol PINT (Peppol International) — an international invoice model with country-specific specializations built on top:

• JP PINT — the Japanese specialization, used with Japan's qualified-invoice system.
• PINT A-NZ — Australia and New Zealand.
• SG PINT — Singapore.

PINT means a supplier can stay on the same Peppol transport while sending a document shaped to each country's local requirements, rather than forcing every market onto the European billing profile. See the Japan and Singapore country guides for how these apply in practice.

How the standards line up

What this means if you sell across borders

The practical takeaway is that “support the standard” is never a single deliverable. A business invoicing across Europe and into Asia might need Peppol BIS for Belgium, XRechnung for German public buyers, Factur-X for France, FatturaPA for Italy, the KSeF schema for Poland, and a PINT variant for Japan — several of which are not interchangeable even though they describe the same underlying sale.

That is the problem a single API is meant to solve: you send one consistent invoice payload, and the mapping to the right format, profile and transport for each destination happens for you rather than being re-implemented per country. For a full picture of how the formats connect to the different mandate types, read what is e-invoicing and the five compliance models.