A valid PDF doesn't mean a valid Peppol e-invoice

A PDF that looks perfect can still fail Peppol validation, because Peppol (the pan-European e-invoice delivery network) checks the structured data behind an invoice, not how it looks on screen. Before you send, you need to check three separate layers: the XML file's structure, whether its content meets EN 16931 (the European e-invoice content standard that sets out which data fields an invoice must contain), and Peppol's own business rules, which sit inside the BIS Billing 3.0 specification. According to openPeppol's documentation, a message counts as compliant if the currently active rules find no fatal errors. Warnings do not break compliance. Just as important: validation artifacts check the invoice message itself, not whether the buyer's system will actually accept or pay it. A green light at validation and "the invoice is paid" are still several steps apart.

What does the five-step check look like before you hit send?

This process works the same way whether you're using an ERP system, accounting software or an operator's portal:

  • Export the XML: generate a UBL or CII file (the two structured formats invoices are exchanged in). Without one, there's nothing to validate in the first place.
  • Run the schema and business-rule check: structural validation first, then Schematron rules (a language for checking the relationships between fields inside an XML file), which look at totals, codes, and how the fields tie together.
  • Fix fatal errors: openPeppol's rule is that a sender must not send a message that isn't BIS-compliant. That's a hard requirement, not a suggestion.
  • Check the recipient's Peppol capability: confirm the buyer is actually registered on the network and can receive the specific document type you're sending.
  • Keep the validation result: hold on to the report and the delivery confirmation. That's the first thing anyone will ask for when an invoice “disappears.”

Which validator does which job?

XSD, or XML schema (the file that defines what counts as valid XML), checks whether a file is correct XML at all: elements in the right place, required fields present. Schematron checks something else entirely: business rules and the relationships between elements, for example whether the sum of the line items matches the invoice total. Per the European Commission's explanation, Schematron doesn't check XML structure by itself, so pair it with a schema check, or use a tool that runs both at once. The Commission offers a free validation service for exactly this, no registration needed, and Latvia's tax authority points businesses to it directly before they submit an XML invoice to the VID. If you send invoices through an operator or accounting software that already validates internally, you don't need to run every single invoice through a separate tool by hand. That's fine for everyday use. But when you're testing new XML-generation logic, run it through a standalone validator anyway.

Reading the report: fatal error before, warning after

A fatal error means the invoice is not BIS-compliant and must not be sent. A warning means the invoice is technically acceptable but worth a second look. In practice, problems cluster around five spots: seller and buyer identifiers (wrong scheme or wrong registry code), VAT category and rate, line and total amounts (rounding errors slip in easily), the payable amount together with its currency code, and the reference number alongside the payment due date. If an invoice line reads €100 plus 22% VAT but the total-amount field shows a different number, the validator throws a fatal error, rightly so, because that figure goes straight into the buyer's accounting system.

How do you check delivery separately from validity?

A structurally correct invoice still isn't guaranteed to arrive. Checking Peppol's content and business rules is one thing; routing across the Peppol network is another. Before sending, check whether the buyer's endpoint actually supports the specific document type you're about to send. The Peppol Directory is a publicly searchable list of registered recipients, but keeping an entry current is up to the service provider, not a legal obligation, so a perfectly valid recipient can still be missing from it. If you're unsure, ask the buyer directly for their Peppol identifier rather than trusting that the Directory shows everything.

What changes in August 2026?

BIS Billing 3.0 version 3.0.20 (with its hotfix) has been mandatory since 23 February 2026, but version 3.0.21 becomes mandatory on 17 August 2026. The update fixes an error in the electronic address scheme (EAS, the code that shows which system a company's identifier is registered under) code list and removes 14 codes that no longer work, which means a check run against the old validator can now give you a false result. The same version adds an optional profile that lets a sender get a formal invoice response, but this requires a separate SMP registration (Service Metadata Publisher, the directory entry that tells the network where to route a company's invoices) and doesn't arrive automatically on every invoice. If you're running an off-the-shelf solution, ask your operator in writing when they're moving their validation artifacts to the new version. If you generate your own XML, update your validation rules before 17 August 2026. Otherwise your own software will keep approving invoices against rules Peppol no longer accepts.

Estonia and Latvia: local checks

In Estonia, a company entered the business register as an e-invoice recipient has been able, since 1 July 2025, to require sellers to send invoices in the EN 16931-1 standard. An invoice meeting that standard counts as correctly formatted, although the two parties can still agree on a different suitable standard instead. This does not make Peppol mandatory for every B2B invoice in Estonia; it just means a registered recipient can insist on the format.

Latvia's timeline runs on more layers. VID (Latvia's tax authority) explains that e-invoices have been mandatory for B2G, G2B and G2G transactions (business-to-government, government-to-business and government-to-government) since 1 January 2025, and submitting e-invoice data to VID itself became mandatory on 1 January 2026. Data has to reach VID within five working days of the invoice being sent. In the B2B segment, submitting that data remains voluntary until the end of 2027, but VID still recommends running the XML file through the same free European Commission validation service you'd use for a Peppol invoice before filing it. These are two separate obligations, content compliance and timely submission to VID, and they're worth tracking on two separate checklists rather than assuming your operator covers both without you checking.

FAQ

Does a valid PDF mean that the Peppol e-invoice is validated and suitable for sending?

No. Peppol validates the structured e-invoice message data (XML), not the PDF appearance. The XML structure, EN 16931 content, and Peppol/BIS Billing 3.0 business rules must be checked separately before sending.

What are the 5 steps before sending a Peppol e-invoice?

First, export the invoice to XML (UBL or CII). Then run a schema and business rules check. Fix fatal errors according to BIS compliance, check the recipient's Peppol capability, and save the validation report and confirmation.

What is the difference between schema (XSD) and business transaction (Schematron) validation?

XSD checks whether the file is correct XML: mandatory elements and structure. Schematron checks business rules and relationships between elements, for example, whether row and total amounts match.

What will change with the new version of BIS Billing 3.0 from August 17, 2026?

The new BIS Billing 3.0 version 3.0.21 will become mandatory on 17.08.2026. The change fixes an error in the Electronic Addressing Scheme (EAS) code list and removes 14 non-working codes that could give an incorrect result with the old validation logic.