Peppol validation checks whether a business document conforms to the syntax and rules declared by that document. For Peppol BIS Billing, a validator typically checks five practical areas. A document must pass every fatal rule that applies. The failed checkpoint helps identify whether the cause is malformed XML, missing or inconsistent invoice data, an unsupported element, a Peppol-specific restriction, or a national requirement.
| Validation area | What it checks | How errors are identified |
| XML schema | The document is well-formed and conforms to the supported UBL 2.1 or CII schema | Parser or schema messages rather than Peppol rule codes |
| EN 16931 business rules | Required business terms, calculations, code lists and VAT logic | BR-, BR-CO-, BR-CL-, BR-DEC- and VAT rule families |
| Syntax binding | The elements, paths and cardinalities permitted in the selected XML syntax | UBL-SR-, UBL-CR- and CII-SR- |
| Peppol BIS rules | Additional Peppol constraints, including specification, profile and identifier requirements | PEPPOL-EN16931-R and PEPPOL-COMMON-R |
| Country-qualified rules | Requirements activated by the supplier country | For example SE-R-, DK-R-, DE-R- and NL-R- |
Fatal errors and warnings
Under OpenPeppol’s BIS compliance rules, a document is compliant when the current validation artifacts report no fatal errors. A document with warnings only is still compliant, but warnings should be investigated. They often identify data quality issues or rules that may become stricter in a later release.
Rule severity can change between scheduled releases. In Peppol BIS Billing 3.0.21, PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053 changed from warnings to fatal errors. The Danish rules DK-R-003 and DK-R-017 also became fatal. The release became mandatory on 17 August 2026. A release change can therefore cause documents that passed an older validator to fail against the current artifacts.
Where validation happens
The sender must not send a document that is non-compliant with the applicable BIS. In practice, the sending software or Peppol Service Provider normally validates the document before transmission. A failure at this stage is usually returned by the sender’s own integration or service provider before the document reaches the recipient.
The receiving solution may validate the document again and apply its own business controls. These are separate from Peppol validation. For example, the recipient may check for a purchase order, duplicate invoice number, agreed supplier details or matching goods receipt after the Peppol document has passed technical validation.
What validation does not prove
A technically valid invoice conforms to the declared specification and the rules that apply to it. Validation does not confirm that the underlying transaction is commercially correct, that the goods were delivered, that the invoice is not disputed, or that the buyer will approve it for payment. Those decisions belong to the business process after receipt.
How to read a validation error
- Check the severity. Resolve fatal errors before sending. Record warnings and assess whether they indicate a future compatibility issue.
- Identify the rule family. The prefix tells you whether the failure comes from EN 16931, the syntax binding, Peppol or a national rule set.
- Read the rule statement and XML context. Validators may provide an XPath, element name or business term such as BT-24. Use it to trace the error back to the source field and mapping.
- Fix the source data or transformation. Avoid changing only the generated XML when the same incorrect value will be produced again.
- Validate the complete document again. One underlying issue can trigger several rules. Correct structural and identifier errors first, then review the remaining results.
How country-specific rules are activated
Country-qualified rules are not selected by the buyer’s destination alone. For Peppol BIS Billing 3.0, the supplier country is determined in priority order from the country prefix in the Seller VAT identifier (BT-31), the country prefix in the Seller tax representative VAT identifier (BT-63), and then the Seller country code (BT-40). Only the relevant national rule set is activated.
This means that a change to supplier tax data can change which rules run even when the postal address remains the same. The national rules are included in the common Peppol BIS validation artifacts. They do not require a separate specification identifier or SMP registration.
Testing new Peppol releases
OpenPeppol publishes the specification, rule tables, code lists, Schematron files, examples and release notes. Integrators should keep the validation artifact version explicit in test and production environments, run regression tests for both invoices and credit notes, and test upcoming releases before their mandatory date. New warnings should be treated as planned remediation rather than ignored until they become fatal.
Common errors
- PEPPOL-EN16931-R004. The specification identifier is wrong or contains version information that is not permitted.
- Inconsistent monetary totals. Line amounts, allowances, charges, VAT breakdowns, and document totals have been calculated or rounded differently.
- Identifier and code-list errors. An identifier uses the wrong scheme, has an invalid format, or a value is no longer present in the active code list.
- Unsupported elements or cardinalities. XML can be valid against the full UBL or CII schema but still use an element or repetition that the Peppol syntax binding does not permit.
See further examples in common Peppol e-invoicing errors.
Normative sources
OpenPeppol publishes the Peppol BIS Billing specification, the current validation rules, the BIS compliance requirements and the release notes. Those sources are normative. The explanations here are Qvalia’s.
Describes Peppol BIS Billing 3.0.21, validation artefacts 1.3.16. Last reviewed 28 September 2026.