E-Invoice Validation Rules Explained

Every EU e-invoice must pass validation before it reaches the receiver. But "validation" isn't a single check — it's four distinct layers, each enforcing different rules. Understanding these layers is the difference between chasing individual error codes and building a pipeline that handles compliance systematically.

The Four Validation Layers

E-invoice validation works like a stack. Each layer adds rules on top of the one below it:

Layer	Rules	What It Catches
1. XML Schema (XSD)	Structure rules	Malformed XML, wrong element names, invalid data types
2. EN 16931 Business Rules	~65 BR-* rules	Missing mandatory fields, amount mismatches, VAT errors
3. Format Rules	~80 PEPPOL-* or format-specific	Peppol BIS, XRechnung, Factur-X requirements
4. Country CIUS	10-30 per country	Germany BR-DE-, Belgium BEvCIUS, France FR-R-

A Peppol BIS invoice sent to a German government entity must pass all four layers. That's 200+ rules. A ZUGFeRD BASIC invoice for a domestic German transaction hits layers 1, 2, and 4 — still 100+ rules.

The total rule count across all layers and all supported countries exceeds 500. Nobody memorizes them. Tools enforce them.

Layer 1: XML Schema Validation

The first check is structural. Is the XML well-formed? Do the element names match the schema? Are data types correct?

This layer uses XSD (XML Schema Definition) files — one for UBL 2.1 and one for CII 16B. It catches:

• Missing required XML elements
• Elements in the wrong order
• Invalid data types (text in a numeric field)
• Unknown elements not in the schema
• Namespace errors

Schema failures are usually ERP template bugs — a misspelled element name, a wrong namespace URI. They're always auto-fixable because they're purely structural.

Layer 2: EN 16931 Business Rules

EN 16931 defines the semantic data model for European e-invoices. Its business rules (prefixed BR-) enforce the relationships between fields.

Rule Categories

Structural rules (BR-01 through BR-10) check that mandatory elements exist:

• BR-01: An invoice shall have a specification identifier (BT-24)
• BR-02: An invoice shall have an invoice number (BT-1)
• BR-03: An invoice shall have an invoice issue date (BT-2)
• BR-05: An invoice shall have an invoice currency code (BT-5)
• BR-06: An invoice shall have the seller name (BG-4)
• BR-07: An invoice shall have the buyer name (BG-7)

Amount calculation rules (BR-CO-*) verify mathematical consistency:

• BR-CO-10: Sum of invoice line net amounts = invoice total without VAT
• BR-CO-13: Invoice total with VAT = invoice total without VAT + VAT total
• BR-CO-15: Invoice line net amount = (quantity × price) - allowance + charge
• BR-CO-16: Amount due = invoice total with VAT - prepaid amount

VAT rules (BR-S-, BR-Z-, BR-E-, BR-AE-, BR-IG-*) enforce tax logic:

• BR-S-01: Taxable amount in a standard-rated VAT breakdown must not be zero
• BR-Z-05: Zero-rated VAT category must have rate = 0
• BR-E-05: VAT exempt category must have rate = 0
• BR-AE-02: Reverse charge requires buyer VAT identifier (BT-48)

Top 5 Most-Triggered EN 16931 Rules

Based on validation data from our engine:

1. BR-CO-10 — Invoice line net amount sum mismatch. Usually a rounding issue between line totals and the invoice total.
2. BR-CO-13 — Total with VAT doesn't match total without VAT + VAT amount. Same rounding root cause.
3. BR-CO-09 — VAT identifier required when tax is charged. Missing seller VAT number (BT-31).
4. BR-02 — Missing invoice number. ERP template didn't populate BT-1.
5. BR-05 — Missing currency code. BT-5 not set.

Layer 3: Format-Specific Rules

On top of EN 16931, each invoice format adds its own rules.

Peppol BIS 3.0

Peppol adds approximately 80 rules (PEPPOL-EN16931-R001 through R080). These enforce Peppol network requirements:

• PEPPOL-EN16931-R003 — Either buyer reference (BT-10) or order reference (BT-13) must be present
• PEPPOL-EN16931-R004 — Specification identifier (BT-24) must be valid
• PEPPOL-EN16931-R010 — Buyer endpoint ID must be present with a valid scheme ID
• PEPPOL-EN16931-R020 — Seller endpoint ID must be present

Top 5 Peppol-Specific Errors

1. PEPPOL-EN16931-R010 — Missing or invalid buyer endpoint. The most common Peppol error.
2. PEPPOL-EN16931-R003 — Missing buyer reference / purchase order. ERP didn't populate either field.
3. PEPPOL-EN16931-R020 — Missing seller endpoint ID.
4. PEPPOL-EN16931-R005 — Invalid identifier scheme. Wrong scheme ID for the country.
5. PEPPOL-EN16931-R004 — Wrong specification identifier in BT-24.

XRechnung

Germany's XRechnung CIUS shares some rules with the Peppol layer but has its own distinct rule set that applies specifically to German B2G invoicing.

Factur-X / ZUGFeRD

ZUGFeRD and Factur-X add rules specific to the hybrid PDF/CII format: CII-specific field mappings, PDF/A-3 compliance requirements, and profile-level completeness checks.

Layer 4: Country CIUS Rules

Each country can define additional rules through a CIUS (Core Invoice Usage Specification). These add requirements without removing any EN 16931 base rules.

Germany (XRechnung): BR-DE-01 through BR-DE-26

Rule	Requirement
BR-DE-01	Payment information (BG-16) mandatory
BR-DE-15	Buyer reference (BT-10) mandatory — must be Leitweg-ID
BR-DE-16	Seller must have email address
BR-DE-17	Seller contact information mandatory
BR-DE-21	Payment means code must be present

Belgium (BEvCIUS)

Belgium's CIUS enforces KBO/BCE enterprise number usage, scheme ID 0208 validation, and Belgian-specific rounding rules.

France (FR-R-*)

France's rules focus on SIRET validation, NAF activity codes, and Chorus Pro routing requirements.

Rule Count Comparison

Country	CIUS	Additional Rules	On top of
Germany	XRechnung	26	EN 16931 + Peppol
Belgium	BEvCIUS	~15	EN 16931 + Peppol
France	FR-R	~20	EN 16931
Italy	FatturaPA	~40	Own schema (not EN 16931)
Netherlands	SI-UBL	~10	EN 16931 + Peppol

How Rules Are Enforced: Schematron

Layers 2-4 use Schematron — an XML-based validation language that expresses business rules as XPath assertions.

How a Schematron Rule Works

<rule context="cac:InvoiceLine">
  <assert test="cac:Price/cbc:PriceAmount >= 0"
          flag="fatal"
          id="BR-26">
    [BR-26] Each invoice line net amount must not be negative.
  </assert>
</rule>

• context: which XML element the rule applies to
• test: an XPath expression that must be true
• flag: severity (fatal = fails validation, warning = advisory)
• id: the error code returned on failure

Severity Levels

Severity	Meaning	Action
Fatal	Rule violation — invoice is invalid	Must fix before submission
Warning	Advisory — invoice may have issues	Review recommended
Info	Informational	No action required

Only fatal errors cause rejection. Warnings and info messages are advisory. Most EN 16931 and Peppol rules are fatal. Some country CIUS rules are warnings.

How Invoice Navigator Classifies Errors

Our engine runs all four validation layers and then adds a classification step. Every error is tagged:

• Auto-fix — structural issues where the fix is unambiguous and doesn't change commercial meaning
• Input required — missing data that only the sender can provide
• Blocked — financial field issues that cannot be auto-resolved

This classification determines what happens next. Auto-fixable errors are remediated immediately. Input-required errors generate precise field-level requests. Blocked errors route for human review. The classified result is documented in an Evidence Pack.

Validate your invoice → or see the API documentation →

FAQ

How do I know which rules apply to my invoices?

It depends on your format and destination country. A Peppol BIS invoice to a German government entity checks EN 16931 + Peppol BIS + XRechnung rules. A ZUGFeRD BASIC invoice for a domestic German B2B transaction checks EN 16931 + ZUGFeRD profile rules. Our validator auto-detects the format and applies the correct rule set.

Where can I find the official rule definitions?

EN 16931 rules are published by CEN TC 434 on GitHub. Peppol rules are maintained by OpenPeppol. Country CIUS rules are published by national authorities (KoSIT for Germany, Logius for Netherlands). We document every rule we encounter in our error library.

What happens when rules conflict between layers?

By design, they don't. A CIUS can only add restrictions on top of EN 16931 — it cannot relax or remove core rules. If an invoice passes all four layers, it's valid for that specific combination of format and country. If there's a perceived conflict, it's usually a misunderstanding of which CIUS applies.