Validating

What for. To establish whether an e-invoice satisfies the rules of its format — before the recipient rejects it.

In. A file or pasted XML. The format is detected from the document itself; there is no selector for it. A ZUGFeRD/Factur-X hybrid PDF is accepted: its embedded XML is extracted and validated.

Each invoice type also has its own sub-page — /en/validate/xrechnung, /en/validate/zugferd and so on. What is validated is the same; the difference is explanatory text.

The three validation routes

Formats	Route	Validation level shown
XRechnung, ZUGFeRD/Factur-X, Peppol BIS	the native EN 16931 validator — the Schematron rules as C# predicates, no Saxon; yields rule IDs and BT references	“EN 16931 + XRechnung CIUS (native)”, “EN 16931 (CII, native)”, “EN 16931 + Peppol (native)”, “EN 16931 + CIUS-RO (native)”
FatturaPA, Finvoice, ebInterface, Austrofix, FA_VAT, Facturae	the official XSD, business rules and an arithmetic cross-check (CONS-*)	“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. More on this under Validation and compliance.

The validation report

Line	Content
Status	Compliant / Not compliant / Not detected, with the name of the detected format alongside
Key figures	Validation level: … · n errors · m warnings
Table	Rule, Severity, Message, Location per finding — or “No objections.”
Footnote	“Message texts come from the validation engine (German); rule IDs and references (BT-…) are language-neutral.”

An error is a breach of a binding rule — the invoice counts as non-compliant and will be rejected by the recipient. A warning is a pointer and does not change the status. The status at the top reads “Compliant” exactly when no finding has the severity error.

The Rule column names 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. The Location column names 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.

Repaired documents

Some defects are fixed rather than causing rejection: broken character-set declarations, invalid characters in element names, unescaped &, control characters, debris before the XML declaration. A warning box then sits above the report — “The file was faulty — we repaired it” — listing the interventions and ending with this:

The result below comes from the repaired version. The original file remains faulty — ask the sender to fix their export, otherwise the same file will fail with every other recipient.

The repair is narrowly defined: a file that is badly nested or cut off mid-element keeps its fault.

Limits and special cases

• No <!DOCTYPE …> and no xsi:schemaLocation. Either would let the uploaded document decide what is fetched or what it is validated against. Only the bundled schemas apply.
• Missing code lists do not make validation fail — it would then reject wrongly — but the report carries a warning in that case.
• An ordinary PDF yields no report. The page says so and offers “PDF to e-invoice”; the file is carried over, so a second upload is not needed.

What else the result page offers

Element	When
“Correct invoice”	only when there are errors: opens the create form with everything the file already carries
“Convert now”	as soon as a format has been detected
the legible rendering	expanded below the report
“File changed? Validate again here:”	a small upload field at the foot of the page
“Save to archive”	with an account only