EN 16931 Validation: The Complete Rule Map (955 Rules Explained)
Every EN 16931 validation rule categorized, explained, and cross-referenced. The definitive technical reference for e-invoice developers.
EN 16931 defines the semantic data model for European e-invoices. It specifies which fields exist, what they mean, and how they relate to each other. But the data model alone does not tell you whether an invoice is valid.
That job falls to 955 validation rules spread across four distinct layers. These rules enforce everything from structural XML correctness to country-specific formatting requirements. A single invoice can be checked against 200+ rules depending on its format and destination. Fail one, and the invoice gets rejected.
This is the complete reference. Every rule category documented, cross-referenced, and explained.
How Validation Rules Are Organized
E-invoice validation operates as a four-layer stack. Each layer builds on the one below it:
| Layer | Rule Count | Prefix | Technology | What It Checks |
|---|---|---|---|---|
| 1. XML Schema | ~50 | cvc-* | XSD | Structure, element names, data types |
| 2. Business Rules | ~65 | BR-, BR-CO-, BR-CL-* | Schematron | Semantic correctness, calculations, codelists |
| 3. Format Rules | ~648 | UBL-CR-, CII-SR-, PEPPOL-* | Schematron | Syntax compliance, disallowed elements |
| 4. Country CIUS | ~192 | BR-DE-, BR-NL-, BR-IT-* | Schematron | National extensions, country-specific fields |
An invoice must pass all applicable layers. A Peppol BIS 3.0 invoice to a German public sector receiver checks layers 1 + 2 + 3 (Peppol rules) + 4 (BR-DE rules). A ZUGFeRD EN 16931 invoice for a domestic German B2B transaction checks layers 1 + 2 + 3 (CII rules) + 4 (BR-DE rules).
For a conceptual overview of how these layers interact, see How to Validate E-Invoices. This article focuses on the rules themselves.
Layer 1: XML Schema Validation (XSD)
The first check is structural. The XML document is validated against the UBL 2.1 or CII D16B schema definition. Errors at this layer have the cvc- prefix (XML Schema Constraint Violation).
What it catches:
- Malformed XML (missing closing tags, encoding errors)
- Unknown elements not defined in the schema
- Wrong data types (text where a date is expected, missing required attributes)
- Elements in the wrong order (XSD enforces sequence)
Common errors:
| Error | Meaning |
|---|---|
cvc-complex-type.2.4.a | Unexpected element found |
cvc-complex-type.2.4.b | Required element missing |
cvc-datatype-valid.1.2.1 | Value does not match the expected data type |
cvc-enumeration-valid | Value not in the allowed enumeration |
XSD errors are fatal — if the XML structure is broken, none of the higher layers can run. Fix these first.
Layer 2: Business Rules (BR-*) — The Core
The EN 16931 business rules enforce the semantic data model. They are implemented as Schematron assertions and fire against the parsed XML content. Every rule has a BR- prefix followed by a number.
These rules are organized into three sub-categories:
BR-* — Document-Level Requirements
The base business rules validate mandatory fields, conditional requirements, and structural relationships.
| Rule | What It Checks |
|---|---|
| BR-01 | Invoice must have a specification identifier (BT-24) |
| BR-02 | Invoice must have an invoice number (BT-1) |
| BR-03 | Invoice must have an issue date (BT-2) |
| BR-04 | Invoice must have a currency code (BT-5) |
| BR-05 | Invoice must have seller name and postal address |
| BR-06 | Invoice must have a seller name |
| BR-07 | Invoice must have a buyer name |
| BR-08 | Invoice must have seller postal address |
| BR-09 | Invoice must have seller country code |
| BR-10 | Invoice must have buyer postal address |
| BR-11 | Invoice must have buyer country code |
| BR-12 | Invoice must have invoice total with VAT (BT-112) |
| BR-13 | Invoice must have amount due (BT-115) |
| BR-15 | Invoice must have at least one invoice line |
| BR-16 | Invoice must have payment instructions if amount due > 0 |
Rules BR-01 through BR-30 cover the document header. Rules BR-31 onward cover invoice lines, VAT breakdowns, allowances, charges, and payment details.
Browse all BR-* rules in the Error Library →
BR-CO-* — Calculation Rules
Calculation rules enforce mathematical consistency. These are among the most frequently triggered errors because rounding differences between ERP systems and the EN 16931 calculation model are common.
| Rule | What It Checks |
|---|---|
| BR-CO-10 | Sum of line net amounts must equal invoice total without VAT |
| BR-CO-11 | Sum of allowances at document level |
| BR-CO-12 | Sum of charges at document level |
| BR-CO-13 | Invoice total without VAT = line totals - allowances + charges |
| BR-CO-14 | Invoice total with VAT = total without VAT + total VAT |
| BR-CO-15 | Invoice total VAT = sum of VAT category tax amounts |
When BR-CO-10 fires, the invoice line net amounts do not sum to the declared total. This usually means one of three things: the ERP rounds line amounts differently than EN 16931 expects, a line was added or removed without recalculating the total, or currency conversion introduced a rounding discrepancy.
BR-CL-* — Codelist Rules
Codelist rules validate that field values come from approved reference lists. EN 16931 references ISO, UNECE, and EU-specific codelists.
| Rule | Codelist | Example Valid Values |
|---|---|---|
| BR-CL-01 | ISO 4217 currency codes | EUR, USD, GBP, SEK |
| BR-CL-10 | UNECE 5189 allowance reason codes | 41 (Bonus), 42 (Discount) |
| BR-CL-11 | ISO 3166-1 country codes | DE, FR, NL, BE, IT |
| BR-CL-17 | EAS scheme identifiers | 0088 (GLN), 0208 (Belgian KBO) |
| BR-CL-25 | UNTDID 1001 invoice type codes | 380 (Invoice), 381 (Credit note) |
Codelist errors are straightforward to fix: replace the invalid value with one from the correct list. The challenge is knowing which version of the codelist the validator expects — some codelists update quarterly.
Layer 3: Format Rules — Structural Compliance
This is the largest rule category by count. Format rules enforce that the XML document uses only the elements allowed by a specific syntax binding. There are separate rule sets for UBL and CII.
UBL Conformance Rules (UBL-CR-*)
There are approximately 648 UBL-CR rules. The vast majority do the same thing: check that a disallowed UBL element is not present. UBL 2.1 defines hundreds of optional elements that EN 16931 does not use. If your XML includes any of them, a UBL-CR rule fires.
Pattern: Each rule follows the form "Element X shall not be used."
| Rule | What It Forbids |
|---|---|
| UBL-CR-077 | AccountingSupplierParty/Party/PartyLegalEntity/CompanyLiquidationStatusCode shall not be used |
| UBL-CR-003 | UBLVersionID shall not be used |
| UBL-CR-046 | BuyerCustomerParty/Party/PhysicalLocation shall not be used |
| UBL-CR-152 | InvoiceLine/DocumentReference/Attachment/EmbeddedDocumentBinaryObject shall not be used |
Why these errors happen: ERP systems often serialize all available UBL elements, including optional ones not in the EN 16931 subset. The fix is almost always to remove the offending element from the XML output template.
These are the most auto-fixable errors in the entire rule set. Of the 648 UBL-CR rules, virtually all can be resolved by stripping the disallowed element — no business logic changes required.
CII-SR Rules (CII-SR-*)
The CII (Cross Industry Invoice) equivalent of UBL-CR rules. These check that CII D16B elements outside the EN 16931 mapping are not used.
| Rule | What It Forbids |
|---|---|
| CII-SR-001 | ExchangedDocumentContext/TestIndicator shall not be used |
| CII-SR-100 | IncludedSupplyChainTradeLineItem — specific unused sub-elements |
CII-SR rules apply to ZUGFeRD and Factur-X invoices, and to any CII-based XRechnung documents.
Peppol Rules (PEPPOL-EN16931-R*)
Peppol adds its own validation layer on top of EN 16931. These rules enforce Peppol BIS 3.0 requirements that go beyond the base standard.
| Rule | What It Checks |
|---|---|
| PEPPOL-EN16931-R003 | Either buyer reference (BT-10) or order reference (BT-13) must be present |
| PEPPOL-EN16931-R010 | Buyer endpoint ID must be present with a valid scheme ID |
| PEPPOL-EN16931-R020 | Seller endpoint ID must be present |
| PEPPOL-EN16931-R080 | Document level allowance/charge reason code required |
PEPPOL-EN16931-R010 is the single most common Peppol validation error. It fires when the buyer's electronic address is missing or uses an incorrect scheme ID for the receiver's country.
Layer 4: Country-Specific Rules (CIUS Extensions)
EU member states extend EN 16931 through Country-Specific Implementations of the Universal Standard (CIUS). These add requirements beyond the base standard — typically making optional fields mandatory or restricting value ranges.
Germany: BR-DE-* Rules
Germany's XRechnung CIUS adds approximately 30 rules. These enforce German-specific requirements for B2G and (from 2027) B2B invoicing.
| Rule | What It Requires |
|---|---|
| BR-DE-01 | Payment instructions (BG-16) mandatory |
| BR-DE-02 | Buyer reference (BT-10) or purchase order reference (BT-13) mandatory |
| BR-DE-04 | At least one payment means type code (BT-81) must be present |
| BR-DE-13 | Seller contact email (BT-43) mandatory |
| BR-DE-15 | Buyer reference (BT-10) mandatory (tightened from BR-DE-02) |
| BR-DE-16 | Seller identifier (BT-29) or seller tax number (BT-32) mandatory |
| BR-DE-17 | Seller VAT identifier (BT-31) or tax number (BT-32) mandatory |
| BR-DE-21 | Customization ID must match current XRechnung version |
For a deep dive into every BR-DE rule with XML examples and fix guidance, see XRechnung BR-DE Validation Errors Explained.
Other Country CIUS
| Country | Rule Prefix | Approximate Rule Count |
|---|---|---|
| Netherlands | NL-R-* | ~10 |
| Italy | BR-IT-* | ~25 |
| France | FR-R-* | ~15 (coming with Factur-X mandate) |
| Belgium | BEvCIUS-* | ~10 |
| Sweden | SE-R-* | ~8 |
Browse all country-specific rules →
Auto-Fixable vs. Manual Fix
Not all validation errors require human intervention. Of the 955 rules in the complete validation stack, a significant portion can be resolved automatically — the fix is deterministic and does not require business judgment.
Fix Operations by Type
| Operation | Rule Count | What It Does |
|---|---|---|
| Remove disallowed element | 648 | Strips UBL-CR / CII-SR elements not in EN 16931 |
| Set default value | 49 | Inserts a standard value when a mandatory field is empty |
| Normalize format | 46 | Corrects formatting (date formats, currency codes, whitespace) |
| Recalculate | 18 | Recomputes totals to match EN 16931 calculation model |
| Map codelist | 12 | Translates non-standard codes to valid codelist values |
Auto-fix only applies to structural and syntactic errors. Financial fields — amounts, quantities, prices, tax rates — are never modified automatically. If a calculation rule fires because the underlying amounts are wrong, that requires manual review.
The Remove Operation
The remove operation accounts for 648 of all auto-fixable rules. This makes sense: UBL 2.1 defines hundreds of optional elements that EN 16931 explicitly excludes. ERP exports that serialize everything (a common default) produce invoices bloated with unused elements that trigger UBL-CR rules.
The fix is safe and deterministic: remove the element. The invoice's business content is unchanged. Only metadata noise is stripped.
Set Default
The set_default operation covers cases where a mandatory field can be populated with a standard value. The most common: setting the specification identifier (BT-24) to the correct EN 16931 customization ID when it is missing, or defaulting the invoice type code (BT-3) to 380 (commercial invoice) when absent.
What Cannot Be Auto-Fixed
Some errors require human judgment:
- Missing seller or buyer information — The data must come from your ERP or customer master
- Wrong VAT treatment — Tax classification depends on the transaction, not the format
- Incorrect amounts — If line totals or tax amounts are wrong, only your business logic knows the correct values
- Missing buyer reference (BT-10) — This is specific to each transaction and must come from the buyer
For a conceptual overview of auto-fix and the Evidence Pack workflow, see E-Invoice Remediation.
Rule Versioning
Validation rules are not static. They update on independent release cycles:
| Rule Set | Approximate Release Cadence | Current Key Version |
|---|---|---|
| EN 16931 Schematron | 1-2 times per year | CEN 1.3.15 |
| Peppol BIS | 2-3 times per year | November 2025 release |
| XRechnung | Annually | 3.0.2 (2026-01-31 configuration) |
| Country CIUS | Varies | Depends on country |
When a new Schematron release drops, previously valid invoices can fail validation if the rules tightened. This is why continuous validation matters — what passed in January may not pass in July.
Explore All 1,300+ Validation Rules
Search, filter, and get fix guidance for every EN 16931, Peppol, XRechnung, and country-specific validation rule.
Open the Error LibraryPutting It All Together
Here is the full validation flow for a Peppol BIS 3.0 UBL invoice destined for a German public sector receiver:
- XSD validation — Check the XML against UBL 2.1 Invoice schema (~50 structural rules)
- EN 16931 business rules — Run BR-, BR-CO-, BR-CL-* Schematron assertions (~65 rules)
- Peppol BIS rules — Run PEPPOL-EN16931-R* assertions (~80 rules)
- UBL conformance rules — Run UBL-CR-* assertions (~648 rules)
- XRechnung CIUS — Run BR-DE-* assertions (~30 rules)
Total: approximately 873 rules for this single invoice. Every rule must pass. One failure means rejection.
The validator runs all applicable layers automatically. Upload an invoice, and it detects the format, identifies the CIUS, and applies the correct rule stack. Every error links to a detailed explanation in the error library.
Frequently Asked Questions
How many validation rules does EN 16931 have?
The EN 16931 standard itself defines approximately 65 business rules (BR-, BR-CO-, BR-CL-*). But a production invoice is validated against far more. Adding format rules (UBL-CR or CII-SR), Peppol rules, and country-specific CIUS rules, the total exceeds 955 distinct rules across all layers.
What is the difference between BR-* and UBL-CR-* rules?
BR-* rules are semantic — they check whether the invoice content is correct (required fields present, amounts calculated properly, valid codelist values). UBL-CR-* rules are syntactic — they check whether the XML structure conforms to the EN 16931 subset of UBL. An invoice can have correct content (pass all BR-* rules) but still fail UBL-CR-* rules because the XML contains extra elements that EN 16931 does not allow.
Can validation errors be fixed automatically?
Many of them, yes. Approximately 648 errors (the UBL-CR/CII-SR rules) are resolved by removing disallowed elements. Another ~125 errors can be fixed by setting defaults, normalizing formats, or recalculating totals. Financial fields are never auto-modified. The remaining errors require human input — typically providing missing business data.
Which layer causes the most rejections in production?
Layer 3 (format rules) generates the highest volume of errors because of the 648 UBL-CR "remove disallowed element" rules. But layer 2 (business rules) causes the most impactful rejections — a missing mandatory field or a calculation mismatch cannot be auto-fixed and requires investigation. PEPPOL-EN16931-R010 (missing buyer endpoint) and BR-CO-10 (amount mismatch) are consistently the most common production-blocking errors.
Where can I find the Schematron source files?
The EN 16931 Schematron rules are maintained by CEN TC 434 and published on the CEN GitHub repository. The XRechnung-specific rules are maintained by KoSIT and available in their validator configuration repository. Peppol BIS rules are published by OpenPeppol as part of the Peppol BIS Billing 3.0 specification.
Validate your invoices against all 955+ rules. Upload to the free validator for instant results, or integrate via the API for pipeline validation.
Check Your Compliance Status
Find out exactly what your business needs to do for e-invoicing compliance.
Use Obligation Finder