Skip to main content

EN 16931 explained

Every EU e-invoicing format you will meet, ZUGFeRD, Factur-X, XRechnung, Peppol BIS, traces back to one document: EN 16931. Understanding it makes the rest of the landscape click into place, because the others are all refinements or carriers of it.

What EN 16931 is​

EN 16931 is a European Standard that defines the semantic data model of the core elements of an electronic invoice. In plain terms, it is the agreed list of what an invoice contains and what each piece means: seller, buyer, invoice number, issue date, line items, VAT categories and rates, allowances, totals, payment terms, and so on.

It came out of EU Directive 2014/55/EU, whose goal was interoperability: a public body in one member state should be able to receive and process an invoice from a supplier in another without a bespoke integration for every trading partner. One shared model makes that possible. The standard is maintained by the European Committee for Standardization, technical committee CEN/TC 434. The current edition is EN 16931-1:2026, revised to align with the EU's ViDA (VAT in the Digital Age) initiative.

Crucially, EN 16931 defines the meaning of the data, not the file format. It does not say whether the invoice is written in one XML dialect or another. That separation is the key to everything below.

The core invoice model​

The model is built from business terms (individual fields, such as the invoice number or a line item's net amount) organized into business groups (for example, the seller's postal address groups several terms together). Each term has an identifier, a defined meaning, and a cardinality that says whether it is mandatory and how often it can appear.

On top of the fields sit business rules: validation constraints that a conformant invoice must satisfy. For instance, the sum of the line net amounts must equal the invoice total net amount, and if a VAT breakdown claims a rate, the invoice must actually carry that category. These rules are what a validator checks, and they are why a file can be well-formed XML yet still fail EN 16931 conformance.

The two syntaxes: CII and UBL​

The same core model can be written in two XML languages, and both comply with EN 16931:

  • UN/CEFACT CII (Cross Industry Invoice), from the UN body for trade standards.
  • OASIS UBL 2.1 (Universal Business Language).

They carry the same information with different element names and structures. A tool or a recipient generally supports one or the other (or converts between them). This is the single most common source of confusion in practice: two invoices can both be perfectly valid EN 16931 documents and still be unreadable to each other's software, because one is CII and the other is UBL.

Which syntax you meet depends on the format:

  • ZUGFeRD and Factur-X embed CII in a PDF.
  • Peppol BIS Billing uses UBL.
  • XRechnung allows either CII or UBL.

CIUS and extensions: how countries specialize the standard​

EN 16931 is deliberately broad, so most real-world formats do not use it raw. They apply a CIUS or an extension. The distinction is precise and worth knowing:

  • A CIUS (Core Invoice Usage Specification) may only restrict the core: mark unused fields as not applicable, make an optional field mandatory, tighten a value's format, or remove code values. It cannot add anything new. An invoice built to a CIUS is therefore still a fully valid EN 16931 invoice. XRechnung and Peppol BIS Billing are CIUS.
  • An extension may do everything a CIUS does and add new business terms beyond the core. An extended invoice is no longer conformant with the bare core, so a recipient who accepts extensions must also accept the plain core. The EXTENDED profile of ZUGFeRD / Factur-X is an extension in this sense.

This is why you can say XRechnung "is EN 16931" (it only narrows the core) but must be more careful with EXTENDED profiles (they go beyond it).

How it all connects​

LayerExampleRole
The standardEN 16931Defines what an invoice means
The syntaxCII, UBLTwo XML ways to write it down
A CIUSXRechnung, Peppol BIS BillingRestricts the core for a country or network
An extensionZUGFeRD / Factur-X EXTENDEDAdds fields beyond the core
A carrierZUGFeRD / Factur-X hybrid PDFBundles the XML with a readable PDF
A networkPeppolDelivers the document

For the full breakdown of how each named format relates, see ZUGFeRD vs Factur-X vs XRechnung vs Peppol.

Where PolyDoc fits​

When you generate an e-invoice with PolyDoc using the en16931 profile, you get invoice data encoded as EN 16931 CII XML, embedded in a PDF/A-3 (a ZUGFeRD / Factur-X hybrid). That is the recommended, most interoperable choice for standard EU B2B invoicing, and it is why the generate guide uses it as the default.

PolyDoc is an HTML-to-PDF product, and this is its e-invoicing mode. If e-invoicing is your main requirement, our dedicated e-invoicing product beliq is usually the better fit: it also emits the UBL syntax and other usage specifications (standalone XRechnung, Peppol BIS), and runs full EN 16931 business-rule validation on invoice data.

Next steps​