ARLing

Peppol Invoice Rejected? Five Fields Worth Checking First

ARLing s. r. o. · 12 September 2026

A Peppol invoice rejected by the receiving side is almost never a random formatting glitch: it fails one specific, documented rule inside EN 16931, the European standard that defines the semantic data model of the core invoice, meaning which pieces of information an invoice must carry and how those values relate to each other. Peppol BIS Billing 3.0 then adds its own layer of checks on top of that standard, so a file that satisfies EN 16931 on its own can still be sent back once the Peppol rules run against it. For a small business that has never read a schematron error message before, the practical shortcut is not to study the whole specification line by line; it is to check five fields before the file leaves the accounting software: the invoice number, two totals that have to add up, the currency code, and one allowance calculation.

What EN 16931 and Peppol BIS Billing 3.0 Actually Check

EN 16931 is the European standard behind every Peppol invoice, and as already noted it sets out which pieces of information an invoice must contain and how those pieces relate to each other. Its own rules split into the core rules BR-01 to BR-65, of which 58 actually exist in the schematron, and the calculation and consistency rules BR-CO-01 to BR-CO-26, of which 24 exist.

Peppol BIS Billing 3.0 is a CIUS, a specification built on top of EN 16931 in the UBL 2.1 syntax, and it adds its own rules with the codes PEPPOL-EN16931-R and PEPPOL-COMMON-R on top of the standard's rules; in the release of November 2025 there are 41 of them, and some apply only to other countries, not Slovakia.

The Invoice Number and the Two Totals That Have to Add Up

The most basic rule in EN 16931 is also the simplest to check first. An invoice must carry an invoice number, formally BT-1, and the schematron text is direct: "[BR-02]-An Invoice shall have an Invoice number (BT-1)." A file where this field is left empty is rejected outright, regardless of whether the number is meant to be filled in later somewhere else in the process.

Another check worth looking at is a mismatch between the header and the line items. Rule BR-CO-10 requires that the sum of the invoice line net amounts, BT-131, equals the invoice line net amount total in the header, BT-106: "[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)." This is what happens when a discount or a rounding step gets applied at the line level in one part of the software and at the header level in another.

The third failure sits one level up in the same chain of totals. Rule BR-CO-15 requires that the invoice total with VAT, BT-112, equals the invoice total without VAT, BT-109, plus the total VAT amount, BT-110: "[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)." It is reported as the most commonly seen totals error of all, and a single cent of rounding difference is enough to trigger it.

Currency Code and the Allowance That Must Match Its Own Math

A fourth field to check even though it looks trivial is the currency code itself. Rule BR-CL-04 states: "[BR-CL-04]-Invoice currency code MUST be coded using ISO code list 4217 alpha-3." The field has to hold a three letter code such as EUR, never the word euro written out and never a currency symbol.

The fifth field belongs to the Peppol layer rather than to EN 16931 itself. Rule PEPPOL-EN16931-R040 requires that when a discount or a surcharge on the invoice carries both a base amount and a percentage, the stated allowance or charge amount has to match that calculation exactly: "Allowance/charge amount must equal base amount * percentage/100 if base amount and percentage exists." A percentage that was rounded in one field of the accounting software while the amount was rounded separately is enough to break that match.

Why the VAT Category Code Multiplies the Checks on Your Invoice

Behind these five fields sits a further source of trouble that rarely shows up as a single rejection message on its own. The VAT category code on each invoice line, taken from the UNTDID 5305 code list, decides which entire family of rules the schematron applies to that line: S for the standard rate, Z for zero rated, E for exempt from VAT, AE for reverse charge, K for an intra community supply, G for an export outside the European Union, O for a supply not subject to VAT, plus L for the Canary Islands and M for Ceuta and Melilla.

Rule groups exist for the categories S, Z, E, AE and G with ten rules each, and O carries fourteen. For code K the group is called BR-IC and carries twelve rules of its own, not BR-K, which does not exist in the official schematron at all, so guessing the group name from the category letter is a mistake worth avoiding.

Frequently asked questions

My accounting software already produces a UBL file. Why would it still fail these checks?

Producing a syntactically correct UBL file only shows the software followed the file format, not that the numbers and codes inside it satisfy rules such as BR-02 or BR-CO-10, and Peppol BIS Billing 3.0 adds its own rules on top of EN 16931 that a plain UBL export can still miss.

Which of the five fields is worth checking first if there is only time for one?

The invoice number mapped to BT-1 is the simplest to check by hand and the most fundamental, since an invoice without one fails rule BR-02 outright before any of the totals are even compared.

Do these checks apply the same way to every VAT category on the invoice?

The five fields matter regardless of category, but the category code itself decides which extra group of rules also runs on that line, so a line coded as K, G or O is checked against a different set of conditions on top of the five fields above.

Conclusion

Checking these five fields by hand in a text editor works for a single invoice, but the totals inside BR-CO-10 and BR-CO-15 get tedious to verify once a business sends more than a handful of files, because every line and every rounding step feeds into the same header sum. The rules themselves come from the public EN 16931 schematron and the Peppol BIS Billing 3.0 schematron built on top of it, so the exact wording behind any error a piece of software reports can be looked up rather than guessed at. For more on the rules that Peppol invoice validation applies, see the ARLing e-invoicing pages.

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.