“Peppol-compliant” hides three different things, and software vendors often fold all three into one sales line even though they're separate matters. The first is content compliance with the European standard EN 16931, the shared data model that sets out which fields an invoice has to carry. The second is compliance with the Peppol BIS Billing 3.0 rules (Business Interoperability Specifications), a tighter rulebook that checks mandatory identifiers and whether the totals actually add up. The third, and the one vendors most often skip past, is real network delivery: does the software have an Access Point through which the XML file, the machine-readable structured invoice, actually reaches the buyer, and is the buyer registered on the Peppol network to receive it? A PDF invoice you email to a client proves none of the three, because it's just a file, not a Peppol invoice.

From August 17, 2026, Peppol BIS Billing version 3.0.21 becomes mandatory, so ask your provider directly when and how that update lands in your account.

What should you check before trusting a vendor?

Before you accept that your software “does Peppol,” work through these five points:

  • BIS Billing version. Ask for the exact number, not "we support Peppol." Version 3.0.20 is current, but from August 17, 2026 version 3.0.21 becomes mandatory.
  • Exportable structured XML. The software has to be able to show you an actual XML file, not only a PDF.
  • Mandatory identifiers and references. The invoice needs both the buyer's and the seller's electronic address; leaving either one out is a fatal error. It also needs the buyer's reference or purchase order number — company name, VAT number and a total alone aren't enough.
  • Validation with no fatal errors. Ask for a validation report, not a promise.
  • A documented sending and receiving path. Who the operator is, which Access Point the invoice actually travels through, and how the buyer receives it on the other end.

What proof should you ask the vendor for?

Send the vendor a direct checklist and hold them to it:

  • A sample invoice built with real (or test-account) customer data, delivered as an XML file.
  • A validation report showing that PEPPOL-EN16931-R010 and R020 (buyer and seller electronic address) and R003 (buyer reference or purchase order number) pass with no fatal error.
  • The name of the Access Point that actually pushes the invoice onto the network.
  • Which document types the software handles, invoice, credit note, and whether they match profile 01 (a standard commercial invoice).
  • Written confirmation of when the 3.0.21 update goes live. It has to be in place before 17 August 2026.

If what comes back is "we're Peppol-certified" with none of these five attached, that's marketing copy, not proof. A certificate confirms the software's general capability. It does not confirm that your specific account is configured, registered, and actually able to exchange invoices with your buyer.

How do you run a real test invoice?

The surest way to know is to send one genuine, low-risk invoice, say €1,200, to a buyer you already know is live on Peppol. Start by finding out that buyer's Peppol identifier, meaning their electronic address, or their approved receiving channel. Send the XML through your own software and log the delivery status: arrived, accepted, or bounced back. Then ask the buyer to confirm the invoice landed in their system as a readable document, not just that "something came through." Only that confirms the invoice actually moves across the network, rather than merely exporting as a file on your end.

What's different in Estonia, Latvia and Lithuania?

The rules diverge across all three countries, and nowhere is Peppol the only channel available.

In Estonia, a buyer registered as an accounting entity can require sellers to send an e-invoice from 1 July 2025 onward. Unless the parties agree otherwise, that invoice has to meet the EN 16931-1 standard. That's a content standard, not a mandate to route the invoice through Peppol specifically. A compliant XML doesn't automatically prove your software can also send that same invoice over the Peppol network.

In Latvia, from 1 January 2025, a company registered in Latvia has to issue a structured e-invoice for anything billed to a government body. From 1 January 2026, e-invoice data for G2G, B2G and G2B transactions also has to be sent to the State Revenue Service (Valsts eiženemu dienests, SRS). The file has to be an XML that meets both the Latvian national standard and Peppol BIS Billing 3.0, but having a Peppol operator does not by itself satisfy the SRS reporting duty if that operator has no interface for submitting data to SRS.

In Lithuania, the SABIS rules require, from 4 February 2025, that a supplier's invoice to a contracting authority follow the EN 16931-1:2017 format. The invoice can go through the Peppol network, through SABIS's own universal data interface, or be entered manually. Peppol is one route among several here, not the only one.

How do you stay compliant after go-live?

Code lists and validation rules keep changing on their own schedule. Version 3.0.21 brings new electronic address schemes and tightens the specification identifier, which now has to read exactly `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`. If your software plans to add the new optional profile 02, where an invoice gets answered with a separate response document, that needs its own registration. A standard profile 01 registration does not cover it automatically.

Keep the following on hand so you can prove compliance whenever it's asked for: validation reports after every version update, written confirmation from your vendor on when 3.0.21 actually went live, a sample XML paired with a real delivery log, and correspondence from a buyer confirming receipt. That way, on 17 August 2026, you're not hoping your provider made the update in time. You've got paper proof that they did.

FAQ

What three things does the term "Peppol-compliant" imply?

The first is the compliance of the invoice content with the European standard EN 16931. The second is compliance with the Peppol BIS Billing 3.0 rules. The third is the actual network transmission: does the software have an access point through which the XML file travels to the buyer.

What do I need to ask the software provider before August 17, 2026?

Ask for the specific BIS Billing version (currently 3.0.20, mandatory 3.0.21 from 17.08.2026), the XML file to be exported, the validation report for mandatory identifiers, the name of the access point, and written confirmation of the implementation of the 3.0.21 update.

How do I make a real test invoice to verify Peppol delivery?

Send a low-risk invoice (e.g. 1200 EUR) to a buyer you know who already uses Peppol. Find out the buyer's Peppol identifier, send the XML through your software, record the sending status, and ask the buyer for confirmation that the invoice arrived legibly in their system.

How do Peppol requirements differ in Estonia, Latvia and Lithuania?

In Estonia, the recipient of an e-invoice may request an e-invoice that complies with the EN 16931-1 standard from 01.07.2025, but Peppol is not mandatory. In Latvia, a structured e-invoice is mandatory for invoices sent to state authorities from 01.01.2025, and data must also be sent to the SRS from 01.01.2026. In Lithuania, SABIS rules require the EN 16931-1 format from 04.02.2025, but Peppol is one option, not the only one.