If you have started looking into e-invoicing in Switzerland or across Europe, you will quickly run into a reference to EN 16931. It comes up in conversations about PEPPOL, about the EU VAT Directive, and about why different countries can exchange invoices without agreeing on a single file format. What it actually is tends to get glossed over.
EN 16931 is a European standard — published in 2017, updated since — that defines the semantic model for a core electronic invoice. Not a file format, not a technical protocol. A semantic model: a structured list of invoice concepts and the rules that govern them.
What a semantic model actually means
A semantic model defines what information an invoice must carry, without specifying how that information must be encoded. EN 16931 lists roughly 160 individual data elements — buyer name, supplier IBAN, VAT category, line item description, and so on. It also defines business rules: invoice totals must match the sum of their lines, VAT amounts must be consistent with the stated rate and taxable base, and so on.
What it does not define is whether those elements should be encoded as UBL XML, UN/CEFACT CII XML, or any other syntax. That separation is deliberate. Two countries can both comply with EN 16931 while using different file formats, as long as both formats can represent the same semantic elements. A mapping layer handles the translation between them.
This is the foundation of PEPPOL's approach. PEPPOL BIS Billing 3.0 is an implementation of EN 16931 in both UBL 2.1 and UN/CEFACT CII. A Swiss supplier sending in UBL and a German buyer receiving in CII are working from the same semantic model — which is what makes the exchange technically possible.
Why EN 16931 was created
Before 2014, there were more than twenty active national e-invoice standards across EU member states. A German supplier invoicing a French buyer had to understand both countries' formats. Cross-border B2G e-invoicing was effectively impossible without bilateral agreements or expensive middleware.
The EU's response was Directive 2014/55/EU, which required all EU public administrations to accept electronic invoices and defined what "electronic invoice" meant. EN 16931 was the technical standard built to support that directive. By establishing a common semantic core, it gave every EU member state a shared reference point — even where national formats add local extensions on top.
Switzerland is not bound by EU directives, but EN 16931 has still shaped the Swiss e-invoicing landscape. The SwissDIGIN profile extends PEPPOL BIS Billing 3.0 — itself an EN 16931 implementation — with Swiss-specific elements like the QR-IBAN and the Swiss UID. The semantic core is shared; the Swiss layer sits on top.
How the 160-odd data elements are organised
EN 16931 groups its data elements into logical sections:
Invoice header. Fields that apply to the whole document: invoice number, issue date, currency, buyer and seller names and identifiers, payment means, payment terms.
Line items. Each line carries a description, quantity, unit price, line amount, and VAT category. Line-level allowances and charges are also part of the model.
VAT breakdown. A mandatory section that groups lines by VAT category and shows the taxable amount, rate, and calculated VAT for each group. If an invoice has lines at multiple rates — common in hospitality or mixed-supply situations — each rate gets its own row.
Document-level allowances and charges. Discounts or surcharges that apply to the whole invoice rather than specific lines.
Totals. Net amount, total VAT, gross amount, prepaid amount, amount due for payment.
Each element carries a cardinality (mandatory, conditional, or optional), a data type, and a plain-language definition. The standard also specifies around 120 business rules written as logical assertions. Schematron validation is the standard mechanism for checking an invoice against those rules automatically.
EN 16931 and VAT
One area where EN 16931 goes into significant detail is VAT handling. The standard defines a specific set of tax category codes — S for standard rate, Z for zero rate, E for exempt, AE for reverse charge, and several others. Using the correct code matters because downstream systems rely on it to determine how to account for the tax.
Reverse charge is a useful example. When a Swiss company sells services to a German business, the German buyer accounts for the VAT themselves. The invoice should carry the AE code, no VAT amount in the totals, and a legal reference explaining why tax was not charged. EN 16931 defines exactly which fields carry which values in this scenario. Getting it wrong can cause the buyer's system to reject the invoice or mispost the accounting entry. The tax category codes post goes through each code with practical examples.
National extensions
EN 16931 covers only the common core. It does not know about QR-IBANs, Swiss UID numbers, or buyer reference fields specific to a national public procurement system. National extensions fill that gap.
In Germany, XRechnung adds a buyer reference field that is mandatory for public sector invoices. In Switzerland, the SwissDIGIN profile adds the QR-IBAN as an alternative payment identifier and the Swiss-format VAT number. These extensions must not contradict the EN 16931 semantic model — they can add new elements, but they cannot redefine existing ones.
If you are building an invoicing pipeline that needs to reach multiple countries, the practical approach is to implement EN 16931 first, then layer country-specific extensions on top. Most enterprise ERP systems that support e-invoicing handle this through a core mapping layer combined with country-specific configuration.
What it means for Swiss businesses in practice
For most Swiss finance teams, EN 16931 is something you benefit from without needing to read directly. If your e-invoicing software is PEPPOL-certified or eBill-compliant, it already implements the relevant parts of the standard. The invoices you send carry the right semantic elements; the invoices you receive are parseable regardless of which syntax the sender used.
Where the standard becomes directly relevant is when you are evaluating software, building a custom integration, or trying to understand why a field that seems optional causes a rejection. In those cases, EN 16931 is the authoritative reference — more reliable than any vendor's documentation, because it defines the logic that all conformant implementations must follow.
The full text is available through national standards bodies. Switzerland's version is published by SNV (Schweizerische Normen-Vereinigung) under the reference SN EN 16931.