A valid PDF does not mean a valid Peppol e-invoice.

Peppol (the pan-European e-invoice transmission network) validates the structured invoice data, not the PDF appearance. Before sending, three separate layers must be checked: the structure of the XML file, the content compliance with EN 16931 (the European e-invoice content standard, which specifies what data must be on the invoice), and Peppol's own business rules, which are summarized in the BIS Billing 3.0 specification. openPeppol'i according to the documentation A message is considered compliant if no fatal errors are found under the current rules. Warnings do not violate compliance. Equally important, however, is the fact that validation artifacts check invoice message, not whether the buyer's system actually approves or pays it. There are still several steps between green light validation and "invoice paid.".

What is the five-step check before pressing the send button?

A process that works regardless of whether you use ERP, accounting software, or operator portal:

  • Export XML: create a file from the invoice in UBL or CII format, without which validation is not possible at all.
  • Run the schema and business rules check: first a structural check, then Schematron rules (a language for checking internal XML relationships) that look at amounts, codes, and relationships between fields.
  • Resolve fatal errors: according to the openPeppol rule The sender must not send a message that is not BIS compliant. This is a hard rule, not a recommendation.
  • Check the recipient's Peppol capability: Make sure the buyer is registered online and can accept the specific document type.
  • Save validation result: Keep the report and delivery confirmation. This is the first thing you ask for when an invoice “disappears”.

Which validator is suitable for which job?

XSD, or XML Schema, checks whether the file is generally correct XML: square brackets in the right place, required elements present. Schematron checks something else: business rules and relationships between elements, for example, whether the sum of the rows equals the total amount of the invoice. According to the European Commission's explanation Schematron does not independently check the structure of XML, so use it in conjunction with a corresponding schema or a tool that does both. The Commission offers free validation service, where you do not need to register and which the Latvian Tax Board recommends directly before submitting an XML invoice to the VID. If you send invoices through an operator or accounting software that already performs validation internally, there is no need to manually check each invoice in the tool. This is reasonable in normal situations, but it is worth using a separate tool when testing the new XML generation logic.

Read the report: fatal error before, warning after

A fatal error means that the invoice is not BIS compliant and should not be sent. A warning means that the invoice is technically acceptable but deserves a closer look. In practice, the most common problems occur in five places: the seller and buyer identifiers (incorrect schema or incorrect registry code), the VAT category and rate, the amounts of the line and total values (rounding errors easily come apart), the amount due with the currency code, and the reference number with the payment due date. If the line of the invoice says 100 euros plus 22% VAT, but the total value field contains the wrong number, the validator will give a fatal error, and rightly so, because this amount goes directly to the buyer's accounting.

How to check delivery separately from validity?

A substantially correct invoice does not mean that it will actually get delivered. Checking Peppol's content and business rules is one thing, routing over the Peppol network is another. Before sending, it is worth checking whether the buyer's endpoint supports the specific document type you are sending. Peppol Directory is a publicly searchable list of registered recipients, but it is the responsibility of the service providers, not the obligation, to maintain it. Therefore, a perfectly correct recipient may not be listed. If in doubt, ask the buyer directly for their Peppol identifier, rather than just hoping that the Directory will show everything.

What will change in August 2026?

BIS Billing 3.0 version 3.0.20 (with hotfix) has been mandatory since February 23, 2026, but new version 3.0.21 will become mandatory on August 17, 2026. The change fixes an error in the Electronic Address Scheme (EAS – a code that indicates in which system the company identifier is registered) code list and removes 14 non-working codes, which is why a check with the old validator may give an incorrect result. The same version adds an optional profile that allows you to receive a formal confirmation (invoice response) for an invoice, but it requires a separate SMP registration and is not automatically included with every invoice. If you use a ready-made solution, ask your operator in writing when they will transfer the artifacts to the new version; if you create the XML yourself, update your validation rules before August 17, 2026, otherwise your own software will start approving invoices based on rules that Peppol no longer accepts.

Estonia and Latvia: local controls

In Estonia, a company that is entered in the commercial register as an e-invoice recipient may:, from July 1, 2025 require the seller to submit an e-invoice in the EN 16931-1 standard. An invoice that complies with this standard is considered to be correctly formatted, but the parties may also agree on another suitable standard. This does not mean that Peppol is mandatory for every B2B invoice in Estonia, but only that the registered recipient can request the format.

In Latvia, the timing is more complicated. VID (Latvian Tax Board) explains, that e-invoices are mandatory in B2G, G2B and G2G transactions from 1 January 2025, and submission of e-invoice data to VID became mandatory from 1 January 2026 – the data must be submitted no later than five working days after sending the invoice. In the B2B segment, submission of data is voluntary until the end of 2027, but VID recommends that before submitting the XML file, it be run through the same free validation service of the European Commission that you also use for the Peppol invoice. It is worth checking the two separate obligations (content compliance and timely submission to VID) in separate lists and not hoping that the operator will cover everything automatically.

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.