EN 16931 Validation: The Complete Rule Map (955 Rules Explained)

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.

Browse all UBL-CR rules →

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

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.

Putting It All Together

Here is the full validation flow for a Peppol BIS 3.0 UBL invoice destined for a German public sector receiver:

1. XSD validation — Check the XML against UBL 2.1 Invoice schema (~50 structural rules)
2. EN 16931 business rules — Run BR-, BR-CO-, BR-CL-* Schematron assertions (~65 rules)
3. Peppol BIS rules — Run PEPPOL-EN16931-R* assertions (~80 rules)
4. UBL conformance rules — Run UBL-CR-* assertions (~648 rules)
5. 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.