How to validate a Peppol invoice

Shortcut: if users search for Peppol validation or a Peppol validator, they usually want to know whether the XML is merely readable or whether it also passes formal invoice rules.

There is a major difference between a useful invoice precheck and full formal validation. A precheck helps you understand whether the file looks structurally plausible and whether the core business fields exist. Formal validation goes further into standard rules, profile rules, mandatory combinations, totals logic, and network-specific requirements. Users searching for a Peppol validator often need the first layer before the second layer becomes meaningful.

Tooltensor editorial note: This page was checked for workflow scope and terminology. Last updated: July 7, 2026.

Start with the basic question first

Before you validate anything formally, ask a simpler question: what file is this, and can I read the main invoice fields? If the file family is unclear, use the detector first. If the XML is already known, open it in the viewer. A file that is already unclear at this stage should not jump straight into deeper validation because the eventual error message may hide the real problem.

What a precheck is supposed to do

A good precheck confirms whether the invoice carries recognizable identifiers, party data, totals, currency, dates, and line items. It is the fastest way to catch files that are incomplete, misclassified, or obviously broken before a stricter rules engine gets involved. A precheck is not a legal verdict. It is an operational triage step.

What formal validation adds

Formal validation goes beyond readability. It checks whether the XML satisfies deeper invoice expectations, such as EN 16931-style content rules, profile alignment, mandatory field combinations, and other structured constraints. A file can look readable to a person and still fail formal Peppol validation for good reasons.

Why the order matters

If you run formal validation first on a file that is already poorly understood, the result can be less useful. A team may see a failure message without knowing whether the real issue is the file family, the invoice content, a missing identifier, or the standard rule itself. Detect first, inspect second, validate third. That sequence keeps the failure point clear.

Common mistake

The most common mistake is using a validator as if it were a viewer. Validators are not designed to explain the invoice to a human from scratch. They are designed to judge a file against a ruleset. If the business still needs to know who sent the invoice, what the total is, or whether the line items are even present, readable inspection should happen first.

Where Tooltensor fits

Tooltensor is strongest at the first two layers. It helps users classify the file and inspect the XML in a readable way. The Peppol Invoice Validator page then adds a staged validation path so users can see the difference between local structural review and deeper invoice-rule checking.

What to check before escalating

Before escalating to formal validation, confirm the invoice family, supplier and buyer blocks, invoice number, issue date, currency, totals, and line items. If those elements are already weak or missing, the structured workflow problem is likely earlier than compliance. Fixing the source file or the supplier export may matter more than reading a longer validator error.