Is EN 16931 a file format?

No, and this is the most common misconception. The standard describes meanings: which fields exist, which are mandatory, how they relate. For the technical representation it points at two existing XML syntaxes, CII and UBL.

What do BT and BG mean?

BT stands for business term and names a single field — BT-1 is the invoice number. BG stands for business group and names a set of related fields, such as BG-4 for the seller. Validator messages speak almost entirely in these numbers.

What is the difference between a CIUS and an extension?

A CIUS may only restrict the core — make fields mandatory, narrow value ranges. An extension adds fields the core does not know. The CIUS stays interoperable across Europe; the extension does not.

Is validating against EN 16931 enough?

Only where the destination has no CIUS of its own. For an XRechnung it is not: it brings additional German rules that a document can fail while satisfying the European standard perfectly.

Does EN 16931 apply to invoices to consumers?

The standard itself targets no particular audience. The obligations that reference it, however, concern public administration and trade between businesses — not dealings with private individuals.

EN 16931: the standard behind XRechnung, ZUGFeRD and Peppol

A standard about meanings, not files

Most standards you meet in invoice processing describe a file: this is what the XML looks like, these are the element names, this is the order they come in. EN 16931 explicitly does not.

The standard describes a semantic data model: a list of the details that make up an invoice, each with its meaning, data type, cardinality, and whether it is mandatory. How those details get written into a file is left to two existing syntaxes — CII and UBL.

That sounds like a technicality, but it explains the entire format landscape: why XRechnung and ZUGFeRD carry the same fields although the files look nothing alike, and why one and the same invoice can be converted between them without loss.

BT and BG: the language of the standard

Every field in the standard has a number. This is not decoration — it is the shared language in which rule sets, error messages and manuals speak:

BT — business term, a single field. BT-1 invoice number · BT-2 issue date · BT-10 buyer reference · BT-31 seller VAT identifier
BG — business group, a set of related fields. BG-4 seller · BG-7 buyer · BG-16 payment instructions · BG-25 invoice line

When a validator reports that group BG-16 is missing, it does not say "the element cac:PaymentMeans is missing". It names the group, because the same rule must hold for CII and UBL — the element names differ, the BG number does not.

💡 The practical payoff: anyone who can find the BT number from an error message in their own data model has the fix in minutes. Anyone searching for the element name is searching in the wrong syntax.

Core, CIUS and extension

The standard describes a core — what holds Europe-wide. Around it two kinds of adaptation are foreseen, and the difference decides interoperability:

	may restrict	may add	readable Europe-wide
Core (EN 16931)	—	—	🟢 yes
CIUS	yes	no	🟢 yes
Extension	yes	yes	🔴 only by prior agreement

A CIUS (core invoice usage specification) tightens: it makes optional fields mandatory or narrows value ranges. Because it adds nothing, every CIUS document stays readable for any recipient who understands the core — they simply see an unusually completely filled-in document.

XRechnung is exactly that: the German CIUS. So is Peppol BIS Billing 3.0, and NLCIUS for the Netherlands.

An extension goes further and adds fields the core does not foresee. That is permitted, but it has a price: the recipient must know the extra fields, otherwise they are silently ignored. The data is not lost — it just does not arrive.

Why the standard alone is not enough

In practice an invoice is never checked against only EN 16931 but against a stack:

The core of the standard — rules like BR-11, requiring a country code in the buyer address.
The arithmetic rules of the standard — rules like BR-CO-10, reconciling line totals against the stated net amount.
The national CIUS — for XRechnung, rules like DE-R-001, making payment instructions (BG-16) mandatory.

All three must pass. A document can satisfy the European standard perfectly and fail the German CIUS — that is not a contradiction but the point of the construction.

The two syntaxes

For representation the standard permits two XML syntaxes, and both are equal:

CII from UN/CEFACT — the basis of ZUGFeRD and Factur-X
UBL from OASIS — the basis of Peppol BIS

XRechnung allows both. Anyone who models the standard properly internally — in BT fields rather than element names — can switch between them without touching business logic.

What to remember

EN 16931 is the layer everything else stands on. Understand it once and the format landscape reads as variation rather than sprawl:

One core, European, binding.
Two syntaxes, interchangeable, equivalent.
Many national CIUS, restricting but never extending.
Hybrid formats, embedding the core in a PDF rather than replacing it.

What comes after that — XRechnung, ZUGFeRD, Factur-X, Peppol BIS — are expressions of it, not competitors to it.