What's behind EN 16931? X-Invoice and ZUGFeRD explained for SMEs

What's behind EN 16931? X-Invoice & ZUGFeRD explained

Since the introduction of mandatory e-invoicing, many companies are dealing with structured invoice formats for the first time. A seemingly simple question quickly arises: XRechnung or ZUGFeRD?

In der Praxis zeigt sich jedoch, dass die eigentlichen Probleme selten durch das Format selbst entstehen, sondern durch das gemeinsame Regelwerk dahinter – die europäische Norm EN 16931.

Sie suchen zunächst einen kompakten Überblick zu den Formaten, Begriffen und gesetzlichen Rahmenbedingungen? Lesen Sie unseren Artikel E-invoicing obligation: X-Invoice and ZUGFeRD explained simply .

What is EN 16931?

EN 16931 is a European standard that defines a uniform data model for electronic invoices. In short, it specifies which fields an e-invoice must contain. Both XRechnung and ZUGFeRD are technical implementations of this standard.

Typical EN-16931 errors in practice

EN 16931 defines approximately 60 data fields, some of which are mandatory. In practice, validation errors often arise from a few recurring mandatory fields that are either not filled in or are filled with structural errors. Three frequently affected mandatory fields are:

BT-9 – Due Date

The due date is mandatory as soon as payment terms are specified. However, many accounting systems do not automatically populate this field, even when a payment deadline is indicated. This leads to validation errors.

BT-23 – Business Process Identifier

The business process identifier is mandatory for invoices to public sector clients (B2G). In the B2B sector, this field is often ignored because the error is only noticed by the recipient.

BG-23 – Tax Breakdown

A separate tax group must be specified for each tax rate. Invoices with mixed tax rates therefore often lead to validation errors if this structure is not implemented correctly.

Important: Selbst wenn eine Buchhaltungssoftware X-Rechnung oder ZUGFeRD unterstützt, bedeutet das nicht automatisch, dass jede erzeugte Rechnung vollständig EN-16931-konform ist. Fehlerhafte oder unvollständige Rechnungen entstehen zum Beispiel durch falsche Konfiguration, fehlende Pflichtfelder oder fehlerhafte Steuerkennzeichen. Eine technische Validierung vor dem produktiven Einsatz spart spätere Rückfragen oder abgelehnte Rechnungen.

X-Invoice: Routing ID, Syntax Selection and Validation

The X-invoice is the mandatory format for invoices to public sector clients in Germany. Technically, it is a structured XML file that is processed entirely automatically.

What is the routing ID and when is it required?

The routing ID is an agency-specific identifier that uniquely identifies the invoice recipient within the public administration. It is usually transmitted in the BT-10 (Buyer reference) field and is mandatory for invoices to public contracting authorities.

Typical format: [Prefix]-[Digits]-[Check digit]

Example: 991-12345678-06

If the routing ID is missing or incorrectly formatted, the invoice is automatically rejected without manual intervention. This is one of the most common reasons why X-invoices are returned to government agencies.

UBL or CII – which syntax is used?

X-Rechnung supports two XML syntaxes:

  1. UBL (Universal Business Language)

  2. UN/CEFACT CII

Both versions comply with EN-16931, but differ in their technical design. Some authorities and receiving systems prefer one version over the other. Therefore, it’s advisable to briefly check with the client before setting it up in the accounting software.

Validation with the KoSIT validator

The official validator of the Coordination Office for IT Standards (KoSIT) checks X-invoices free of charge against the applicable Schematron rules.

The tool identifies missing required fields, structural errors, and validation problems. Test validation is particularly recommended after software updates or for new clients or customers.

ZUGFeRD profiles compared

ZUGFeRD combines a human-readable PDF with an embedded structured XML dataset. The structure of the XML data also conforms to the EN 16931 standard.

What ZUGFeRD profiles are there and how do they differ?

ZUGFeRD exists in five profiles.

MINIMUM Contains only a greatly reduced dataset with core data.

BASIC WL

Extended data structure, but not yet fully compliant with EN-16931.

BASIC Contains key invoice information, but does not fully meet the requirements of the EN 16931 standard.

EN 16931 Full compliance with standards and suitable for most B2B applications.

EXTENDED Additional fields for complex business transactions.

Which ZUGFeRD profile makes sense for companies?

For most companies, the EN 16931 profile is the safe choice. It meets the legal requirements from 2027 onwards and is well supported by common accounting software.

**Please note: **ZUGFeRD 2.x is not backwards compatible with version 1.0. Companies with older systems should therefore check which version is supported.

Validation of ZUGFeRD invoices

The Mustang Validator (open source) is frequently used to check ZUGFeRD invoices. It checks the PDF/A-3 document, the structure of the embedded XML data set, and compliance with the EN-16931 rules.

X-Invoice vs. ZUGFeRD: Technical Comparison

criteria X-calculation ZUGFeRD
File format Pure XML (UBL or CII) PDF/A-3 with embedded XML
compliant with EN 16931 Yes Yes (from profile EN 16931)
Human-readable No (only with viewer) Yes (PDF directly readable)
Mandatory for invoices to public authorities (B2G) Yes Accepted
Routing ID required at federal agencies Not necessarily
Validation tool KoSIT Validator (official) Mustang Validator (Open Source)
Implementation costs Medium to high Low to medium

When is which e-invoice format practical?

Invoices to authorities

For invoices to public sector clients, X-Rechnung is mandatory. Companies should ensure that their accounting software correctly processes the routing ID, correctly fills in all mandatory EN-16931 fields, and can generate valid X-Rechnung invoices.

Invoices to businesses (B2B)

In the B2B sector, ZUGFeRD in the EN 16931 profile is often the most pragmatic entry point, because recipients can read the PDF directly and at the same time structured data is available for automated processing.

When are both formats needed?

Many companies need to invoice both government agencies and other businesses. In this case, a software solution that supports both formats is worthwhile. The technical basis is identical; both are based on the EN 16931 standard.

Conclusion: EN 16931 should be understood as a common foundation.

X-Rechnung und ZUGFeRD werden häufig als konkurrierende Formate dargestellt. Technisch betrachtet stimmt das jedoch nicht. Beide basieren auf derselben europäischen Norm EN 16931. Die Norm definiert, welche Daten eine elektronische Rechnung enthalten muss und wie diese strukturiert übermittelt werden. X-Rechnung und ZUGFeRD setzen diese Vorgaben lediglich auf unterschiedliche Weise technisch um.

For companies, the real challenge usually lies not in the chosen format, but in generating the invoice data correctly.

In the long term, EN 16931 will increasingly become the technical standard for electronic invoices in Europe. Companies therefore benefit from not only focusing on individual formats, but also on the underlying standard and its implications. Importance for data quality To understand. Because anyone who knows EN 16931 can confidently use both X-Rechnung and ZUGFeRD and avoids typical errors right from the invoice creation stage.

Software solutions like GetMyInvoices help companies automatically retrieve invoices from portals, email inboxes, and online services and transfer them in a structured manner to accounting systems. This also makes it easier to integrate requirements related to electronic invoice formats into existing processes.