What is EN 16931? A guide to the European e-invoice standard

Historically, "electronic invoice" in Europe meant whatever a given software vendor decided it meant. A French ERP produced one shape of XML, a German system another, an Italian platform a third. Companies trading across borders had to maintain a separate integration for each format their customers happened to use, and the public sector — obliged to receive invoices from everyone — bore the brunt. EN 16931, published in 2017 by the European Committee for Standardisation (CEN), is the standard that resolved this.

A semantic model, not a file format

The first surprise about EN 16931 is that it does not specify a file format. It specifies a semantic data model: roughly 160 business terms with names like "Buyer reference", "VAT category code" and "Item net price", grouped into business groups such as "Seller party" and "VAT breakdown". The standard prescribes what an invoice must contain to count as a valid commercial document; it is silent on which bytes appear on disk.

This separation is deliberate. By keeping "what" distinct from "how", CEN allowed the standard to remain stable while the underlying file syntaxes evolve independently. The same invoice can therefore be expressed in two different XML formats and remain, in every meaningful sense, the same invoice.

The two syntaxes: UBL and CII

The standard endorses two XML syntaxes for representing the semantic model on the wire:

• UBL 2.1 (Universal Business Language), maintained by OASIS. Widely used in Northern Europe — Denmark, Norway, the Netherlands, Belgium.
• UN/CEFACT CII (Cross Industry Invoice), part of the UN trade facilitation work. The basis for Germany's XRechnung, the Franco-German Factur-X, and France's national format.

Both are XML, both express the same semantic model, both are EN 16931. The choice between them is largely a question of which ecosystem one's customers and tax authority happen to inhabit. There is no real technical advantage to either format in isolation; the matter is political and historical.

Anyone who has wondered why European e-invoicing carries two competing XML formats for the same content has the answer here: two industry bodies arrived first, neither was willing to abandon its work, and CEN endorsed both rather than declare a winner. For a closer comparison of the two, see UBL vs CII.

National customisations: the CIUS concept

EN 16931 is the European baseline. National tax authorities are free to add their own constraints on top of it — what the standard calls a CIUS, or Core Invoice Usage Specification. A CIUS may require fields that EN 16931 leaves optional, restrict code lists to a national subset, or add domestic business rules. What a CIUS cannot do is relax anything: every CIUS-compliant invoice is automatically EN 16931-compliant, but the converse does not hold.

The most prominent CIUSes today are:

• XRechnung — Germany. Mandatory for invoices to public administrations since 2020, and the receiving format for all B2B invoices in Germany since January 2025.
• Factur-X / ZUGFeRD — France and Germany. A hybrid PDF/A-3 with CII XML embedded inside, so that humans and machines can read the same file.
• PEPPOL BIS Billing 3.0 — used across the PEPPOL network and adopted as the de facto national format in Belgium, the Nordics, and parts of the Netherlands.
• FatturaPA — Italy. Predates EN 16931 but has been brought into alignment.

Most other member states have either published their own CIUS or are preparing to do so, generally built on PEPPOL BIS rather than from first principles.

Validation: the schematron layer

What gives "compliance with EN 16931" its substance is the fact that the standard ships with a machine-readable rule set. The rules are written in Schematron — an ISO standard for expressing business constraints over XML — and fall into several families:

• BR-* rules — the basics: required fields, mandatory cardinalities, presence of identifiers.
• BR-CO-* rules — internal consistency: that the invoice total equals the sum of line items, that calculated VAT matches rate × base, that period start dates precede end dates.
• BR-CL-* rules — code-list constraints: that currencies, units of measure and payment means come from the prescribed lists.
• VAT category rules (BR-S-*, BR-E-*, BR-AE-*, and so on) — the constraints specific to each VAT category. A reverse-charge invoice must carry VAT identifiers for both parties; an exempt invoice must cite a legal basis for the exemption.

Each CIUS layers its own rules on top. XRechnung adds the BR-DE-* family; PEPPOL adds PEPPOL-EN16931-*; the French CIUS adds BR-FR-*. A typical invoice is checked against perhaps 200–300 rules; the union across every CIUS we know of comes to roughly 2,000. The complete catalogue is in our rule reference.

What compliance provides

A compliant invoice is one that any EN 16931-aware software can:

• read without ambiguity, since every field has a defined meaning;
• validate automatically, with no human eyes needed for the basics;
• post into accounting systems with no manual data entry;
• prove tax-correct under the receiver's jurisdiction.

For sellers, this means an invoice accepted on the first try by every customer's system. For buyers, accounts payable can run on autopilot for the standard cases. For tax authorities, automated reporting becomes possible — and several member states are already using exactly this property to prefill VAT returns.

It is worth being precise about the limits of these benefits. Compliance with EN 16931 is the necessary minimum for any of them to materialise; it is not, by itself, sufficient. Automation only takes effect when both sides have integrated the standard. The standard's contribution today is the removal of one layer of friction — format negotiation — so that the layers above it (delivery, archiving, dispute resolution) become tractable. The sufficient conditions live in those upper layers, and they vary by country, sector, and contractual relationship.

The boundaries of the standard

Several things fall outside EN 16931 altogether:

• Transmission. The standard is silent on how the file moves from seller to buyer. Email, AS4, SFTP, the PEPPOL network, a portal upload — all are equally valid.
• Archival. Retention obligations are a national matter. Germany requires eight years (reduced from ten in 2025), France ten, Italy ten years for B2B with separate rules for B2C.
• Digital signatures. Some jurisdictions require a qualified electronic signature (QES) for a tax-compliant invoice; others do not.
• Document lifecycle. Status messages — "received", "approved", "paid", "disputed" — are layered on top by national platforms, not by the standard itself.

For anyone evaluating an "EN 16931 compliant" product, these are the right questions to ask: which CIUSes does it support, which transmission channels, what does it offer for archival, and how does it handle the lifecycle messages required by the relevant tax authority.

How to know your invoice complies

To know whether an invoice complies, run it through a validator. The standard's strength — that it ships with executable rules — also means a definitive yes or no exists for any given file. There is no judgement call and no "looks about right": the schematron either fires or it does not.

Our free validator checks any UBL or CII invoice against the EN 16931 baseline and the major CIUSes. A green report means the file will be accepted by any compliant receiving system. A red report identifies the rule that failed, the location of the failure, and a plain-language explanation of what to put right.