How to Check an E-Invoice Before Your First Peppol Send

The short answer: before you send a real invoice, run the same file through three separate checks. The Peppol specification treats syntax validation, EN 16931 data model validation and Peppol’s own extra rules — the CIUS, or Core Invoice Usage Specification — as three distinct layers. An XML file that parses cleanly is not yet a compliant invoice. As at 16 September 2026 you should be working with version 3.0.21, published on 20 May 2026 and mandatory from 17 August 2026, together with the validation artefacts 1.3.16 released on 10 April 2026. In practice, check four things: the buyer’s electronic address and its scheme identifier, the mandatory fields, the chain of totals from line level up to the amount due, and the profile identifiers. Only then send a test invoice through the Peppol Testbed — and after that, to the buyer.

Which Three Rulebooks Must One Invoice Satisfy?

The PDF can look flawless: right logo, correct totals, polite payment term. The e-invoice still gets stuck in validation. The reason is simple. An e-invoice has to satisfy three rulebooks at once, written in different places and for different purposes.

The first is national invoicing law. If you invoice from an Estonian company, the VAT Act requires the invoice to be issued within seven calendar days in the ordinary case, and to carry the data the law lists. None of that changes because the invoice now travels as a machine-readable data stream instead of paper. The second is EN 16931 — the European semantic data model for e-invoices — which says which fields must be there and what logic must hold. The third is Peppol’s additional constraints, which are narrower than EN 16931.

In Estonia this has a concrete consequence. Since 1 July 2025, an accounting entity listed in the business register as an e-invoice recipient may require an e-invoice from its seller, and an e-invoice conforming to EN 16931-1 is presumed compliant unless the parties have agreed on another relevant standard. So “we’ll send a PDF for now” is no longer always your call to make.

Why You Start With the Buyer, Not the XML

Most failed first sends don’t fail on arithmetic. They fail on addressing. So settle three things with the buyer before a developer touches the XML.

The first is the channel. Confirm that the buyer receives invoices over the Peppol network and that their side is actually registered to receive. If the buyer wants an invoice response — a message back about the invoice’s status — Peppol BIS Billing 3.0 handles that through a separate optional profile 02, which needs its own SMP registration. SMP, the Service Metadata Publisher, is the directory that tells the network what a participant can receive. The plain invoice profile does not include profile 02.

The second is the electronic address together with its scheme identifier. Peppol requires that both seller and buyer have an electronic address (EndpointID) and that the schemeID attached to it comes from Peppol’s EAS code list — EAS being the Electronic Address Scheme list, the catalogue of allowed address types. The attribute itself is mandatory, not advisory. And there’s a fresh trap here. Version 3.0.21 fixed an incorrect code list reference, which removed 14 EAS codes that were technically usable before. If a scheme code has been sitting in your ERP or accounting software on a partner card since forever, check it. A value that worked yesterday can throw an error today.

The third is the reference. Peppol’s rule PEPPOL-EN16931-R003 requires the invoice to carry either a buyer reference or a purchase order reference — and missing both is a fatal-level error. Ask the buyer directly: do we put a purchase order number on the invoice, or an agreed buyer reference value, and where exactly does it come from?

What Happens After Your ERP Hands Over the Invoice?

The chain is shorter than it looks. Your ERP or accounting software passes the invoice data over an API to your e-invoice operator, who runs a certified Peppol Access Point. The operator builds or checks the UBL-format XML — UBL, Universal Business Language, being the XML syntax Peppol uses — runs it through validation, finds the buyer’s operator from the electronic address, and delivers the invoice across the Peppol network. The buyer’s operator hands it into the buyer’s system, where the data lands straight on the accounts payable desk. If your operator validates at the moment of sending — synchronous validation — the error comes back immediately in the API response. That’s your cheapest test.

Which Fields Must Be Present in the Invoice and the XML?

Work this list through on a real invoice, not on a sample file. Peppol BIS Billing 3.0 requires, among other things:

• a specification identifier and an invoice number;
• the issue date and the invoice type code;
• the invoice currency;
• the seller’s and buyer’s names and the postal address of both parties;
• at least one invoice line.

On top of that: what was sold (the item or service name on the line), the payment details the buyer pays against, VAT registration numbers where these are required, and the buyer reference or order number. Every invoice line must carry exactly one VAT category. If one line mixes a standard-rated part and an exempt part, split the line in two.

In What Order Does Peppol Check the Totals?

The totals check isn’t freeform. Peppol’s chain of document totals is mandatory and runs exactly like this:

1. Sum of line net amounts — the net amounts of all invoice lines added up.
2. Total without VAT = sum of line net amounts − document-level allowances + document-level charges.
3. Total with VAT = total without VAT + total VAT amount.
4. Amount due for payment = total with VAT − prepaid amount + rounding amount.

The VAT breakdown is checked separately. Each VAT category amount must be the taxable base × the rate / 100, rounded to two decimals, and the sum of those amounts must equal the invoice’s total VAT amount. The most common failure here is a mismatch in logic: the ERP calculates VAT line by line and rounds each line, while the invoice summary calculates per category. One cent drifts apart and the invoice is rejected. Check which way your system works before you send.

Checking the XML: Profile, Codes, Dates and Rounding

The profile identifiers must be exactly what the specification asks for. For a normal invoice and a credit note, the base value of CustomizationID is `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0` and the ProfileID is `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`. Don’t append a version suffix of your own invention. Rule PEPPOL-EN16931-R004 was tightened in version 3.0.21, and a CustomizationID carrying version information now returns a clear error.

Codes and dates are just as literal. The currency code must come from the current ISO 4217 list. Version 3.0.21 removed ANG and BGN from it and added XCG. Dates follow the specification’s semantic data types in the form YYYY-MM-DD, so 16 September 2026 is `2026-09-16` in the file, not `16.09.2026`.

On rounding, one thing is worth keeping in mind. Line net amounts, the tax breakdown amounts, the document totals, the amount due, and allowance and charge amounts may carry at most two decimals. The unit price has no such limit — the documentation gives 10000.1234 as an example. A precise unit price is allowed, but the end amounts have to be cent-exact and they have to reconcile with each other.

Which Errors to Fix First

The validator returns three kinds of error, and it pays to fix them from the top down:

1. XSD or syntax errors. The file doesn’t match the UBL schema: an element in the wrong place, a missing namespace, a value of the wrong type. Until these are cleared, the remaining checks never reach the content.
2. BR and BR-CO errors. These come from the EN 16931 rules: a missing mandatory field, a broken calculation, a forbidden code.
3. PEPPOL and UBL-SR errors. Peppol’s additional constraints and syntax rules — PEPPOL-EN16931-R003, for instance, or cardinality limits. Country-specific rules sit here too.

Read the warnings as well, not only the errors. In version 3.0.21, rules PEPPOL-COMMON-R052 and R053 were promoted from warnings to errors, because they now apply to all profiles. Today’s warning is quite often the next release’s error.

What Your Test Pack Should Contain

One correct sample invoice proves nothing. Build five cases and run all of them through the Peppol Testbed or your operator’s validator:

• a plain invoice at the standard Estonian VAT rate;
• an invoice with a document-level allowance or charge;
• an invoice carrying several VAT categories at once (standard rate plus exempt sales, for example);
• a credit note or correction invoice with a reference to the original invoice;
• a cross-border invoice, if you send them at all — the buyer’s electronic address, scheme code and tax identifiers behave differently in another country.

Keep those files. When a new version of the validation artefacts lands six months from now, five minutes will tell you whether something broke.

What a Passed Validation Still Doesn’t Prove

A passed validation proves one thing: the file matches the syntax, the EN 16931 data model and Peppol’s additional rules. It does not prove that the invoice arrives, or that the buyer pays it.

Four things need checking separately. Whether the buyer is genuinely able to receive, and whether you used their correct electronic address. Whether the buyer’s internal rules require a purchase order number — a wrong or missing number leaves the invoice parked in their approval flow even though Peppol was perfectly happy. Whether the invoice content matches the contract: prices, quantities, payment term. And whether the tax treatment is right in substance — the validator checks that the VAT calculation is internally consistent, not that you picked the correct VAT category.

The first send goes most calmly when you agree with the buyer on one specific invoice to watch together: you confirm it went out and validated, they confirm it reached their system and is in the approval flow. After that, the rest is only a question of volume.

Also available in: eesti keeles · latviski · lietuviškai

Last reviewed: 16 September 2026