Validating a Peppol invoice and delivering it are two different activities that accountants and software teams often consider to be one and the same. Validation means checking the invoice XML file, or machine-readable data file, against the requirements of the European e-invoice standard EN 16931. It shows whether the structure and fields are correct, but does not move the invoice anywhere. Delivery means the actual transmission of the invoice to the recipient via the Peppol network, which is the responsibility of a Peppol-certified Access Point. For manual verification, a free European Commission e-invoice validation tool, which verifies the invoice in UBL or CII format. However, for the actual sending, you need to contact a Peppol-certified service provider whose the access point validates the outgoing message one more time and finds the recipient before transmission.
Why are two tools usually needed, not one?
This confusion arises because both activities use the same word „validation.” A free validator answers the question „is this file correct?” An access point answers the question „where and how does this file actually end up?”. Peppol Interoperability Framework describes it as a 4-corner model: the seller sends an invoice to its access point, which finds the buyer's access point through a central addressee register and forwards the invoice securely. Each sending access point is obliged to check the outgoing message against Peppol BIS rules before sending. This check is part of the sending process, not a separate service that you manually order. The free validator itself does not forward the message anywhere and does not check the existence of the recipient. This is a quality check before sending, not a forwarding service, like tool description clearly shows.
Best validation options by use case
It is most practical if you check the invoice manually before sending it. European Commission eInvoice Validator, which is free and accessible from a web interface, REST interface, or SOAP interface. Developers who build validation directly into the software need official Peppol Schematron artifacts, or rule files that check each BT (Business Term) code for compliance with the standard, and update history shows when these rules change. In a production environment where invoices are actually sent, your access point performs a third, mandatory check: it automatically validates the outgoing message before it even reaches the network. You don't have to order this third check separately, but you should know that it's happening. Otherwise, it will look like the manual validation and the actual sending are the same process.
What to check on a Peppol invoice before sending?
Before sending, it is worth going through a simple checklist. Check that the XML file corresponds to the UBL or CII structure and that all mandatory fields of EN 16931 are filled in. Review the Peppol BIS identifiers, document type codes and schemas that you Changes in version 3.0.21 partially updated, for example, the Electronic Address Scheme (EAS) code list was corrected. Check the buyer's endpoint identifier (endpoint ID) and its schema, as an incorrect schema means that the access point cannot find the recipient. Add the buyer reference or purchase order (PO) reference if the buyer requires it. Review the VAT breakdown by line and summary, the invoice total and currency, and check additional country-specific rules. In Latvia, the XML structure must comply with the national standard, which based on Peppol BIS Billing 3.0 specification. If any of these are missing or in the wrong format, the validator will reject the invoice before it is sent. Better there than at the recipient's.
How to choose a Peppol invoicing tool or access point?
Your needs will vary depending on how many invoices you send and how.
| User | What do you need most? |
|---|---|
| Manual sender on few bills | Simple web interface, validation before sending, clear sending status |
| Accounting software user | Built-in Peppol connection that automatically updates rules |
| ERP/API team | Direct connection to the access point, support for multiple document types, audit trail or sending log |
You can check which service provider to choose From the list of OpenPeppol certified service providers, which was updated on August 28, 2026. The list shows whether the provider is certified as an Access Point (AP), a Service Metadata Provider (SMP), or both. An important nuance: the country shown in the list indicates the legal location of the provider, not the region where it actually provides the service, so Estonian accounting software can use an Access Point registered in Belgium without any problems. After checking the certificate, see what document types the provider supports, whether it offers recipient capability search, how fast it is to deploy, whether you can export the sending log for auditing, and how it displays error messages. These last two are what distinguish the tool used by a good provider from a bad one.
What to ask about the Peppol BIS Billing 3.0.21 August 2026 change?
The current version is Peppol BIS Billing 3.0.21, which published on May 20, 2026 and became mandatory on August 17, 2026. This version uses the updated version 1.3.16 of the EN 16931 validation rules, published on April 10, 2026. If your validator or invoicing software has not updated these rules, it may show an incorrect result, even though the invoice does not actually meet the new requirements. The version also added an optional profile „Billing with Response”, which allows the buyer to send a response to the invoice, but this profile requires a separate SMP registration. Just because your regular invoice sending works doesn't automatically mean the buyer can or will use this response profile. If the provider offers this feature, clearly ask if registration has been done, not just "is it supported".
How do shipping options differ in Estonia and Latvia?
In Estonia, the system operates on a register basis. As of July 1, 2025, an accounting entity may register your status and e-invoice reception channel details in the commercial register, indicating that he wishes to accept only machine-readable invoices. Once the buyer has registered himself in this way, he may request an e-invoice from the seller, which is duly formatted, when it complies with EN 16931-1 standard, unless the parties have agreed otherwise. This does not mean that all Estonian B2B invoices must automatically go through Peppol. The agreement on the format and shipping conditions remains between the parties, unless the law provides otherwise. Therefore, the very first step for the seller is to check whether the buyer has requested an e-invoice in the register, and only then choose the appropriate shipping method.
In Latvia, the situation is more clearly defined in terms of time due to the law. Structured e-invoices are mandatory from January 1, 2025 in transactions between the state and businesses (G2G, B2G, G2B). The transmission of e-invoice data to the State Revenue Service (VID) became mandatory in the same segment from 1 January 2026.. In the B2B sector, i.e. between businesses, the submission of data to the VID is currently voluntary and will remain so until 31 December 2027, but From January 1, 2028, structured e-invoice and VID notification will become mandatory for all companies registered in Latvia. also on B2B invoices. In practice, the invoice must be submitted to the VID within five working days at the latest after sending it, either by uploading the XML file to the Electronic Declaration System (EDS) or via API directly from the accounting software. VID recommends before submitting check the XML file with the European Commission validation tool. This is one of the most specific places where a free validator and mandatory reporting intersect.
A five-minute test before switching invoicing software
Before you decide to change your software or access point, do one simple test. Create a typical invoice that includes all the usual fields, such as VAT, references, and buyer information. Validate it With the European Commission tool, to eliminate obvious structural errors. Check that the buyer's endpoint schema and identifier are correct and that the provider supports exactly the document type you need. Send one control invoice to the actual or test recipient and keep the sending status as proof. This will be useful if there is a later dispute about whether the invoice was delivered. If you operate in Latvia, also check that this invoice is correctly forwarded to the VID, as sending in the Peppol network and getting the data to the tax authorities are two separate steps that are worth reviewing separately.
FAQ
Why are two tools usually needed, not one?
The free validator checks the file for correctness, the access point forwards the invoice to the recipient. Both activities use 'validation', but are different processes.
What to check on a Peppol invoice before sending?
Check XML structure, EN 16931 mandatory fields, Peppol BIS identifiers, buyer endpoint identifier, references, VAT distribution, and country-specific rules.
How to choose a Peppol invoicing tool?
The choice depends on the volume of invoices: for a small number of invoices, a simple web interface, a built-in connection for the accounting software user, a direct connection to the access point for the ERP/API team. Check the service provider from the OpenPeppol certified list.
What to ask about the Peppol BIS Billing 3.0.21 change?
Ask if the software has been updated to rules 1.3.16 and if the optional profile 'Billing with Response' with SMP registration is supported.