“Peppol-compliant” isn’t one claim. It’s three separate things you can verify independently: the invoice’s XML file (a machine-readable file format, not a PDF) matches the Peppol BIS Billing 3.0 standard; the invoice travels through a certified access point (the gateway that connects your software to the Peppol network); and the recipient, whether a company or a public platform, actually processed the invoice, not just received it. Under the Peppol interoperability framework, the sending access point has to validate an outgoing invoice before it leaves, but that only proves technical correctness, not that your client actually approved it. BIS Billing version 3.0.21, published on 20 May 2026, became mandatory on 17 August 2026. If your software vendor talks about being “Peppol-ready,” ask for proof on all three points, not just one.

What does Peppol compliance actually mean?

The trouble with most e-invoicing sales pitches is that “Peppol-compatible” sounds like a single thing. It’s actually three independent layers, and a vendor can tick one box while quietly failing the other two.

The first layer is content: does the XML file follow the BIS Billing 3.0 rules for structure, fields and formatting. The second layer is transport: does the invoice actually move through a Peppol-certified access point, part of what’s called the four-corner model, where sender and receiver each connect only to their own service provider, a bit like how two different mobile carriers still route a call between each other’s customers. Under the OpenPeppol framework, an access point isn’t allowed to offer Peppol services until it has signed a Peppol Service Provider Agreement and passed a conformance test. The third layer is acceptance: did the recipient’s system actually pull the invoice into processing. Most disputes happen right here. Your software shows “sent,” but that doesn’t mean anyone on the other end ever opened it.

How do you check your software’s Peppol compliance in 20 minutes?

You don’t need an IT department for this.

  • Identify the real operator. Check your software contract or settings for who actually sends your invoices on the Peppol network. It’s usually not the accounting brand you see on screen. It’s the service provider working behind it.
  • Verify the legal name. Search that name in OpenPeppol’s list of certified service providers, last updated on 28 August 2026.
  • Ask for a live sample XML. Request one real invoice file generated right now, not a demo file that’s been sitting around for years.
  • Run an end-to-end test. Send that invoice to a real Peppol address and check whether you get a receipt confirmation, not just a send confirmation.

This is where most business owners get confused. Accounting software itself can’t be “Peppol-certified.” Only a service provider acting as an access point, or as an SMP (Service Metadata Publisher, the directory that tells the network where to deliver invoices for a given recipient), can hold that certification. If your software exports XML and shows a Peppol logo next to the invoice, that doesn’t automatically mean the invoice travels through a certified channel.

Check the certified service providers list for the exact legal name that signed a Peppol Service Provider Agreement, and note that the country field in that list shows where the provider is registered, not where it actually operates. A client registered in Estonia can be served by a provider officially registered somewhere else entirely.

Is the invoice format and validation evidence actually current?

Getting the XML format right once is one thing. Keeping it current is another. The Peppol BIS Billing v3 release notes confirm that version 3.0.21 was published on 20 May 2026 and became mandatory on 17 August 2026. Ask your vendor, in writing, whether their system already runs on this version.

The same release also added an optional profile called “Billing with Response,” which requires a separate SMP registration. In practice, that means basic support for sending a standard invoice doesn’t prove your software can handle every Peppol workflow a business partner might eventually require.

Was the invoice actually sent, or also received?

Send status, technical validation and actual processing are three different things, and the gap between them isn’t theoretical.

Lithuania’s public procurement system makes the point concretely. According to a notice from the national service centre operating under Lithuania’s Ministry of Finance, over 4,500 Peppol invoices sent to the SABIS platform in May 2026 were left completely unprocessed, accounting for 5% of that month’s Peppol volume. Of the invoices submitted with errors, only 13% were successfully resubmitted afterward, according to the same notice. The reason is simple: an invoice stayed unprocessed whenever there was no matching contract on file, or when the buyer, seller or contract code on the invoice didn’t match the data already sitting in the system. A “sent” status from Peppol checks none of that.

What should you check before going live with Peppol in each Baltic country?

Estonia

Since 1 July 2025, an entity subject to accounting rules, or its contracted e-invoice operator, can register with the Estonian Business Register to indicate that it only wants to receive machine-readable e-invoices. The same rule treats an e-invoice as properly formed if it follows the EN 16931-1 standard, though the parties involved can also agree on a different suitable standard between themselves.

Latvia

In Latvia, a structured e-invoice’s XML file has to meet the PEPPOL BIS Billing 3.0 specification. G2G, B2G and G2B invoices have been mandatory since 1 January 2025, and from 1 January 2026 the data from those invoices must be reported to the State Revenue Service (Valsts ieņēmumu dienests, VID). B2B invoices become mandatory e-invoices, with mandatory VID reporting, only from 1 January 2028; in between, from 1 January 2026 through 31 December 2027, that reporting stays voluntary.

Lithuania

In Lithuania, don’t assume SABIS confirms receipt automatically. Per the notice cited above, invoices go unprocessed specifically because of mismatched codes and contract data, so it’s worth checking your partner’s codes separately before sending invoices at any real volume.

What should you ask your software vendor today?

  • What’s the legal name of your Peppol access point, and is it listed in OpenPeppol’s certified providers list?
  • Which document profiles does your software support (Billing, Billing with Response, Self-Billing), and which of those require a separate SMP registration?
  • Does the system validate invoices against the BIS Billing 3.0.21 rules, and when did you actually roll out that version?
  • How can I check, before sending, whether the recipient’s Peppol address supports the document profile I’m using?
  • What error messages show up when an invoice goes unprocessed on the recipient’s side, and how will I find out about it?
  • What’s your update timeline whenever Peppol publishes a new mandatory version?
  • After a real test invoice, what proof do I actually get: a send confirmation, a receipt confirmation, or both?

FAQ

Mida tähendab Peppol-vastavus kolme kihina?

Esimene kiht on arve XML-vormingu vastavus BIS Billing 3.0 standardile. Teine kiht on transport läbi sertifitseeritud ligipääsupunkti. Kolmas kiht on saaja reaalne vastuvõtt ja menetlus, mitte ainult saatmise kinnitus.

Kuidas kontrollida tarkvara Peppol-vastavust 20 minutiga?

Tuvasta tegelik operaator lepingust, kontrolli tema nime OpenPeppol’i sertifitseeritud pakkujate nimekirjast, küsi kehtiv näidis-XML ja tee otsast lõpuni testarve saatmine reaalsele Peppol-aadressile.

Kas kontrollida tuleb ligipääsupunkti või tarkvara logo?

Sertifikaadi saab ainult teenusepakkuja, kes tegutseb ligipääsupunktina. Tarkvara Peppol-logo ei tõenda automaatselt sertifitseeritud kanalit – vaata alati OpenPeppol’i nimekirja.

Mida küsida tarkvara pakkujalt enne Peppol käivitamist?

Küsi ligipääsupunkti juriidilist nime, toetatud dokumendiprofiile, BIS Billing 3.0.21 versiooni juurutamise kuupäeva ja veateateid menetlemata jäänud arvete kohta.