EN 16931
EN 16931 is the European standard that defines the semantic data model of an electronic invoice — that is, which details an e-invoice contains and what they mean. It forms the content basis for formats such as XRechnung and ZUGFeRD.
EN 16931 is the European standard that defines the semantic data model of an electronic invoice: it specifies which information an e-invoice can contain, what those details are called, what they mean in business terms and which of them are mandatory. The standard was developed by the European standardisation body CEN on behalf of the EU Commission and published in 2017. At its core is a so-called Core Invoice Model comprising around 160 business invoice elements — from the invoice number through line-item data and tax rates to payment terms and buyer reference.
What matters is the role EN 16931 plays: it is not a file format but a set of content rules. Formats such as the German XRechnung, the hybrid format ZUGFeRD or the international Peppol BIS Billing translate this model into concrete XML syntaxes. So when someone speaks of a standard-compliant e-invoice, they mean an invoice whose data and rules conform to EN 16931 — regardless of the technical form in which it is ultimately transmitted. This makes the standard the common denominator that enables Europe-wide interoperability of electronic invoices in the first place.
At a glance
- European standard (CEN, 2017) for the semantic data model of the e-invoice
- Defines around 160 business invoice elements — not a file format but a content model
- Permits two XML syntaxes: UBL 2.1 and UN/CEFACT CII
- Basis for XRechnung, ZUGFeRD (from the EN 16931 profile) and Peppol BIS Billing
- Derived from EU Directive 2014/55/EU; foundation of the German B2B e-invoicing mandate
What EN 16931 governs — and what it does not
EN 16931 describes the semantics of an invoice, not its outward form. The standard bundles invoice content into a structured model of groups and individual fields: each element has a unique identifier (for example BT-1 for the invoice number), a defined meaning, a data type and an indication of whether it is mandatory, conditional or optional. This means every receiving system understands exactly what a value expresses — an amount in the "net total" field is the same figure everywhere in Europe.
What the standard deliberately leaves open is the transmission route. Whether an invoice is sent by email, via a portal or through a network like Peppol is not the subject of EN 16931. Nor does it prescribe a single file format. Instead, it defines a common business language that can be "spoken" by different technical formats. It is precisely this separation of content and transport that makes the standard robust and durable.
Structure of the standard: data model, syntaxes and rules
The standard itself, EN 16931-1, contains the semantic core model. It is complemented by technical specifications that define how the model is translated into machine-readable XML, as well as by an extensive set of validation rules (Business Rules) against which every invoice can be checked.
The two permitted syntaxes
EN 16931 allows exactly two XML syntaxes in which the core model may be technically represented: UBL 2.1 (Universal Business Language) and UN/CEFACT CII (Cross Industry Invoice). Both carry the same business information but differ in structure and field names. In Germany, CII is particularly widespread, for example in ZUGFeRD; XRechnung supports both syntaxes. Because both reference the same semantic model, they can be converted into one another without loss.
Business Rules and validation
The standard includes a set of machine-readable business rules tagged with identifiers such as BR-1 or BR-CO-10. They check, for example, whether mandatory fields are present, whether totals add up arithmetically and whether tax details are consistent. An invoice is considered standard-compliant only if it passes these rules without error. Receiving systems and public validation services use exactly this rule set to check incoming documents automatically — a key advantage over unstructured invoices.
EN 16931, XRechnung, ZUGFeRD and Peppol in interplay
The standard is the basis on which the formats used in practice build. To adapt it to national or industry-specific requirements, EN 16931 provides for so-called CIUS (Core Invoice Usage Specifications) and Extensions. A CIUS restricts or refines the core model without contradicting it — it adds no new obligations that run counter to the standard.
The German XRechnung is exactly such a CIUS: it makes EN 16931 concrete for the German public administration, for example through a mandatory routing ID (Leitweg-ID). ZUGFeRD, in turn, is a hybrid format whose profiles from the "EN 16931" level (formerly "Comfort") fulfil the standard and whose data set can be embedded in a PDF/A-3 file. At the international level, Peppol BIS Billing 3.0 is also a CIUS of the standard and additionally governs the exchange over the Peppol network. All three speak the same business language — which is why an XRechnung is, in principle, readable for any system that processes EN 16931.
Why EN 16931 matters in the ERP system
For an ERP system, EN 16931 is the benchmark against which the invoicing functions must be aligned. On the outbound side, the system must generate a standard-compliant data set from the existing document and master data — customer, line items, tax keys, payment terms — that correctly fills all mandatory elements and passes the Business Rules. If, for example, a valid buyer reference is missing or a tax rate does not match the tax category, the invoice is rejected during validation.
On the inbound side, the standard enables fully automated processing: because every field has a defined meaning, the ERP can read in an incoming invoice without re-keying, match it to open purchase orders and check it in a three-way match against order and goods receipt. This requires clean data quality in the master data and correctly configured tax logic. In practice, EN 16931 therefore means less that users need to know the standard themselves — rather, the ERP or a connected invoicing solution should ensure compliance and validation in the background.
DACH specifics and distinctions
In Germany, EN 16931 is the content foundation of the B2B e-invoicing mandate: since 2025, a document only counts as an e-invoice if it is issued in a structured format and conforms to the standard or is interoperable with it. In Austria, invoice exchange with the administration is likewise based on European standards, often via the business service portal (Unternehmensserviceportal) or Peppol; Switzerland, as a non-EU country, is not bound by the standard but in practice sometimes follows the same formats.
EN 16931 must be clearly distinguished from the terms with which it is often confused. It is not the e-invoice itself but its content model. It is not a format like XRechnung or ZUGFeRD but their basis. And it is not a transmission network like Peppol but merely describes what the invoice contains. Anyone who separates these layers — content (standard), format (syntax/profile) and transport (network) — understands the e-invoice without the typical misunderstandings. This article provides a general overview and does not replace tax advice in individual cases.
Example
Example: mid-sized company validates its invoices against EN 16931
A mid-sized machinery manufacturer switches its outgoing invoices to ZUGFeRD. In the ERP, an XML data set to EN 16931 is generated whenever an invoice is created and embedded in the PDF/A-3 file. Before dispatch, the invoice is automatically run against the standard’s Business Rules: a document in which the tax amount does not match the stated net total is intercepted before it reaches the customer.
On the inbound side, the same company receives supplier invoices as XRechnung. Because both formats are based on EN 16931, the ERP reads out the structured data directly, matches it to the corresponding purchase order and triggers the approval workflow. Accounting is spared manual data entry; the documents move into the archive in an audit-proof manner and are handed over to the tax firm via the DATEV interface.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about EN 16931 in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.