Common EN 16931 validation errors and how to fix them (BR-06, BR-CO-10, BR-S-…)
Under EN 16931 validation, a structured e-rēķins is checked against a set of business and technical rules. If the invoice doesn't meet the requirements, the validator points to an error code — for example, BR-06, BR-CO-10, or BR-S-09.
These codes help pinpoint exactly where the invoice falls short: in the seller's data, in the invoice amounts, in the VAT breakdown, in rounding, or in other structured fields.
How to read validation error codes
| Code group | What it usually means |
|---|---|
| BR-xx | Core rules on mandatory invoice fields |
| BR-CO-xx | Rules on amounts and data matching each other |
| BR-S-xx | Rules for transactions with the standard VAT rate |
| BR-DEC-xx | Rules on the allowed number of decimal places |
| BR-CL-xx | Rules on classifiers and code lists |
BR-06 — the invoice is missing the seller's name
What the error means: the invoice lacks the seller's name.
Where the problem is: the Seller name field, BT-27, doesn't contain the seller's legal name.
Why it happens: the legal name isn't filled in on the company's card in the accounting software, or only the registration number is passed into the XML file, without the name.
How to fix it: check the seller's data in your accounting software and make sure the legal name is filled in exactly in the field the software uses to generate the e-rēķins XML.
BR-CO-10 — the sum of the invoice lines doesn't match the stated line total
The net sum of the invoice lines must match the line total without VAT stated in the invoice. The most common cause is rounding, or a line that was changed after the total was already calculated. For the full list of causes, two worked examples, and a comparison with BR-CO-13/BR-CO-15, see the dedicated BR-CO-10 page.
BR-CO-15 — the total with VAT doesn't match the calculation
What the error means: the invoice total with VAT must match the amount without VAT plus the VAT amount.
Where the problem is: the field "Invoice total amount with VAT" doesn't match the calculation "Invoice total amount without VAT" + "Invoice total VAT amount."
Why it happens: the VAT was calculated from the wrong base, the VAT breakdown shows a different amount than the invoice total, or different fields were rounded inconsistently.
How to fix it: check three values: the amount without VAT, the VAT amount, and the amount with VAT. They must match mathematically at the XML level too, not only visually in the PDF invoice.
The BR-S group — errors in transactions with the standard VAT rate
BR-S rules apply when an invoice line, a document-level discount, or a surcharge uses the standard VAT category.
What the error means: the VAT category, the VAT rate, and the VAT breakdown aren't consistent with each other.
Common examples:
| Code | What it means |
|---|---|
| BR-S-01 | If the invoice has a line with the standard VAT category, the VAT breakdown must contain a matching standard VAT category |
| BR-S-05 | A line with the standard VAT category must have a VAT rate greater than zero |
| BR-S-08 | The taxable amount in the breakdown must match the amounts of the related lines, surcharges, and discounts |
| BR-S-09 | The VAT amount must match the taxable amount multiplied by the VAT rate |
Why they happen: a line has one VAT category while the VAT breakdown shows another; the VAT rate is blank or incorrect; a discount or surcharge isn't included in the same VAT category; the VAT amount is rounded differently than the validation rules expect.
How to fix it: check that each line has the correct VAT category code, VAT rate, and a matching entry in the VAT breakdown. If the invoice has several VAT rates, each rate must be correctly reflected in its own separate VAT breakdown entry.
The BR-DEC group — too many decimal places
What the error means: a specific amount field has more decimal places than allowed.
Where the problem is: in amount fields — for example, the invoice line net amount, the VAT amount, the total without VAT, or the total with VAT.
Why it happens: the system passes an amount into the XML file with three or more decimal places, for example 121.005, even though that field only allows two.
How to fix it: check the rounding settings in your accounting software and make sure amounts are passed into the XML file with the allowed number of decimal places.
The main takeaway
Most EN 16931 validation errors happen not because the content of the invoice is fundamentally wrong, but because the structured data has an inconsistency between fields.
The most common causes are a missing mandatory field, an incorrect VAT category code, a mismatch between line amounts and totals, or inconsistent rounding.
The validator helps you find the specific inconsistency: it shows the error code, the field with the problem, and an explanation of what to fix in the XML file or in the accounting software.
If you're still unsure about the basics, start with what is an e-rēķins. If the same errors keep repeating across several invoices, the cause is often in the accounting software's settings — see what to look for when choosing or checking your software.
Frequently asked questions
What does error BR-CO-10 mean?
BR-CO-10 means the net sum of the invoice lines doesn't match the line total without VAT stated in the invoice. Common causes are rounding, a skipped line, an incorrect discount, or an error in XML generation.
What does error BR-06 mean?
BR-06 means the invoice is missing the seller's name (field BT-27). Check whether the seller's legal name is filled in in your accounting software and whether it's actually passed through into the XML file.
Why does an invoice fail validation when the amounts look correct?
The reason is often a difference between what you see in the PDF invoice and what's actually recorded in the XML file. Validation checks the XML data itself: amount fields, the VAT breakdown, category codes, mandatory fields, and rounding.
What if the same error keeps repeating on every invoice?
If an error repeats systematically, the problem is usually in the accounting software's settings or in the e-invoice export configuration. In that case, don't fix invoices one by one — fix the software or its XML generation logic instead.