Validation and compliance (EN 16931)

Validating an e-invoice means establishing whether it satisfies the rules of its format — before the recipient rejects it. The report knows exactly two severities: Error and Warning. “Compliant” means “no finding with the severity error”. A warning stays in the report and should be read, but it does not render the invoice ineffective.

The three validation routes — not equivalent

Formats	Route	Validation level shown
XRechnung, ZUGFeRD/Factur-X, Peppol BIS	the native EN 16931 validator: the Schematron rules ported to C# predicates, with rule IDs and BT references. With Peppol a jurisdiction switch decides which PINT rule sets apply	“EN 16931 … (native)”
FatturaPA, Finvoice, ebInterface, Austrofix, FA_VAT, Facturae	the official XSD, business rules and an arithmetic cross-check	“Arithmetic consistency + business rules”
ERP formats, non-European formats, ZUGFeRD 1.0	not validatable — not an EN 16931 document. The answer names the format and points to conversion	“Format detection”

The validation level belongs in every record

A “Compliant” from the consistency check is a different assurance from one issued by the EN 16931 validator. Anyone archiving or passing on validation results should note the level as well — otherwise the record later claims more than was actually checked.

What the report contains

Column	Content
Rule	the rule that was breached: BR-… (EN 16931), BR-DE-… (German refinement), PEPPOL-EN16931-…, CONS-… (our own consistency rules). A — means a finding without a rule reference
Severity	error or warning
Message	the text from the validation engine
Location	the reference — an XPath or a business term such as BT-10

For automated evaluation the rule ID is what counts, never the message text

The normative EN 16931 rules deliberately keep their original wording. Some messages come from the engine and are in German even when the interface is set to English; those passages are marked in the report. Rule IDs and BT references are language-neutral.

Two rules that often come as a surprise

Peppol requires a reference. PEPPOL-EN16931-R003 demands either a buyer reference (BT-10) or an order reference (BT-13) — as an error, not a warning.

XRechnung is stricter. BR-DE-15 requires BT-10 itself; an order reference is not enough. With German public-sector buyers, BT-10 is the Leitweg-ID. Store it in the customer record and it will no longer be missing.

Why ZUGFeRD is sometimes rejected

It is probably ZUGFeRD 1.0. That format predates EN 16931 and is therefore readable but not validatable. Convert it to a current version and validate that — which is precisely the migration route for a legacy archive.

Repaired documents

Narrowly defined defects are fixed before reading: wrong encoding names, invalid tag names, bare &, control characters, debris before the XML declaration, an orphaned end tag at the end of the file. Every repair is stated in the report; none of it happens silently. A file that is badly nested or cut off mid-element keeps its fault.

The warning box above the report also says what follows from this: the original file remains faulty and will fail with every other recipient — the sender should fix their export.

Limits of validation

• No <!DOCTYPE> and no xsi:schemaLocation. Either would let the uploaded document decide what it is validated against. Only the bundled schemas apply.
• Missing code lists do not make validation fail — it would then reject wrongly. Instead those rules are skipped and the report carries a warning. That way an unvalidated invoice is never reported as a validated one.
• Through the API, 200 only means “validated”. The verdict is in isValid and errorCount; a 400 means validation could not run at all.