UBL/Peppol invoice validator

Check the shape before the network checks it for you

The expensive way to find out an invoice file is broken is to send it: it travels to your customer or an access point, gets rejected hours or days later, and the payment clock starts over. The cheap way is thirty seconds here first. This validator answers the blunt, useful questions: is the file well-formed XML at all, is it actually a UBL Invoice, and are the fields present that any readable invoice needs — number, dates, both parties, lines and totals. Files are checked in server memory and discarded immediately, which is the appropriate way to treat a document carrying names, amounts and bank details. It earns its keep in two situations especially: a small business generating its first UBL invoices from a template or an unfamiliar ERP module, and a developer testing an export pipeline who wants a fast outside opinion on the output before pointing it at the real network.

What a structural check is — and what Schematron is

Honesty matters here. The official Peppol BIS Billing 3.0 validation is a Schematron rule set: hundreds of business rules checking things like whether VAT category codes are consistent and the tax totals add up to the line sums. This tool does not run those rules. Read the two outcomes accordingly: a fail here is definitive — a file that does not parse, or lacks mandatory fields, will fail everywhere, so fix it before sending. A pass here means the shape is usable, not that every business rule is satisfied; the network can still reject it for a rule-level violation. Structural first, Schematron after, is the natural order of checking. The boundary is deliberate, not lazy: the official rule sets are versioned and centrally maintained, and running them properly is the job of the Peppol infrastructure itself — imitating that badly would serve you worse than naming the limit plainly.

The failures we actually see

Most rejected files fall into a handful of patterns. The file is a credit note rather than an invoice — a different UBL document type this validator does not cover yet. It is a Factur-X PDF rather than raw XML — the invoice is embedded inside a PDF and needs extracting first with the Factur-X tool on this site. It was truncated or re-encoded somewhere along an email journey, so the XML no longer parses. Or an ERP export left mandatory party or total fields empty because a master-data record was incomplete. The validator names what is missing, which usually points straight at which of these happened. A subtler variant is worth knowing: a file that opens fine in a text editor can still fail to parse because an email gateway or a copy-paste step changed its character encoding — invisible to the eye, fatal to XML. Re-export from the source system rather than repairing by hand.

The same parser as the PDF renderer — and when to call your provider

This validator shares its parser, line for line, with the e-invoice to PDF tool here. That gives you a dependable little workflow: validate the file, then render it and read the invoice the way a human would — a wrong IBAN or an absurd total is often easier to spot on a page than in XML. And know where the boundary lies: if a file passes here, renders sensibly, and is still rejected by the Peppol network, the problem sits at the business-rule or transmission level. That conversation belongs with your access point or software vendor, who can see the official validation report — bring their error message with you, because it names the exact rule that fired.

What this actually checks

This confirms the file is well-formed XML, has a UBL Invoice root, and has the fields a readable invoice needs: an invoice number, dates, supplier and customer parties, line items, and totals. It's a structural sanity check, not the official Peppol BIS Billing 3.0 Schematron validation — it won't catch every business-rule violation (e.g. tax totals that don't add up correctly), only whether the shape is usable at all.