EN 16931 is a European standard that defines the semantic data structure of an electronic invoice. It was initiated by the European Union (EU) to ensure cross-border interoperability and reduce trade barriers in the digital single market.
Since 2025, electronic invoicing has been the legal standard in the German B2B sector, i.e., for invoices issued to businesses. A “proper e-invoice” must comply with the European standard EN 16931. Companies are therefore no longer free to choose the format; structured, machine-readable invoices become mandatory.
The standard ensures that:
- invoices are interoperable across Europe
- IT systems can automatically validate and post invoices
- media discontinuities and manual errors are reduced
- legal requirements are met
What does this mean in practical terms for companies?
EN 16931 is not a file format like PDF, but a binding data model. In practice, it is currently implemented via XML-based formats such as:
- XRechnung (public administration, Germany)
- ZUGFeRD from version 2.0 onwards (hybrid format with an XML core)
Companies must ensure that their ERP or accounting systems:
- can generate EN 16931-compliant invoices
- can process incoming structured invoices
- take current validation rules and code lists into account
However, the standard is not only a technical standard, but also a regulatory instrument. It forms the basis for further digitization initiatives at EU level (e.g., “VAT in the Digital Age”).
This makes it a central building block for:
- tax compliance
- process automation
- digital business models
- future reporting and disclosure obligations
EN 16931 is the shared “vocabulary” of electronic invoicing in Europe. Those who master it not only meet legal requirements, but also create the basis for efficient, automated finance processes.
What companies need to implement now
The obligation to receive structured e-invoices is already a reality. Transitional rules for issuing invoices are being phased out step by step. Companies should therefore, at the latest now, work fully in compliance with EN 16931 and adjust their processes accordingly.
Specifically, this means:
- use structured formats such as XRechnung or ZUGFeRD in production
- process XML invoices in a technically valid manner
- take current code lists and validation rules into account
- document processes in an audit-proof manner
Anyone who continues to work primarily with PDF will come under time pressure due to the transitional deadlines until the end of 2026 (companies with more than 800,000 euros in turnover) and until the end of 2027 (for all B2B companies).
Legal origin and mandate
The standard is based on Directive 2014/55/EU. This directive required all public contracting authorities in the EU to receive and process electronic invoices, provided they comply with the European standard. In Germany, this directive was transposed into national law by the E-Invoicing Act and the E-Invoicing Ordinance (E-RechV).
What exactly does EN 16931 regulate?
The standard does not define a specific technical file format (such as XML), but rather a semantic data model. This means it specifies what information must be included in an invoice and how that information relates to one another.
The standard consists of several parts, with the most important part being EN 16931-1:
- Semantic data model: Definition of the core elements, which are divided into logical groups (Business Groups, BG) and individual data fields (Business Terms, BT). This is where all essential information is defined (e.g., seller, buyer, delivery details, tax information, and the individual invoice lines).
- Mandatory and optional fields: Determination of the occurrence frequency for each Business Term. This specifies which fields are mandatory (cardinality 1..1, e.g., invoice number/BT-1) and which are optional (cardinality 0..1 or 0..n).
- Business rules (Business Rules): Logical checks that link the individual Business Terms and ensure that the invoice is mathematically and legally correct (e.g., “The sum of the net amounts plus VAT must equal the gross amount”).
The parts of the standard at a glance
| Part | Title / focus | Significance |
| Part 1 | Semantic data model | Definition of all Business Groups (BG) and Business Terms (BT). |
| Part 2 | List of syntaxes | Approval of UBL 2.1 and UN/CEFACT CII. |
| Part 3-1 | Methodology of syntax binding | Guidance on how a Business Term is technically translated into XML. |
TIP: Using standardized Business Terms ensures that recipient systems, regardless of the software used, know exactly where in the data set to find information such as the due date or cash discount terms.
Technical implementation: syntaxes
Since a data model alone is not machine-readable, the standard specifies in Part CEN/TS 16931-2 the technical languages (syntaxes) in which the invoice may be written. Currently approved are:
- UN/CEFACT XML: (Cross Industry Invoice – CII), the basis for the ZUGFeRD format (from version 2.0).
- UBL 2.1: (Universal Business Language), the basis for the XRechnung format.
What does “conformity” with the standard mean?
An invoice is only considered compliant with the standard if it contains all mandatory fields of EN 16931 and does not violate any rules. There are two ways it can be applied:
- Core Invoice User Specification (CIUS): A specific adaptation of the standard for a particular context (e.g., the XRechnung for German public authorities). A CIUS may narrow the standard (turn optional fields into mandatory fields), but it must never remove mandatory fields of the standard.
- Extensions: Extensions for specific industry requirements that go beyond the core model.
Mandatory fields according to EN 16931 (core model)
These data fields must be included in every standards-compliant e-invoice to be technically and legally valid.
| Required information | Business Term (BT ID) |
| Invoice number | BT-1 |
| Invoice date | BT-2 |
| Invoice type code | BT-3 |
| Currency | BT-5 |
| Seller name | BT-27 |
| Seller address | BG-5 |
| Seller tax number/VAT ID | BT-31 / BT-32 |
| Buyer name | BT-44 |
| Total of net amounts | BT-109 |
| Total invoice amount (gross) | BT-112 |
| Amount due | BT-115 |
Why is EN 16931 important for companies?
The Growth Opportunities Act makes EN 16931 the standard in the German B2B sector (between companies) as well. Since 2025, the rule has been: A “proper e-invoice” is legally defined as one that must comply with the EN 16931 standard.
In summary, this means: EN 16931 is the “vocabulary book” and the “grammar” of e-invoicing. It ensures that a computer in Germany can correctly interpret, verify, and post an invoice from Italy or France without human intervention.
Further information on the EN 16931 standard
Formally, yes, as it defines only a semantic data model. In practice, however, its application is currently tied to XML-based syntaxes, since only UBL 2.1 and UN/CEFACT CII are permitted. The technology neutrality relates to the semantics, not to the implementations currently approved.
Technical responsibility lies with CEN Technical Committee 434 (CEN/TC 434 – Electronic Invoicing). Changes are made via formal standardization procedures such as Amendments or Corrigenda. In addition, external code lists are updated regularly, which can have an immediate impact on practical compliance.
The Business Rules are a normative part of EN 16931. An invoice that violates a business rule is not standards-compliant—even if it is structurally correct. Compliance therefore always includes mathematical and logical consistency.
Yes. The standard ensures that all relevant information is present in a structured form and has been calculated with logical consistency. However, it does not replace a tax review. A formally compliant invoice may, for example, apply an incorrect tax rate or contain information that is substantively incorrect under tax law.
Compliance always refers to a specific published version of EN 16931, including the associated validation artifacts and code lists. If a code list is updated, an invoice that was previously valid may no longer be compliant in a later version. The decisive factor is therefore always the currently applicable version.
Areas of interpretation arise in particular with context-dependent mandatory fields, optional Business Terms, and the tax classification of certain business transactions. These leeways are one of the reasons for the existence of CIUS specifications, which specify the application framework more precisely.
The standard is regarded as the structural basis for further digitalization initiatives such as “VAT in the Digital Age.” Since it provides a uniform semantic model, it is suitable as a reference framework for possible transaction-based reporting systems or real-time reporting models within the EU.
Non-compliance may lead to rejection of the invoice, payment delays, breaches of statutory acceptance obligations, or tax risks. Since the standard is referenced by law, this is not merely a technical quality feature, but a compliance issue.
The standard is designed as a core model. It can be extended via CIUS and extensions, as long as the underlying semantic model is not changed or undermined. Interoperability takes precedence over individual customizations.
The stable identifier (e.g., BT-1, BT-112) enables unambiguous referencing in validation rules, technical documentation, and audit logs. This significantly facilitates traceability in audits, system implementations, and regulatory reviews.
It is both. Technically, it defines a structured data model with validation logic. From a regulatory perspective, it is referenced by European and national legislation. It is precisely this combination of standards engineering and legal anchoring that makes it a key element of digital invoicing regulation in Europe.
No, there are practical exceptions. Low-value invoices up to a gross amount of 250 euros, as well as travel tickets for passenger transport, do not necessarily have to comply with the structured EN 16931 standard. These can still be issued and received in the conventional form (e.g., as a PDF or paper receipt). This significantly simplifies the handling of everyday expenses such as fuel receipts or train tickets.
Sources:
- EU Official Journal: Directive 2014/55/EU
- CEN (European Committee for Standardization): EN 16931 standards series
- KoSIT (Coordination Office for IT Standards): XRechnung specification
