EN 16931: the European e-invoice standard explained

EN 16931 is the European standard that defines what an electronic invoice contains: a semantic data model of business terms, their meaning, their cardinality and the rules between them. It is not a file format. Two XML syntaxes carry the model — UBL 2.1 and UN/CEFACT Cross Industry Invoice — and national or sector specifications such as XRechnung, ZUGFeRD, Factur-X and Peppol BIS Billing 3.0 restrict or extend it. Public buyers in the EU must accept EN 16931 invoices; Germany, France and Belgium built their B2B mandates on it.

Why EN 16931 exists

EN 16931 exists because Directive 2014/55/EU asked for one European standard to replace the incompatible national e-invoice formats that were fragmenting public procurement. The directive required the standard to be technologically neutral, compatible with international standards, practical for SMEs and usable in B2B trade, and to come with a "limited number of syntaxes".

CEN/TC 434 delivered it in 2017. The Commission published the reference of EN 16931-1:2017 and the syntax list in the Official Journal on 17 October 2017 (Implementing Decision (EU) 2017/1870), which started the clock for the B2G receiving obligation. Since then the standard has become the common denominator of European e-invoicing: the German VAT Act defines an e-invoice by reference to it, France's accepted formats are EN 16931 syntaxes, and Belgium's default format is an EN 16931 CIUS. The EU context is on the EU requirements page.

The parts of the standard

EN 16931 is a family of documents: one normative part with the semantic model, one technical specification listing syntaxes, and supporting bindings and reports.

Only Parts 1 and 2 are free, under the licence agreement between the Commission and CEN. Everything an implementer needs for validation, however, is public: the Schematron artefacts are published on GitHub by the Commission's eInvoicing team.

The semantic model: business terms and groups

The semantic model lists every information element an invoice may carry, numbered as business terms (BT) and grouped into business groups (BG), with a cardinality that says whether the element is mandatory, optional or repeatable.

Examples of what the model covers:

• Document level: invoice number, issue date, invoice type code, currency, buyer reference, payment due date, preceding invoice reference for credit notes and corrections.
• Parties: seller and buyer with name, address, VAT identifier, legal registration identifier and electronic address; optional payee and tax representative.
• Delivery and payment: delivery date and address, payment means (credit transfer, direct debit, card), payment terms, bank account.
• Allowances and charges at document and line level, each with a VAT category.
• VAT breakdown: one group per VAT category and rate, with taxable amount, VAT amount and, where the rate is zero or absent, an exemption reason.
• Totals: sum of line net amounts, allowances, charges, total without VAT, total VAT, total with VAT, prepaid amount, amount due.
• Lines: quantity, unit, net price, line net amount, VAT category, item identifiers and classification.

The model is deliberately "core": it holds what a majority of European invoices need for VAT and payment purposes, not every field an industry might want. Extra needs are handled through extensions, described below. A developer's walk-through of the elements with request examples is in the EN 16931 developer guide.

Syntaxes: UBL 2.1 and UN/CEFACT CII

The semantic model is carried by two XML syntaxes listed in CEN/TS 16931-2 and published in the Official Journal: OASIS UBL 2.1 (ISO/IEC 19845:2015) and UN/CEFACT Cross Industry Invoice (CII) D16B. A UN/EDIFACT binding exists as Part 3-4 but is not in the published list.

Both syntaxes express the same business terms, so an EN 16931 invoice can be represented in either without loss of the core content. Which one you meet depends on the ecosystem:

A receiving system that claims EN 16931 support should accept both syntaxes; in practice many national channels narrow the choice. Peppol requires UBL. ZUGFeRD and Factur-X embed CII. The format guide lists what each country expects.

CIUS and extensions: how countries adapt the core

A CIUS (Core Invoice Usage Specification) narrows EN 16931 — it may make optional elements mandatory, restrict code lists or add rules — but never adds elements, so every CIUS invoice is still a valid EN 16931 invoice. An extension adds elements and is therefore not automatically valid for a receiver that only knows the core.

XRechnung (Germany)

A CIUS maintained by KoSIT for public buyers, in UBL or CII, with a buyer reference (Leitweg-ID) and national code-list rules. Version 3.0.2 has been in force since 1 February 2024, kept current through bugfix bundles, the latest being the "Winter 2025/26" edition effective 31 January 2026. XRechnung also defines an extension mechanism. See XRechnung.

Peppol BIS Billing 3.0

OpenPeppol's CIUS, UBL mandatory, identified by the customization ID urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, with rules prefixed PEPPOL-EN16931-R and country-specific rules on top. Current release 3.0.21 (May 2026). See Peppol.

ZUGFeRD / Factur-X

The German-French hybrid defines profiles: MINIMUM and BASIC WL carry less than the core and are not EN 16931 conformant on their own; BASIC is a subset; EN 16931 is the full core; EXTENDED goes beyond it. Version 2.5.2 (Factur-X 1.09.2) was published on 4 August 2026 and applies from 1 September 2026, based on CII D22B with backward compatibility to D16B. See ZUGFeRD and Factur-X.

Every CIUS and extension announces itself in the invoice: the customization ID (BT-24) says which specification the file follows, and the profile ID (BT-23) names the business process. A receiver reads these two values before choosing a rule set.

Business rules and validation

An EN 16931 invoice is valid when it passes the schema of its syntax and the business rules of the semantic model, expressed as Schematron. The rules are the part that catches real-world mistakes: totals that do not add up, a VAT breakdown that misses a category, a missing seller VAT identifier where one is required.

The Commission's eInvoicing team publishes the validation artefacts on GitHub (ConnectingEurope/eInvoicing-EN16931) for UBL and CII; the latest release is 1.3.16 of 10 April 2026, with a roughly six-monthly cadence. Rule identifiers follow a pattern:

• BR-xx — general rules on presence and structure (an invoice shall have a number, an issue date, a seller name, …).
• BR-CO-xx — calculation and consistency rules, for example that the invoice total equals the sum of line net amounts plus charges minus allowances.
• BR-S-, BR-Z-, BR-E-, BR-AE-, BR-IC-, BR-G-, BR-O-, BR-IG-, BR-IP- — rules per VAT category: standard, zero-rated, exempt, reverse charge, intra-Community, export, out of scope, and the Canary Islands and Ceuta/Melilla taxes.
• BR-CL-xx — code-list rules (currency codes, unit codes, VAT category codes, country codes).

National specifications layer their own rule sets on top: KoSIT publishes an XRechnung Schematron and a configurable validator, and OpenPeppol publishes the Peppol rules. A file therefore has to pass up to three layers — schema, EN 16931 core, national CIUS — and each layer reports its own identifiers. The free e-invoice checker runs a file through the rules of the chosen country without storing it.

Versions: 2017, A1:2019 and the 2026 edition

The edition in force for most of the last decade is EN 16931-1:2017 with its amendment A1:2019. According to the Commission, a new edition, EN 16931-1:2026, was published in May 2026; the 2017 edition has been formally withdrawn but remains compliant during a migration period, and migration plans are being developed by the relevant organisations and Member State authorities.

What this means for implementers today: the customization IDs in circulation still reference urn:cen.eu:en16931:2017, and the validation artefacts, XRechnung and Peppol BIS all continue to work against the 2017 model. FeRD notes that the EXTENDED profile of ZUGFeRD 2.5.2 already carries additional elements "for the French B2B e-invoicing reform and the revised EN 16931 data model". Expect the national specifications to publish their own migration dates; until they do, the 2017 model is what receivers validate against.

How KRONENWERK handles this

KRONENWERK generates EN 16931 invoices in the syntax and CIUS the buyer's country expects, and validates them against the applicable rule layers before the invoice is issued.

• Germany — XRechnung (UBL or CII) and ZUGFeRD, validated with the KoSIT Schematron rules and cross-checked with the Mustang library: SUPPORTED.
• France — Factur-X as PDF/A-3 with embedded CII: generation SUPPORTED; transmission through an approved platform NOT YET READY.
• Belgium — Peppol BIS Billing 3.0 UBL: SUPPORTED WITH LIMITATIONS, sent and received through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery.
• Receiving — incoming XRechnung, ZUGFeRD/Factur-X and UBL files are read into bills: SUPPORTED.

The VAT category on each line and in the VAT breakdown comes from the invoice's tax verdict (standard, zero-rated, exempt, reverse charge, outside scope), which is derived from the transaction's facts and never guessed; where a professional would have to decide, the invoice is held with "requires professional confirmation". Poland's FA(3) is a national schema outside EN 16931 and is covered on the FA(3) page. Developers can create drafts through the e-invoicing API; the product overview is on the e-invoicing page. Back to the Europe hub.

Frequently asked questions

Is EN 16931 a file format?

No. It is a semantic model — a list of business terms and rules. The file formats are the syntaxes that carry it, UBL 2.1 and UN/CEFACT CII, and the specifications built on them such as XRechnung, ZUGFeRD, Factur-X and Peppol BIS.

Is a ZUGFeRD invoice EN 16931 compliant?

The EN 16931 and EXTENDED profiles carry the full core; BASIC is a subset that validates against the core rules; MINIMUM and BASIC WL carry less than the core and are not conformant EN 16931 invoices on their own.

What is the difference between a CIUS and an extension?

A CIUS restricts the core (more mandatory elements, narrower code lists) and stays valid for every EN 16931 receiver. An extension adds elements and needs a receiver that understands them.

Where do I get the validation rules?

The Commission's Schematron artefacts for UBL and CII are public on GitHub (ConnectingEurope/eInvoicing-EN16931). KoSIT publishes the XRechnung rules and validator; OpenPeppol publishes the Peppol BIS rules.

Do I have to migrate to EN 16931-1:2026 now?

Not on 3 September 2026. The Commission states the 2017 edition remains compliant during a migration period and that plans are still being developed. Follow the announcements of KoSIT, OpenPeppol, FeRD/FNFE and your national authority.