A validation error names a rule identifier and, usually, the business terms involved. Rules starting BR- come from the European standard EN 16931; rules starting PEPPOL-EN16931- are additional constraints of Peppol BIS Billing 3.0. The identifier tells you which test failed. The business term numbers (BT-, BG-) tell you which values to look at — the catalogue is in invoice business terms.
Validation is performed by Schematron rule sets published with the specification, and every competent access point runs them before transmission. The setup is described in the testing and validation stack. This page is the other half: what the most frequent rules test, in the published wording, and why invoices fail them.
The arithmetic rules (BR-CO)
The BR-CO rules are the calculation constraints. They are where most rejections come from, because they test the relationships between amounts that ERPs often compute independently.
| Rule | What it requires |
|---|---|
| BR-CO-10 | Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131) |
| BR-CO-13 | Invoice total amount without VAT (BT-109) = Σ line net amounts (BT-131) − document-level allowances (BT-107) + document-level charges (BT-108) |
| BR-CO-14 | Invoice total VAT amount (BT-110) = Σ VAT category tax amount (BT-117) |
| BR-CO-15 | Invoice total amount with VAT (BT-112) = BT-109 + BT-110 |
| BR-CO-16 | Amount due for payment (BT-115) = BT-112 − Paid amount (BT-113) + Rounding amount (BT-114) |
| BR-CO-17 | VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) × (VAT category rate (BT-119) ÷ 100), rounded to two decimals |
| BR-CO-18 | An Invoice shall at least have one VAT breakdown group (BG-23) |
Why they fail. The pattern is nearly always the same: the ERP rounds per line, per tax code and per document in a different order from the one the standard assumes, or it carries more than two decimals somewhere in the chain. The standard computes VAT per VAT category on the summed taxable amount (BR-CO-17), not per line. An ERP that calculates VAT on each line and adds the results will be a cent away on some invoices, and BR-CO-14 or BR-CO-15 catches it.
A five-cent BR-CO-17 failure
Ten invoice lines, each with a net amount of €2.50, all at 21% VAT.
- VAT per line, as the ERP computes it: €2.50 × 21% = €0.525, rounded€0.53
- (ERP total VAT: 10 × €0.53)€5.30
- Taxable amount for the 21% category (BT-116): 10 × €2.50€25.00
- VAT the rule expects: €25.00 × 21%€5.25
Difference, enough to fail BR-CO-17 and then BR-CO-14€0.05
Line-level rounding pushes every line in the same direction whenever the third decimal is 5 or more, and the error grows with the number of lines. The fix is to calculate VAT on the category total, the way the rule does, rather than adjusting the XML. Figures illustrative.
Decimals. The BR-DEC rules cap amounts at two decimals — for example BR-DEC-09 for the sum of line net amounts (BT-106). Unit prices may carry more; line totals and document totals may not.
The VAT breakdown rules (BR-S, BR-Z, BR-E, BR-AE …)
Each VAT category has its own family of rules, and they test the breakdown per category and rate, not the totals.
- BR-S-08 (standard rated) — for each rate, the taxable amount in the breakdown must equal the line net amounts at that rate, plus document-level charges, minus document-level allowances at that rate. BR-Z-08 is the zero-rated equivalent.
- BR-S-09 — the tax amount for a standard-rated breakdown must equal taxable amount × rate.
- BR-E-10 (exempt) and BR-AE-10 (reverse charge) — a breakdown in that category must carry a VAT exemption reason code (BT-121) or reason text.
Why they fail. A document-level discount that is not given a VAT category and rate cannot be allocated to any breakdown, so totals reconcile but BR-S-08 does not. Exempt and reverse-charge invoices fail BR-E-10 or BR-AE-10 when the ERP's tax code maps to the right category but carries no exemption reason. The mapping is covered in VAT exemption reason codes and, upstream of it, in VAT determination on a structured invoice.
The mandatory content rules (BR-01 … BR-16)
These test presence rather than arithmetic, and they rarely fail once a mapping is built — until a new customer or a new document type arrives.
| Rule | Published wording |
|---|---|
| BR-01 | An Invoice shall have a Specification identifier (BT-24) |
| BR-02 | An Invoice shall have an Invoice number (BT-1) |
| BR-05 | An Invoice shall have an Invoice currency code (BT-5) |
| BR-06 / BR-07 | The Seller name (BT-27) and Buyer name (BT-44) must be present |
| BR-08 / BR-10 | The Seller postal address and Buyer postal address (BG-8) must be present |
| BR-16 | An Invoice shall have at least one Invoice line (BG-25) |
A customer created in the ERP with a name and a VAT number but no structured postal address will pass every internal check and fail BR-10 on the first invoice.
The Peppol rules (PEPPOL-EN16931-R…)
Peppol BIS Billing 3.0 adds its own constraints on top of the standard. The ones that generate most rejections:
| Rule | Published wording, in short | Usual cause |
|---|---|---|
| PEPPOL-EN16931-R001 | Business process MUST be provided | Profile identifier missing from the mapping |
| PEPPOL-EN16931-R003 | A buyer reference or purchase order reference MUST be provided | Customer requires a reference that was not captured at order entry |
| PEPPOL-EN16931-R008 | Document MUST not contain empty elements | Mapping emits a tag for a field that is blank |
| PEPPOL-EN16931-R010 / R020 | Buyer / Seller electronic address MUST be provided | Endpoint identifiers missing from master data |
| PEPPOL-EN16931-R040 | Allowance/charge amount must equal base amount × percentage / 100 | Discount amount rounded separately from its percentage |
| PEPPOL-EN16931-R120 | Invoice line net amount MUST equal quantity × (net price ÷ base quantity) + charges − allowances | Line total taken from the ERP instead of recomputed |
| PEPPOL-EN16931-R130 | Unit code of price base quantity MUST be same as invoiced quantity | Price per box, quantity in pieces |
R003 deserves a note of its own because it is a business-process failure rather than a technical one. Many public buyers will not process an invoice without their reference, and the specification makes one of the two mandatory. If sales order entry does not capture the buyer reference, no amount of mapping will produce it.
R010 and R020 are master data: the electronic address and its scheme for each party. National rules add to them — Greek parties, for example, must use their tax identification number under scheme 9933. How addresses work is in addressing on Peppol.
Fix it upstream
- BR-CO-, BR-S-08, BR-S-09: the tax calculation — compute VAT per category on the summed taxable amount, and give every document-level allowance or charge a VAT category and rate.
- BR-DEC-: rounding — round line and document amounts to two decimals before serialising, not after.
- BR-E-10, BR-AE-10: the tax code table — map each exempt and reverse-charge code to an exemption reason code.
- BR-08, BR-10, R010, R020: the customer and supplier master — structured addresses and electronic addresses with their schemes.
- R003: order entry — capture the buyer reference when the order is taken.
- R001, R008: the mapping — profile identifier present, no empty elements emitted.
Every one of these is cheaper to fix once in the source system than to correct invoice by invoice, and each correction made by hand in the XML leaves the ERP and the transmitted invoice disagreeing — which is a business controls problem in its own right.
