Peppol invoice validation and actual delivery are two separate jobs that accountants and software teams often lump together as one. Validation means checking the invoice’s XML file, the machine-readable data file, against the European e-invoicing standard EN 16931. That tells you whether the structure and fields are correct, but it doesn’t move the invoice anywhere. Delivery means the invoice actually reaching the recipient through the Peppol network, a job handled by a Peppol-certified Access Point. For a manual check, the free European Commission invoice validation tool checks invoices in UBL or CII format. To actually send an invoice, though, you need a connection to a Peppol-certified provider, whose Access Point validates the outgoing message once more and locates the recipient before forwarding it.

Why you usually need two tools, not one

The confusion comes from both jobs using the same word: “validation.” The free validator answers one question: is this file correctly built? An Access Point answers a different one: where and how does this file actually get there? The Peppol Interoperability Framework describes this as a four-corner model: the seller sends the invoice to its own Access Point, which finds the buyer’s Access Point through a central directory of recipients, then forwards the invoice securely. Every sending Access Point is required to check the outgoing message against Peppol BIS rules before it goes out. That check is part of the sending process itself. It’s not a separate service you order by hand. The free validator, on its own, never forwards anything and never checks whether the recipient actually exists. It’s quality control before sending, not a delivery service, as the tool’s own description makes clear.

The best validation option for each use case

If you’re checking an invoice by hand before sending it, the most practical choice is the European Commission’s eInvoice Validator, which is free and reachable through a web interface, a REST interface, or a SOAP interface. Developers building validation directly into software need the official Peppol Schematron artefacts, rule files that check every BT code (Business Term) against the standard, and the release notes show exactly when those rules change. In production, where invoices are actually sent, a third and mandatory check is run by your Access Point: it validates the outgoing message automatically before the message even reaches the network. You don’t have to order this third check separately, but you should know it happens. Otherwise it’s easy to assume manual validation and actual sending are the same process.

What to check on a Peppol invoice before sending

Run through a short checklist before you hit send. Confirm the XML file follows UBL or CII structure and that every mandatory EN 16931 field is filled in. Review the Peppol BIS identifiers, document type codes and schemes, some of which the 3.0.21 update revised. The electronic address scheme (EAS) code list, for instance, was corrected. Check the buyer’s endpoint ID and its scheme, because the wrong scheme means the Access Point simply won’t find the recipient. Add the buyer’s reference or purchase order (PO) reference if the buyer requires one. Review VAT breakdowns by line and by summary, the total invoice value and currency, and check for country-specific extra rules. In Latvia, the XML structure must match the national standard, which builds on the Peppol BIS Billing 3.0 specification. If any of this is missing or wrongly formatted, the validator will reject the invoice before it’s even sent, and that’s a better place for it to fail than at the recipient’s end.

How to choose a Peppol sending tool or Access Point

What you need depends on how many invoices you send and how.

User What matters most
Occasional sender, few invoices Simple web interface, validation before sending, clear delivery status
Accounting software user Built-in Peppol connection that updates its rules automatically
ERP/API team Direct connection to an Access Point, support for multiple document types, an audit trail (a log of what was sent)

To check who’s certified, look at OpenPeppol’s list of certified service providers, last updated on 28 August 2026. The list shows whether a provider is certified as an Access Point (AP), a Service Metadata Publisher (SMP), or both. One nuance worth knowing: the country shown in the list is the provider’s legal registration, not the region it actually serves. So an Estonian accounting package can use a Belgium-registered Access Point without any problem. Beyond checking certification, look at which document types the provider supports, whether it offers a lookup for recipient capability, how fast onboarding is, whether you can export a sending log for audit purposes, and how clearly it surfaces error messages. Those last two are what separate a good provider’s tool from a mediocre one.

What to ask about the August 2026 update to Peppol BIS Billing 3.0.21

New validation rules take effect

The version currently in force is Peppol BIS Billing 3.0.21, published on 20 May 2026 and made mandatory on 17 August 2026. It runs on an updated set of EN 16931 validation rules, version 1.3.16, published on 10 April 2026. If your validator or invoicing software hasn’t updated to these rules, it can show a false pass even though the invoice doesn’t actually meet the current requirements.

The optional Billing with Response profile

The version also added an optional profile called “Billing with Response,” which lets a buyer send a response back on an invoice, but that profile needs a separate SMP registration. Your regular invoice sending working fine doesn’t automatically mean the buyer can or will use this response profile. If a provider offers this feature, ask specifically whether the registration has been done, not just whether it’s “supported.”

How do sending rules differ in Estonia and Latvia?

Estonia: registering that you want e-invoices

Estonia runs on a registry-based system. As of 1 July 2025, an accounting-obligated entity can register its status and e-invoice receiving channel details in the business register, signalling that it wants to receive only machine-readable invoices. Once a buyer has registered this way, it can require the seller to send a properly formatted e-invoice, meaning one that meets the EN 16931-1 standard, unless the parties have agreed otherwise. This doesn’t mean every Estonian B2B invoice must now go through Peppol automatically. The format and terms of delivery are still up to the two parties, unless the law states otherwise. So the first step for any seller is to check whether the buyer has registered a requirement for e-invoices, and only then pick the right sending method.

Latvia’s timeline is set out more explicitly by law. Structured e-invoices have been mandatory since 1 January 2025 for transactions between government and business (G2G, B2G, G2B). Reporting e-invoice data to the VID (Valsts ieņēmumu dienests, the State Revenue Service) became mandatory in that same segment from 1 January 2026. In the B2B space, between businesses, reporting to the VID is currently voluntary and will stay that way until 31 December 2027, but from 1 January 2028, structured e-invoices and VID notification become mandatory for every company registered in Latvia, including B2B invoices. In practice, an invoice must be reported to the VID within five working days of being sent, either by uploading the XML file to the electronic declaration system (EDS) or directly from accounting software via an API. The VID recommends checking the XML file with the European Commission’s validation tool before submitting. This is one of the more concrete points where the free validator and the mandatory reporting requirement actually meet.

A five-minute test before switching invoicing software

Before you decide to switch software or Access Point, run one simple test. Build a typical invoice containing all the usual fields: VAT, references, buyer details. Validate it with the European Commission’s tool to catch any obvious structural errors. Check that the buyer’s endpoint scheme and identifier are correct and that the provider supports exactly the document type you need. Send one test invoice to a real or test recipient and keep the delivery status as proof. That record is worth having if a dispute later comes up over whether the invoice arrived. If you’re operating in Latvia, also check that this invoice correctly makes its way to the VID as well. Sending through the Peppol network and the data reaching the tax authority are two separate steps, and each is worth checking on its own.

FAQ

Miks on reeglina vaja kahte tööriista, mitte üht?

Tasuta valideerija kontrollib faili korrektsust, ligipääsupunkt edastab arve adressaadile. Mõlemad tegevused kasutavad ‘valideerimist’, kuid on erinevad protsessid.

Mida kontrollida Peppol-arvel enne saatmist?

Kontrolli XML-struktuuri, EN 16931 kohustuslikke välju, Peppol BIS identifikaatoreid, ostja lõpp-punkti identifikaatorit, viiteid, käibemaksu jaotust ja riigipõhiseid reegleid.

Kuidas valida Peppol-arvete saatmise tööriist?

Valik sõltub arvete mahust: väheste arvete puhul lihtne veebiliides, raamatupidamistarkvara kasutajale sisseehitatud ühendus, ERP/API-tiimile otseühendus ligipääsupunktiga. Kontrolli teenusepakkujat OpenPeppoli sertifitseeritud nimekirjast.

Mida küsida Peppol BIS Billing 3.0.21 muudatuse kohta?

Küsi, kas tarkvara on uuendatud reeglitele 1.3.16 ja kas toetatakse valikulist profiili ‘Billing with Response’ koos SMP-registreeringuga.