How e-invoice standards are structured: from the semantic model EN 16931 through syntax bindings (UBL, CII) to country-specific implementations.
E-invoicing is about more than just sending an XML file. Behind every e-invoice lies a carefully constructed system of agreements, ranging from what information an invoice should contain to how that information is structured. This article explains that structure step by step.
The foundation of every e-invoice is the semantic model. This model describes the meaning of the data on an invoice, independent of the technical format. Think of: supplier, buyer, invoice number, invoice date, amounts, VAT rates. It is about the content, not the form.
In Europe, this is defined in EN 16931, the European standard for electronic invoicing. EN 16931 specifies exactly which information elements an e-invoice must contain (mandatory) and which elements are optional. The result is an abstract, technology-neutral model that describes what an e-invoice is, without saying anything about how the information is technically stored.
EN 16931 was developed by CEN (the European standardisation body) on behalf of the European Commission and is legally anchored in EU Directive 2014/55/EU. Every e-invoice considered valid in Europe must comply with this semantic model.
A semantic model alone is not enough. Computers need a concrete file format to read and process data. That concrete format is called the syntax or syntax binding.
EN 16931 has two officially recognised syntaxes:
Both syntaxes express the same semantic information but in a different XML structure. An invoice in UBL looks technically different from an invoice in CII, yet contains the same data.
UBL is the most widely used syntax in Europe and the Peppol network. Most e-invoices sent via Peppol are UBL invoices. CII is mainly used in Germany and France, among others as the basis for Factur-X/ZUGFeRD.
A syntax like UBL describes the structure but says nothing about the business rules that apply within a specific network. That is why profiles exist that add validation rules on top of the syntax.
The most important profile for the Peppol network is Peppol BIS Billing 3.0. This profile takes UBL (or CII) as its basis and adds hundreds of business rules:
An invoice that complies with Peppol BIS Billing V3 automatically complies with EN 16931. The profile is a refinement, not a deviation.
You can read more about this profile in the article on Peppol BIS Billing V3.
Countries may further refine the European model for their own market. This is done through a CIUS (Core Invoice Usage Specification). A CIUS adds country-specific rules and requirements but may never conflict with the underlying EN 16931 model.
Well-known examples:
An invoice that complies with a CIUS automatically complies with Peppol BIS Billing and with EN 16931. The relationship is strictly hierarchical: each layer builds on the previous one.
While BIS Billing and the CIUS variants were designed for Europe, PINT (Peppol International Invoice) extends the reach to the rest of the world. PINT is a separate profile, also based on EN 16931, but with region-specific variants:
You can read more about PINT in the article on PINT.
All layers together form a pyramid, from abstract to concrete:
EN 16931 (semantic model: what belongs on an invoice?)
│
├── Syntax bindings (how is it stored?)
│ ├── UBL 2.1
│ └── CII (UN/CEFACT)
│
├── Profiles (which rules apply?)
│ ├── Peppol BIS Billing 3.0 (European Peppol profile)
│ └── PINT (international Peppol profile)
│ ├── PINT EU
│ ├── PINT A-NZ
│ ├── PINT Japan
│ └── ...
│
└── CIUS (country-specific implementations)
├── NLCIUS (Netherlands)
├── XRechnung (Germany)
├── Svefaktura (Sweden)
├── ebInterface (Austria)
└── France CIUS (France)
The top layer is the most abstract (meaning only), the bottom layer the most concrete (specific XML fields and validation rules for a given country).
Besides the pure XML standards, there are also hybrid formats that combine a visual PDF with machine-readable XML data in a single file. The technical principle is always the same: a PDF/A-3 document with an embedded XML attachment. The receiver can view the invoice visually (as a PDF) and at the same time process the data automatically (via the XML).
The best-known example is Factur-X/ZUGFeRD, which embeds CII XML and is widely used across Europe. In addition, ISDOC.PDF is the Czech variant that embeds its own national XML schema instead of CII. Both formats share the hybrid concept but differ in the embedded XML and the degree of EN 16931 compliance.
Hybrid formats are particularly practical during the transition to full e-invoicing: they serve as a bridge between the traditional PDF and the fully structured XML invoice. A comprehensive comparison, including the technical structure and processing complications, can be found in Hybrid invoice formats: PDF with embedded XML.
The table below brings together the most important e-invoice standards. This gives you an at-a-glance overview of how they relate to each other and to the European standard EN 16931.
EN 16931 forms the semantic foundation on which all other standards build. UBL and CII are the two officially recognised syntax bindings. The CIUS specifications (Peppol BIS, NLCIUS, XRechnung) tighten the model with additional restrictions or obligations, without changing the core model. ZUGFeRD/Factur-X combines a visual PDF with an embedded CII XML file. ISDOC is the Czech national format with its own hybrid variant. PINT is the successor to BIS for international Peppol invoicing, with region-specific variants for Australia, Japan, Singapore and others.
As an eConnect user, you do not need to manage this hierarchy yourself. The platform automatically transforms between all supported formats. Sending a UBL invoice to a receiver that expects XRechnung? The invoice is transformed. Receiving a CII invoice while your accounting system expects UBL? eConnect converts the document.
The standards hierarchy is what makes this possible: because all formats trace back to the same semantic model (EN 16931), lossless conversion between formats is technically feasible.
Tip: Want to learn more about a specific format? Check the articles in the Formats category, where each format is described with its characteristics.
Download sample files