EN 16931 explained: the European e-invoicing standard in plain terms

EN 16931 is the European standard that defines what a compliant e-invoice must contain. If you send invoices to German public authorities, or to buyers in any EU country that has transposed the e-invoicing directive, the rules in EN 16931 are the baseline your invoice has to meet. This post explains what the standard covers, what it leaves to each country, and how it connects to the formats you actually send, like XRechnung and ZUGFeRD.

What EN 16931 actually defines

EN 16931 is a semantic standard. It defines the content of an electronic invoice: which fields must be present, what values they can carry, and the rules those values have to satisfy. It does not define the file format. The same invoice data can be serialized as CII XML or UBL XML, and both are valid EN 16931 documents as long as the content matches the standard.

This separation between content and format is the part that confuses people. EN 16931 is not a file you open. It is a rulebook that says what an e-invoice has to contain. The file you send, whether that is a XRechnung XML or a ZUGFeRD PDF, is one serialization of that content.

The building blocks: BT, BG, and BR

EN 16931 organizes invoice data into three kinds of elements:

• A BT (Business Term) is a single field. BT-1 is the invoice number, BT-2 is the issue date, BT-32 is the seller's tax registration identifier. Every piece of data the standard recognizes has a stable BT code.
• A BG (Business Group) is a container that holds related BTs. BG-32 is the invoice line group, which holds the line description, quantity, and price for each line item.
• A BR (Business Rule) is a validation rule the invoice must pass. BR-1 requires an invoice number. BR-2 requires an issue date. The BRs are the checks a compliant invoice has to satisfy.

A compliant EN 16931 invoice carries every required BT, groups them into the right BGs, and passes every BR.

What EN 16931 does not define

EN 16931 stops at the semantic content. It leaves several things to national or sector customizations:

• The XML syntax. The standard allows CII and UBL. A country or a recipient system picks one.
• Country-specific rules. A CIUS (Customization) narrows EN 16931 with extra required fields and stricter rules for a specific country, region, or industry.
• The delivery container. XRechnung is a standalone XML file. ZUGFeRD ships the same XML inside a PDF/A-3 so a person can read it and a machine can process it.

This is why you hear EN 16931, XRechnung, and ZUGFeRD used together. EN 16931 is the shared content model. XRechnung and ZUGFeRD are the German formats that deliver that content to a recipient.

How XRechnung and ZUGFeRD build on EN 16931

XRechnung is the German public-sector CIUS of EN 16931. It takes the EN 16931 data model and adds German rules on top. The most visible addition is the Leitweg-ID, a buyer reference that routes the invoice to the correct recipient system. The BR-DE-15 rule requires it on every XRechnung invoice to a German federal authority.

ZUGFeRD takes the EN 16931 data model and ships it as a PDF/A-3 with the CII XML embedded inside. ZUGFeRD and XRechnung share the same underlying data. The difference is the container: a readable PDF for ZUGFeRD, a bare XML file for XRechnung.

Every XRechnung invoice conforms to EN 16931. The reverse is not true. An EN 16931 invoice is only a valid XRechnung invoice if it also satisfies the German rules the CIUS adds on top.

Who has to meet EN 16931

The EU's e-invoicing directive requires public-sector buyers across member states to accept structured e-invoices. EN 16931 is the reference standard those invoices are measured against. Each country transposes the directive into national law and publishes its own CIUS.

In Germany, the public-sector format is XRechnung. For B2B invoices, Germany's growing e-invoicing mandate is built on the same EN 16931 foundation. Even where XRechnung itself is not the required format, the data model and rules it codifies are the reference point German e-invoicing compliance is measured against.

How compliance is checked

A compliant EN 16931 invoice has to pass two layers of validation:

• An XSD schema check confirms the XML is well-formed and the elements are in the right structure.
• A Schematron rule set encodes the BRs and the CIUS-specific rules. This is where the business rules are enforced, because XSD alone cannot express them.

For XRechnung, both layers are published by KoSIT, the German federal IT standards office. A XRechnung invoice must pass the KoSIT XSD and Schematron checks to be considered valid. The recipient's system runs the same checks on receipt, so an invoice that fails validation will be rejected.

How InvoiceSpec handles EN 16931

InvoiceSpec generates invoices from a single canonical JSON request. The engine maps the JSON to CII XML, computes the totals, and runs the KoSIT XSD and Schematron validation before returning the file. You send one payload and get back an invoice that passes the same validation the recipient's system will run.

You can generate XRechnung, ZUGFeRD, or a plain EN 16931 document from the same request by changing the config object. The engine applies the right CIUS rules for the format you select.

Frequently asked questions

Is EN 16931 the same as XRechnung?

No. EN 16931 is the European standard. XRechnung is the German customization of it. Every XRechnung invoice conforms to EN 16931, but an EN 16931 invoice is only a valid XRechnung invoice if it also satisfies the German rules XRechnung adds on top.

Does EN 16931 require XML?

EN 16931 is syntax-agnostic. It defines the content of the invoice, not the file format. The content can be serialized as CII XML or UBL XML. In practice, every delivery format in use today carries that content as XML, either as a standalone file or embedded inside a PDF.

Do I need EN 16931 for B2B invoices?

In Germany, the growing B2B e-invoicing mandate is built on the EN 16931 data model. Even where the required format is XRechnung or ZUGFeRD rather than a plain EN 16931 document, the rules your invoice has to satisfy trace back to EN 16931.

Start issuing compliant e-invoices

You can generate your first EN 16931-compliant invoice in minutes. Create a free account and send a valid invoice with one API call, or try the free XRechnung Generator with no signup. InvoiceSpec handles the EN 16931 rules, the German CIUS additions, and the KoSIT validation so you do not maintain that logic in-house.

Start a free trial or read the API reference to generate compliant invoices programmatically.