Key takeaways
- Peppol BIS validation checks that an invoice complies with the EN 16931 standard and the profile's own rules before it travels the network.
- The checks are written in Schematron, an ISO language, and published by OpenPeppol as rule files.
- Every rule carries a severity: a fatal error invalidates the invoice, a warning only flags it.
- The validation report names the failing rule, its severity and the place in the document to fix.
Peppol BIS validation, the check that comes before sending
Before an invoice travels the Peppol network, it passes an automatic exam: Peppol BIS validation. That check verifies, rule after rule, that the document is well formed, complete and consistent. An invoice that fails is not transmitted: it is rejected and sent back for correction. Understanding this step means understanding why an invoice goes out without a hitch or stays stuck.
Validation does not judge the commercial substance of the invoice: it does not say whether the price is right. It checks compliance with the format. Its job is to guarantee that a document accepted by one piece of software will be read without ambiguity by any other, anywhere on the network.
This article describes how that check works. For the profile itself, read Peppol BIS Billing 3.0: what the format contains; for the standard it applies, The EN 16931 standard.
Two rule sets stacked: EN 16931 and Peppol
Validation does not rest on a single set of rules but on two complementary layers. The first comes from the European standard EN 16931: these are the business rules of the invoice model, common across Europe. The second is added by OpenPeppol: these are the rules specific to the profile, which refine and tighten the standard for real use on the network.
The two rule sets are published separately. The standard's rules live in one file, the Peppol rules in another. A document must pass both to be accepted: being EN 16931 compliant is not enough if it fails a Peppol rule, and the reverse is just as true.
The rule families an invoice goes through
EN 16931 business rules
Carry a 'BR-' prefix (business rule): mandatory fields, consistency of totals, VAT breakdown rules.
Code list rules
Carry a 'BR-CL-' prefix: a currency, country or VAT category code must belong to the expected standardised list.
UBL binding rules
Carry 'UBL-CR-', 'UBL-DT-', 'UBL-SR-' prefixes: they check how the model is expressed in the UBL 2.1 syntax.
Peppol-specific rules
Carry a 'PEPPOL-EN16931-R' or 'PEPPOL-COMMON-R' prefix: requirements added by OpenPeppol, plus any national rules.
Schematron: the language that expresses the rules
All these rules are written in one language: Schematron, an ISO standard designed to check XML documents. Where an XML grammar describes which tags exist, Schematron expresses assertions: "this total must equal the sum of the lines", "this reference must be present". That is exactly what an invoice needs.
OpenPeppol publishes these rules as Schematron files (the .sch extension), freely downloadable: one file for the EN 16931 rules, one file for the Peppol rules. A validator loads those files, applies them to the invoice's UBL file and produces a line-by-line report. It is this same mechanism that runs inside compliant software and in the official test tool.
rule sets
EN 16931 and Peppol rules
check language
an ISO standard for XML
severities
fatal error or warning
Fatal error or warning: what blocks and what flags
Every rule carries a severity, and it is the severity that decides the invoice's fate. A fatal rule makes the document invalid: until it is corrected, the invoice cannot be transmitted. A warning rule points to a defect recommended for correction but does not prevent sending.
The severity is not inferred from the message text: it is set by a flag attribute on the rule inside the Schematron file (fatal or warning). In practice, only fatal errors cause a rejection; warnings pile up in the report without blocking the document.
| Fatal error | Warning | |
|---|---|---|
| Makes the invoice invalid | ||
| Prevents transmission | ||
| Must be fixed before sending | ||
| Appears in the validation report |
A few classic fatal rules give a sense of what is checked: a Peppol invoice must carry the business process identifier, it must include either a buyer reference or a purchase order reference, and its amounts may not have more than two decimal places. Each matches a precise rule, identified by its code in the report.
Invoices that pass validation on the first try
YouInv validates your invoices against the Peppol BIS Billing 3.0 profile before sending: fatal errors are flagged and corrected before the document leaves on the network.
Reading a rejection report and fixing it
When an invoice fails, the validator does not simply refuse it: it produces a detailed report. For each failing rule, the report gives three things: the rule code (for example PEPPOL-EN16931-R003), its severity and a readable message describing the problem. It also points to the exact place in the document, which lets you trace straight back to the field to fix.
Reading a rejection therefore always follows the same order: spot the fatal lines, read their message, locate the field, correct the source data, then revalidate. Warnings are handled afterwards, without urgency. On the network, a formal rejection issued by the recipient takes the shape of a Message Level Response, described in The Peppol Message Level Response (MLR).
What it changes for your business
The good news is that you do not have to learn the rules by heart or read Schematron. Compliant software embeds the official rule files, validates every invoice before sending and shows you the errors in plain language. Your job is limited to correcting the flagged data.
What changes is the criterion for choosing your tool: it must validate upstream, at the right version of the rules, and hand you a report you can understand rather than a silent rejection. That is what separates an invoice that goes out first time from a round trip of corrections.
Further reading
- Peppol BIS Billing 3.0: what the format contains: the profile that validation enforces.
- The EN 16931 standard: the semantic model the "BR-" rules come from.
- The Peppol Message Level Response (MLR): how a rejection is returned to the sender.
The reference source is authoritative: the Peppol BIS Billing 3.0 documentation published by OpenPeppol.
What is Peppol BIS validation?
Peppol BIS validation is the automatic check an e-invoice must pass before it can travel over the Peppol network. Using Schematron rules, it verifies that the document complies with the EN 16931 standard and with the rules specific to the Peppol BIS Billing 3.0 profile. An invoice that fails a fatal rule is invalid and rejected.
What is Schematron in e-invoice validation?
Schematron is a standardised language (ISO) that expresses check rules over an XML document. The Peppol validation rules are published by OpenPeppol as Schematron files (.sch): one carries the EN 16931 rules, the other the rules specific to Peppol. A validator applies those rules to the UBL file and produces a report.
What is the difference between a fatal error and a warning?
A fatal error makes the invoice invalid: it cannot be transmitted until it is corrected. A warning flags something worth fixing but does not invalidate the document. Only fatal errors cause a rejection.
Why is my e-invoice being rejected?
An invoice is rejected when it fails at least one fatal validation rule: a missing mandatory field, a total that does not add up, a code outside the allowed list, or a required reference left out. The validation report names the rule at fault, its severity and the location in the document concerned.
Who validates the invoice on the Peppol network?
A compliant access point validates the document before sending it, so that a non-compliant invoice never leaves on the network. The recipient can in turn check what it receives. Compliant invoicing software builds this validation in upstream.
