ARLing

Peppol Invoice Validation Errors Explained

When a business sends an electronic invoice over the Peppol network, the file has to pass a set of automated business rules before the recipient's system will accept it, and a peppol invoice rejected at this stage almost always comes back as a short code rather than a plain sentence explaining the problem. That short code is what shows up in the accounting software as a peppol validation error, and two rule books apply to the same file at once. The European standard EN 16931 defines the semantic data model of the core invoice and splits its checks into core rules labelled BR and the calculation and consistency rules labelled BR-CO. Peppol BIS Billing 3.0, the specification used directly in Slovakia and across the Peppol network, is built on top of EN 16931 and adds its own PEPPOL-EN16931-R and PEPPOL-COMMON-R rules for messages sent through the network itself. Every EN 16931 validation error therefore carries a BR code, and that code is the starting point for fixing the file before resending it.

Two layers of rules behind every BR code

EN 16931 alone lists 58 core BR rules plus 24 calculation and consistency rules under the BR-CO prefix. Peppol BIS Billing 3.0 does not replace these rules, it sits on top of them: the November 2025 release adds 41 further checks under the PEPPOL-EN16931-R and PEPPOL-COMMON-R codes, and part of that set applies only to specific countries rather than to every Peppol invoice.

Errors on the invoice number and the totals

The plainest example is BR-02: an invoice must carry an invoice number, referenced as BT-1 in the data model, and a file with that field empty is rejected outright rather than flagged as a warning.

Most totals errors are less about a missing field and more about arithmetic. BR-CO-10 requires the sum of the individual invoice line net amounts, BT-131 on each line, to equal the header line net total, BT-106. BR-CO-15 is reported even more often: the invoice total with VAT, BT-112, must equal the invoice total without VAT, BT-109, plus the total VAT amount, BT-110.

VAT category and currency code errors

Every invoice line and VAT breakdown carries a category code from the UNTDID 5305 list: S for standard rate, Z for zero rate, E for exempt, AE for reverse charge, K for an intra community supply, G for export outside the European Union, O for not subject to VAT, L for the Canary Islands and M for Ceuta and Melilla.

Each of these letters triggers its own group of checks: S, Z, E, AE and G each carry ten rules, O carries fourteen, and K carries twelve rules under the BR-IC prefix; the codes BR-K, BR-IG and BR-IP do not exist in the official rule set.

Currency causes a similar class of mistakes. BR-CL-04 requires the invoice currency code to follow the ISO 4217 alpha-3 list, so the field must read EUR rather than the word euro or a currency symbol, and a symbol in that field fails validation even when every amount on the invoice is correct.

Allowance and charge amounts

Discounts and surcharges on a line are checked for internal consistency rather than just for a value being present. PEPPOL-EN16931-R040 requires that, whenever both a base amount and a percentage are given for an allowance or a charge, the amount itself must equal the base amount multiplied by the percentage and divided by 100, so a discount figure that does not match the percentage typed next to it fails this rule even though both numbers look reasonable on their own.

Frequently asked questions

Why does my invoice fail even though every field looks filled in?

A filled field is not the same as a correct one: most rejections at this stage come from arithmetic checks across related fields rather than from a field being left empty, with BR-CO-15 the most frequently reported example.

Is EUR the only currency code Peppol invoices accept?

BR-CL-04 does not name a single currency: it requires whichever currency is used to be written as its ISO 4217 alpha-3 code, so EUR is correct for the euro while any other currency needs its own three-letter code from the same list.

Why does the validator report BR-IC instead of BR-K for an intra-EU supply?

Category K, the intra community supply code, is checked under the BR-IC group of twelve rules rather than under a code named after the letter itself; codes such as BR-K, BR-IG or BR-IP do not exist in the official rule set, so searching for them by that name will not turn up any documentation.

Conclusion

Reading the BR code correctly saves more time than rerunning the export and hoping the second attempt passes: a BR-CO code points to a calculation or consistency mismatch, most often a totals check, a PEPPOL-EN16931-R code points to a network-specific rule, and both name the exact business term you need to check in the accounting software before resending the file. Slovakia has no separate CIUS or schema of its own; it uses Peppol BIS Billing 3.0 directly, extended by the national PASR requirements that mainly set the mandatory network identifier, so the same BR and PEPPOL codes described here apply there too, alongside that extra identifier requirement; the eFaktúra overview covers the identifiers Slovak businesses need alongside these validation rules.

Sources. The facts in this note are numbered after our internal fact list and were checked on the publication date. ARLing is not a bank; a clean check result is no guarantee that the bank accepts the payment. If a source has changed since, write to andrej@arling.sk and we will correct this page.