The Standard Behind Every EU E-Invoice
If you've looked into e-invoicing in Europe, you've probably seen "EN 16931" mentioned everywhere — in regulations, in software descriptions, in compliance checklists. But most explanations assume you already know what it is. This article explains it from the ground up.
EN 16931 is a European standard that defines what data an electronic invoice must contain. It doesn't define how the invoice looks visually. It doesn't specify what software you use. It defines the data model — the specific set of information fields that make an e-invoice valid and interoperable across the entire EU.
Think of it as a shared vocabulary. Whether you're a freelancer in Berlin, a small business in Lyon, or a supplier to the Dutch government, EN 16931 ensures that the invoices you send can be understood and processed by any compliant system on the other end.
Why Does This Standard Exist?
Before EN 16931, every EU country — and often individual industries within countries — had their own invoice formats. A German invoice didn't look like an Italian one at the data level. Cross-border invoicing meant manual data re-entry, format conversion, and constant compatibility issues.
The European Commission addressed this by mandating a single semantic standard for e-invoices under EU Directive 2014/55/EU. The standard was developed by CEN (the European Committee for Standardization) and published in 2017. Its full title is:
EN 16931-1:2017 — Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic invoice
The goal was straightforward: define one data model that all EU member states accept, so that an e-invoice created in any country can be processed in any other country without modification.
What EN 16931 Actually Defines
EN 16931 is a semantic data model. That means it defines the meaning and structure of invoice data — the fields, their relationships, and the business rules governing them. It does not define the visual layout or the technical file format.
Here's what the standard covers:
Document-Level Fields
Every compliant invoice must include:
- Invoice number — unique within the seller's system
- Issue date — when the invoice was created
- Invoice type code — 380 for a standard invoice, 381 for a credit note, and others for specific scenarios
- Currency code — the ISO 4217 code (EUR, USD, GBP, etc.)
- Due date — when payment is expected (if applicable)
- Buyer reference — a reference the buyer uses to identify the transaction (such as a purchase order number)
Seller Information
The business issuing the invoice must provide:
- Legal name
- Postal address including country code
- At least one tax identifier (VAT number for EU businesses)
- Electronic address (typically email, identified with a scheme code)
- Business registration number with the correct ISO 6523 scheme ID for the country
Buyer Information
The client or customer must be identified with:
- Legal name
- Postal address including country code
- VAT number (required for B2B within the EU)
- Electronic address
Line Items
Each goods or service entry must include:
- Description
- Quantity and unit of measure (using UN/ECE Recommendation 20 codes — "HUR" for hours, "DAY" for days, "C62" for units)
- Unit price (net of tax)
- Line total
- VAT rate and VAT category code
Tax Summary
A breakdown of tax across all line items:
- Taxable base amount per VAT rate
- Tax amount per VAT rate
- VAT category code: "S" for standard, "E" for exempt, "AE" for reverse charge, "Z" for zero-rate
- The applicable VAT rate percentage
Totals
- Sum of all line net amounts
- Total tax amount
- Invoice total including tax
- Amount due for payment
Payment Information
- Payment means code (30 for bank transfer, 58 for SEPA credit transfer, 59 for SEPA direct debit)
- Bank account details (IBAN, optionally BIC)
- Payment terms or due date
EN 16931 vs Factur-X vs ZUGFeRD vs UBL vs Peppol
This is where confusion usually starts. Here's how everything fits together:
EN 16931 is the abstract data model. It says what data must be present but doesn't specify the file format.
CII (Cross Industry Invoice) and UBL (Universal Business Language) are the two XML syntaxes that EN 16931 can be expressed in. They're different technical formats that carry the same data. The standard officially supports both.
Factur-X / ZUGFeRD uses the CII syntax. It takes the XML and embeds it inside a PDF/A-3 document, creating a hybrid invoice.
Peppol BIS Billing 3.0 primarily uses the UBL syntax. It sends the XML through the Peppol delivery network without a PDF wrapper.
XRechnung is Germany's national standard for government invoicing. It uses UBL syntax and adds some German-specific business rules on top of EN 16931.
So the hierarchy is:
- EN 16931 — the data model (what fields to include)
- CII or UBL — the XML syntax (how to structure the file)
- Factur-X, Peppol BIS, XRechnung — specific implementations (how to deliver the invoice)
All of them implement EN 16931. If your invoice is Factur-X compliant at the EN 16931 profile, it's EN 16931 compliant. If it's Peppol BIS Billing 3.0 compliant, it's also EN 16931 compliant. They're different roads to the same destination.
The Profile Levels
EN 16931 itself defines one level of compliance: either an invoice contains all the mandatory fields and passes the business rules, or it doesn't. There's no "basic" or "advanced" within the standard itself.
However, Factur-X defines profiles that represent increasing levels of data completeness:
- Minimum — invoice number, date, parties, total. Not EN 16931 compliant.
- Basic WL — adds currency, tax breakdown, payment info. Not fully EN 16931 compliant.
- Basic — adds line items. Close to but not fully EN 16931 compliant.
- EN 16931 — all mandatory EN 16931 fields. This is the compliance target.
- Extended — adds optional fields beyond what EN 16931 requires.
If someone asks "is your invoice EN 16931 compliant?" they're asking whether it meets the EN 16931 profile or higher.
Business Rules
EN 16931 isn't just a list of fields. It includes business rules — logical constraints that the data must satisfy. Some examples:
BR-CO-10: The sum of all line net amounts must equal the invoice-level total of line net amounts. In other words, your line items must add up correctly.
BR-CO-15: The invoice total with tax must equal the invoice total without tax plus the total tax amount. Basic arithmetic, but validators check it precisely, and rounding differences will cause failures.
BR-S-08: If any line item uses VAT category "S" (standard rate), the VAT rate must be greater than zero.
BR-AE-01 to BR-AE-10: A set of rules governing reverse charge invoices. If the VAT category is "AE," no tax amount should be charged, and the invoice must include a specific reason code and note.
There are roughly 150 business rules in total. Validators like those from ecosio or FeRD check all of them. A structurally valid XML file that violates a business rule will still fail validation.
Why Should You Care?
If you're a freelancer or small business owner, you might wonder why a technical standard matters to you. Here's why:
Legal compliance. Multiple EU countries are mandating e-invoices that conform to EN 16931. Germany, France, Belgium, Poland, and others are all rolling out mandates between now and 2028. If your invoices don't meet the standard, they may be rejected.
Faster payments. Invoices that conform to EN 16931 can be processed automatically by the recipient's accounting system. No manual data entry means no delays caused by someone re-typing your invoice into their software.
Cross-border simplicity. One standard works across all EU countries. You don't need to learn German e-invoicing rules and French e-invoicing rules separately. If your invoice is EN 16931 compliant, it works everywhere.
Future-proofing. As ViDA (VAT in the Digital Age) progresses, EN 16931 is the baseline. Any future EU-wide e-invoicing mandate will build on this standard. Getting compliant now means you won't need to rework your invoicing later.
How to Know if Your Invoice Is Compliant
The most reliable way is to validate it. Several free tools exist:
ecosio online validator checks both the XML structure and the EN 16931 business rules. Upload your CII or UBL XML and get immediate feedback.
KoSIT Validator (Germany) is the official German validation tool for XRechnung and other EN 16931 formats.
Chorus Pro (France) validates invoices submitted to French government entities.
If you use Factur-X, the XML is embedded inside your PDF. You'll need to extract it first (tools exist for this), then upload the XML to a validator.
The key things validators check:
- Are all mandatory fields present?
- Are the values in the correct format (dates, codes, amounts)?
- Do the totals add up?
- Are the business rules satisfied?
- Is the correct profile identifier present in the XML?
How Facturwise Handles EN 16931
Facturwise generates invoices at the EN 16931 profile automatically. When you create an invoice, the system:
- Maps your invoice data to the full set of EN 16931 mandatory fields
- Generates valid CII XML with the correct profile identifier (
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931) - Embeds the XML into a PDF/A-3b document with proper XMP metadata
- Assigns the correct ISO 6523 scheme IDs based on each party's country
- Calculates tax summaries and validates that totals are arithmetically consistent
You fill in your invoice as normal — client name, line items, amounts — and the compliance layer works in the background. No configuration, no technical knowledge required.
You don't need to memorize business rules or learn XML syntax. Facturwise maps your invoice data to the full EN 16931 standard automatically — every field, every calculation, every validation — so you can focus on your work instead of compliance paperwork. Create your first EN 16931 compliant invoice for free.