EN 16931 Explained: How It Shapes Germany E-Invoicing

The request for German businesses to exchange e-invoices does not merely mean “exchanging an XML file”. Such an invoice must be machine-readable and comply with EN 16931, which is the standard defining the content of an electronic invoice and its structure. All German invoice formats used in Germany e-Invoicing, ranging from XRechnung to ZUGFeRD, are based on this standard.

This is why the EN 16931 standard is the very first thing that a company’s finance, tax and IT departments must understand prior to implementing an ERP integration or selecting a provider. This page describes what the standard is about, how it relates to XRechnung and ZUGFeRD, where invoices usually fail validation, and what needs to be checked before going live.

Role of EN 16931 in Germany E-Invoicing

The EN 16931 standard was created by CEN in line with Directive 2014/55/EU as part of the development of the European e-invoicing standard. It was meant for public procurement, but it became the common reference for all B2B e-invoicing in the EU. EN 16931 is the basis of Germany’s e-invoice definition, according to which an e-invoice is a structured and electronically processable invoice in compliance with EN 16931.

The standard fulfils three functions:

• The standard provides the definition of meaning by listing all information elements that an invoice may contain in a semantic data model such as seller information, buyer information, lines, VAT breakdown and totals;
• The standard restricts the technical representation by referencing the possible syntaxes for representing the semantic data model in XML;
• The standard sets the rules for the data by defining the list of business rules for determining the validity and completeness of the data.

Understanding the EN 16931 Data Model

At the heart of the standard lies the semantic model. This describes invoice contents independently of file format, and that’s how interoperability is achieved for invoices from systems that don’t even know each other.

Business Terms and Business Groups

The model consists of business terms (BT), individual data items, and business groups (BG), collections of related terms. They each have a numeric code. BT-1 stands for invoice number, BT-2 is the issuance date, while BT-5 refers to invoice currency. BG-4 covers the seller information, BG-7 the buyer information, BG-23 the VAT summary, and BG-25 the invoice line item.

Their codes are useful not only for documentation purposes but also because they are used in validation errors, where a rejection mentioning “BT-10” immediately points out which field needs correction.

Required Identifiers and Business Data

The model contains the identifiers that will be required by the receiving party to read the invoice in an automated way:

• Invoice number, date of creation, type code, and currency
• Seller and buyer names, addresses, and identifiers, including VAT identifier of the seller (BT-31)
• Buyer reference (BT-10), which is crucial for German public sector buyers
• Means of payment and payment account information
• Line items’ quantities, units, prices, and descriptions
• VAT classification, VAT percentage, and reasons for exemptions

Mandatory, Conditional and Optional Information

Every item has a cardinality, denoted by “1..1”, meaning one is mandatory, “0..1”, indicating that it is optional, and “1..n”, showing that at least one is required, while allowing repetitions. Certain data items are conditional; for example, the reason for exemption becomes compulsory when the VAT Category is either “Exempt” or “Reverse Charge”. EN 16931 is deliberately designed to be a core model, thus not including all industry-specific elements.

EN 16931 Syntax and E-Invoice Formats

Does EN 16931 Define a Single XML Format?

No. The standard describes the content model, not one file structure. According to the European Commission, there are two different syntaxes that may be used to carry the content model: UBL 2.1 and UN/CEFACT Cross Industry Invoice (CII). Both syntaxes can express the semantic model, and binding rules ensure that every business term corresponds to one element of the syntax.

That is why being “EN 16931 compliant” does not specify any file format.

XRechnung and EN 16931

XRechnung is the German implementation of the standard, classified as a CIUS (Core Invoice Usage Specification). A CIUS restricts the standard by turning certain optional fields into required fields and providing national rules, but it does not introduce any new content. In practice, XRechnung EN 16931 alignment means that every XRechnung is also a valid EN 16931 invoice. XRechnung may be issued in either UBL or CII format, and it was developed to allow invoicing the German public administration, for which a buyer reference, such as the Leitweg-ID, is necessary.

ZUGFeRD and EN 16931

ZUGFeRD (in line with French Factur-X) is more of a blend. It is a PDF/A-3 document with an embedded CII XML file, allowing users to view the PDF while systems process the XML. Its profiles vary from MINIMUM and BASIC WL to BASIC, EN 16931 and EXTENDED. The only profiles which fulfill the full EN 16931 content, i.e. the EN 16931 profile and, if used properly, the EXTENDED profile, match the German e-invoicing standard. ZUGFeRD EN 16931 compliance therefore depends on the profile chosen. The profiles MINIMUM and BASIC WL lack line-level information, hence don’t fit.

The choice of one over another is a completely different story, as it is explained better in the comparison guide of ClearTax. The following table gives you an overview of each standard’s relation to EN 16931.

Creating and Mapping Invoice Data to EN 16931

Here is where most of the compliance work resides. The ERP and billing systems typically do not maintain the data in the format required by the standard; therefore, all invoice fields must be mapped to business terms. Good mapping practice will include:

• Source-to-term mapping. Map all ERP fields to their respective BT or BG and log transformation rules.
• Master data quality. Populate VAT ID, addresses, bank information and buyer reference at the customer and supplier levels, and not at the invoice level.
• Code lists. Map internal fields to appropriate standard codes for units of measure, currencies, country codes, means of payment and VAT categories.
• Tax logic. Define the VAT category per invoice line, including cases of exempt, zero-rated and reverse charge supplies, and provide the reason for such exemption.
• Calculation behaviour. Align rounding rules and computation of line totals, document totals and VAT totals to those defined in the standard.
• Attachments and references. Decide how purchase order numbers, contract references and documents will be transferred.

Groups that approach the process as a simple field matching process are likely to identify Germany e-Invoicing errors only once rejection letters start flowing. By treating it as a data governance activity, many of these issues can be avoided.

EN 16931 Validation and Common Invoice Errors

Invoice validation occurs in layers, where each layer can detect a different kind of error, and an invoice may pass one level but fail another.

Semantic Validation

This validates the consistency between the content of the invoice and its data model. The validation checks whether all mandatory elements are there, identifiers have been used appropriately, and conditional elements occur where necessary. This is the level nearest to the actual standard.

Syntax and Schema Validation

This level performs the XML validation against the standard’s schema (UBL/CII). Validation catches issues such as wrong ordering of elements, incorrect data types, invalid dates and namespace issues. An invoice that fails the syntax/schema validation never reaches the business rules at all.

Business Rule Validation

There are business rules that come with the standard and are implemented in Schematron. The rules are identified by BR-xx for core rules, BR-CO-xx for calculation and consistency rules and specific VAT rules for categories. In addition, Germany adds BR-DE rules for XRechnung. The KoSIT validator and similar tools execute all these levels and output the failing rule and the associated element.

Common EN 16931 Validation Failures

• Missing Buyer Reference (BT-10). A common rejection seen on invoices sent to public bodies, as per BR-DE-15, a German rule.
• Incomplete contact details of Seller. XRechnung needs contact information, which is missing from many ERP export files.
• Totals do not match. The total amount should equal the net total plus VAT (rule BR-CO-15). Rounding is usually the reason for this.
• VAT Category and Rate mismatch. Standard rate category with zero rate or vice versa.
• Missing reason for exemption. Exempt/reverse charge categories require a reason code or text.
• Invalid codes. Codes for unit, country, currency or payment means that are not in the allowed list.
• Incorrect ZUGFeRD Profile. MINIMUM or BASIC WL used for a document that requires the German Definition.

From EN 16931 Compliance to Germany E-Invoicing Readiness

Conformity with EN 16931 is necessary but not sufficient. Being prepared for Germany implies preparation for the whole chain of processes, which means that every company should be prepared to receive structured invoices, whereas obligations to issue them are phased in until 2027 for most taxpayers and become obligatory for all businesses from 2028. Also, teams should take into account how invoices are transmitted and archived, because archiving rules apply to the structured file, as well as to the approval and accounting process for received invoices.

It is better to follow this sequence: decide on the format you issue and accept, create and test mapping, validate it according to the standard’s requirements and German requirements, and then integrate transmission and archiving.

Pre-Production Checks for EN 16931 E-Invoices

Prior to going live, test the Germany e-Invoicing solution with real-world sample invoices not just with ideal test data:

• Format and profile are validated for each type of customer (public sector, B2B, with or without readable copy).
• All mandatory terms are filled in from source data, including BT-10 if necessary.
• VAT categories, tax rates and tax exemption reasons are tested in domestic, exempt, reverse charge and EU cases.
• Credit notes, corrections, multiline invoices and discounts or charges are validated.
• Invoices pass validation with the existing schema, EN 16931 and German rules.
• Rounding is tested with high volume invoices and those with multiple VAT rates.
• Receiving processes will be able to read and process XRechnung and ZUGFeRD invoices.
• Archiving preserves the original structured invoice in an unchanged and readable format.
• Rule and format changes have owners, because both the standard and German specifications are versioned.

Conclusion 

EN 16931 compliance is the foundation of Germany’s e-Invoicing framework, but achieving it requires more than generating a structured invoice. Businesses must ensure accurate data mapping, correct VAT treatment, seamless ERP integration, and consistent invoice validation.  

Cygnet helps businesses simplify this transition with its e-invoicing capabilities, supporting structured invoice processing, compliance requirements, and integration into existing business workflows. With the right technology and a well-planned implementation approach, businesses can reduce validation errors, improve invoice accuracy, and prepare for Germany’s evolving e-Invoicing requirements. With Cygnet, businesses can move towards a more reliable, efficient, and compliance-ready e-invoicing process.

Author

Kesha Shah

General Manager - Products Marketing

Kesha Kumar leads the global products marketing team at Cygnet.One, where she turns the complexity of tax and finance transformation into stories that resonate with the people who matter most. She’s the strategic force behind the brand’s presence across India, the GCC, Southeast Asia, and Europe, translating dense subjects like e-Invoicing mandates, digital engineering, and enterprise AI into narratives that inform and drive action. With expertise spanning tax and finance transformation, quality, enterprise applications, and data and AI, Kesha blends sharp strategic thinking with a marketer’s instinct for what truly connects. At Cygnet.One, she does more than build campaigns and content; she shapes the conversations that help enterprises navigate compliance with clarity and confidence, propelling the brand to the forefront of the industry along the way.