The term „PEPPOL-compliant” covers three different things, and software vendors often use it to mean all three together, even though they are separate things. The first is that the invoice content complies with the European standard EN 16931, a common data model that specifies which fields must be on the invoice. The second is that it complies with Peppol BIS Billing 3.0 rules (Business Interoperability Specifications), a more detailed set of rules that checks mandatory identifiers and the correctness of calculations. The third, and most often forgotten, is the actual network transmission: does the software have an Access Point through which the XML file, or machine-readable structured invoice, actually travels to the buyer, and is the buyer registered for this in the Peppol network. The PDF invoice that you send to the customer by email does not prove any of these three, because it is a regular file, not a Peppol invoice. On August 17, 2026, it will become mandatory Peppol BIS Billing version 3.0.21, so ask the software provider directly when and how this update will be implemented.

What to check before trusting a software provider?

Before you decide that your software "makes Peppoli", go through these five points:

  • BIS Billing version. Ask for a specific number, not “we support Peppoli”. Currently version 3.0.20, but From August 17, 2026 is mandatory 3.0.21.
  • Exportable structured XML. The software must be able to display the actual XML file, not just a PDF.
  • Mandatory identifiers and references. The invoice must contain the buyer's electronic address and the seller's electronic address; their absence is a fatal flaw. There must also be a buyer reference or order number, as just the company name, VAT number and amount are not enough.
  • Validation without fatal errors. Ask for a validation report, not a promise.
  • Documented shipping and receiving route. Who is the operator, what access point is used to transfer the invoice, and how does the buyer receive it?.

What evidence should I ask for from the software provider?

Send a direct list to the software provider and stick to it:

  • Sample invoice with actual customer data in XML format (based on your own or test account data).
  • Validation report, where you can see that PEPPOL-EN16931-R010 and R020 (buyer and seller electronic address) and R003 (buyer reference or order number) pass without a fatal error.
  • The name of the Access Point through which the bill is actually sent to the network.
  • What document types (invoice, credit note) does the software support and do they correspond to profile 01 (regular sales invoice).
  • Written confirmation of when it will be implemented 3.0.21 update. The update must be implemented before August 17, 2026.

If the answer is “we are Peppol certified” without these five points, it is marketing talk, not proof. The certificate confirms the general capabilities of the software, but does not prove that your specific account is set up, registered, and able to communicate with your buyer.

How to make a real test invoice?

The best way to make sure is to send a real, low-risk invoice, for example a 1200 euro invoice to a familiar buyer who already uses Peppol. First, find out the buyer's Peppol identifier, i.e. electronic address or their approved receiving channel. Send the XML through your software and record the sending status: arrival, acceptance, possible rejection. Ask the buyer to confirm that the invoice arrived in their system readable, not just that "something came". This is the only way to show that the invoice is actually moving, not just exported as a file.

What are the differences in Estonia, Latvia and Lithuania?

The rules are different in the three countries, and Peppol is not the only channel available anywhere.

In Estonia, the recipient of an e-invoice registered as an accounting entity may, from From July 1, 2025 request an e-invoice from the seller. Unless otherwise agreed, the invoice must correspond to EN 16931-1 standard. This is a content standard, not an obligation to use the Peppol network. XML that complies with the standard does not automatically prove that the software can also send invoices via Peppol.

In Latvia you have to start from From 1 January 2025 As a company registered in Latvia, prepare an invoice to be submitted to a state authority as a structured e-invoice. From From 1 January 2026 e-invoice data must also be sent to the State Revenue Service (SRS) in G2G, B2G and G2B transactions. The file must be in XML, which complies with Latvian national standard and Peppol BIS Billing 3.0, but the presence of a Peppol operator in itself does not fulfill the SRS reporting obligation if the operator does not have an interface for transmitting SRS data.

In Lithuania, they require SABIS rules from 4 February 2025, the supplier's invoice to the purchaser must comply with the EN 16931-1:2017 format. The invoice can be submitted via the Peppol network, the SABIS universal data interface or manual entry. Peppol is one option, not the only one.

How to maintain compliance even after launch?

Code lists and validation rules change regularly. Version 3.0.21 brings new electronic address schemes and specifies the specification identifier, which must be exactly `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`. If your software plans to support the new optional profile 02, where invoices are replied to with a separate response document, it will require a separate registration. The normal profile 01 registration does not automatically cover this.

Keep the following evidence to demonstrate compliance at all times: validation reports after each version upgrade, written confirmation from the software vendor that 3.0.21 has been implemented, sample XML with the actual shipping log, and correspondence with the buyer confirming receipt of the invoice. This way, on August 17, 2026, you won't be left with just hoping that the vendor has upgraded. You'll have proof of this on paper.

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.