How do you validate an e-invoice?
Validating an e-invoice means running it through three checks in order, XML schema, EN 16931 business rules, then the country or network rules, and knowing which of them actually ran.
An e-invoice is validated in layers, not in one pass. The document goes through an XML schema check, then the EN 16931 business rules, then whatever country or network rules apply to it. Each layer can reject the document for a different reason, and a document that clears one can still fail the next.
The three layers
XSDJudgesWhich elements exist, in what order, and with what data types.
Is this a well-formed document of the right shape? It catches a truncated file, a misspelled element, a date in the wrong format.
SchematronJudgesInvoice content, as Business Terms and Business Groups.
EN 16931 is the European semantic standard for e-invoicing, published by CEN in support of Directive 2014/55/EU. It defines invoice content as Business Terms (BT-1 is the invoice number, BT-2 the issue date) and Business Groups, and it constrains them with business rules: BR-* for the core rules, BR-CL-* for code-list membership, BR-CO-* for arithmetic. This is the layer that notices your line totals do not add up to your invoice total, or that your currency code is not a real ISO 4217 code. These rules are published as Schematron, an XML rule language, so they run mechanically rather than by inspection.
CIUSJudgesWhatever restrictions a market layers on the European core.
On top of the European core, most markets add their own restrictions, published as a CIUS (Core Invoice Usage Specification). Germany’s XRechnung adds BR-DE-* rules, the Peppol BIS Billing 3.0 network adds PEPPOL-EN16931-R*, Factur-X adds FX-SCH-*, and the French B2B reform adds BR-FR-CTC-*.
CustomizationID the file itself declares, so get that identifier wrong and the right rules never run.Not every format has all three
This is the part most explanations skip. A layer can only run if someone published rules for it to run.
For the EN 16931 family, all three layers exist. For three national formats they do not: Italy’s FatturaPA, Spain’s Facturae and Slovenia’s e-SLOG are published as an XML schema with no machine-readable business rules anywhere. For those, validation ends after layer one. A document that comes back valid is schema-valid, and that is the strongest statement any tool can honestly make about it from the outside.
Beliq labels this difference rather than hiding it. Formats judged against their authority’s own rulebook are Authority-checked; formats with only a schema to check against are Schema-checked, and the API says which is which in the verificationTier field on the keyless catalog. A tool that reports one undifferentiated “valid” across every format is telling you less than it appears to.
Hybrid PDFs add two more checks
ZUGFeRD and Factur-X are not a separate rulebook; they are the same CII XML wrapped in a PDF. So they carry the three layers above for the XML, plus two more for the envelope: the XML has to be correctly embedded, and the resulting file has to be a valid PDF/A-3b. A hybrid invoice that passes every business rule and is not valid PDF/A is still a broken deliverable.
A verdict is only as good as the rules behind it
“Valid” is a claim about a document measured against a specific set of rule files at a specific version. Rulebooks change: authorities publish new Schematron releases on their own schedules, and a rule that was a warning last year can be fatal this year. So the useful question is not only “did it pass” but “what judged it”.
That is why a Beliq validation result carries the rule artifacts that ran, each with its version and its own SHA-256 fingerprint, plus a single combined rulesetSha256. You can reproduce that fingerprint yourself and cross-check every component against the public catalog, so the verdict is something you can stand behind months later rather than something you have to take on trust.
Doing it
You do not need to build a validation stack to try this. The playground on the Beliq dashboard runs the live engine on a sample invoice with no key and no code, and returns the verdict, the ruleset version and the hashes. From code it is one POST of your XML or PDF to /v1/validate, which returns the same thing as structured JSON: a valid flag, and every finding with its rule ID, severity, XPath location and a human-readable message.