BR-CO-10:Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)
Fix: Recalculate BT-106 as the sum of the already-rounded line net amounts and write the result to cac:LegalMonetaryTotal/cbc:LineExtensionAmount. Invoice Navigator auto-fixes BR-CO-10 at 0.95 confidence because the correct value is fully derivable from the lines already present in the document — no external data is needed. Upload your invoice to fix this automatically.
BR-CO-10 fires when the document-level sum of line net amounts does not equal the arithmetic sum of the individual line net amounts. It is a pure totals check: BT-106 in cac:LegalMonetaryTotal must equal the sum of every cbc:LineExtensionAmount across all invoice lines, rounded to two decimals. Almost every occurrence traces back to rounding applied at the wrong point in the calculation, or to a total that was overridden manually after the lines were built.
Engine Classification
Recalculate LineExtensionAmount as InvoicedQuantity x PriceAmount
Confidence: 95% · Applied automatically in pipeline
What is BR-CO-10?
BR-CO-10 is a fatal validation rule defined in the EN 16931 specification. It validates the LineExtensionAmount element in the UBL invoice XML.
When this rule fires, the invoice is rejected by Peppol access points and never reaches the buyer.
Target path: //cac:InvoiceLine/cbc:LineExtensionAmount
Why This Error Matters
BT-106 is the base of the entire totals chain. Every amount above it — tax exclusive total, VAT, tax inclusive total, amount due — is derived from it. A mismatch here means the receiver cannot reconcile the document at all, and the error cascades into three or four further validation failures.
BR-CO-10 is a hard failure — the invoice must be corrected and re-sent before it can reach the recipient.
The invoice is rejected and, because the failure is arithmetic, AP teams treat it as a data-integrity problem rather than a formatting one. Repeated occurrences from the same sender tend to trigger manual review of all their invoices, which is slow and expensive on both sides.
Invoice Navigator can automatically correct this error in your pipeline. The fix is applied with full audit evidence, so your compliance trail remains intact.
Validator Behavior
- ·Causes invoice rejection
- ·Error returned: BR-CO-10
- ·Specification: EN 16931
How to Fix It
Round each line first
Ensure every cac:InvoiceLine/cbc:LineExtensionAmount is already rounded to 2 decimals. Rounding at the end instead of per line is the single most common cause of the one-cent mismatch.
Sum the rounded line values
Add all cbc:LineExtensionAmount values across cac:InvoiceLine (or cac:CreditNoteLine for credit notes). Include every line — negative lines and zero-value lines count too.
Write the result to BT-106
Set cac:LegalMonetaryTotal/cbc:LineExtensionAmount to that sum, with the same currencyID as the document currency.
Check the downstream totals
Changing BT-106 shifts BR-CO-13 (TaxExclusiveAmount) and BR-CO-15 (TaxInclusiveAmount). Recalculate the whole totals chain, not just this one field.
Before / After
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="EUR">450.25</cbc:LineExtensionAmount> </cac:InvoiceLine> <cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="EUR">120.10</cbc:LineExtensionAmount> </cac:InvoiceLine> <cac:LegalMonetaryTotal> <!-- 450.25 + 120.10 = 570.35, but header says 570.34 --> <cbc:LineExtensionAmount currencyID="EUR">570.34</cbc:LineExtensionAmount> </cac:LegalMonetaryTotal>
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="EUR">450.25</cbc:LineExtensionAmount> </cac:InvoiceLine> <cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="EUR">120.10</cbc:LineExtensionAmount> </cac:InvoiceLine> <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">570.35</cbc:LineExtensionAmount> </cac:LegalMonetaryTotal>
Technical Reference
//cac:InvoiceLine/cbc:LineExtensionAmountCode Example
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="EUR">850.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="EUR">178.50</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>21</cbc:Percent>
</cac:TaxCategory>
</cac:TaxSubtotal>Common Causes
- ·Rounding applied once at the end instead of per line
- ·Line amounts stored at 4 decimals internally and truncated on export
- ·Document total overridden manually after the lines were created
- ·A line added or removed without recalculating the header total
- ·Discount applied to the total rather than distributed across the lines
Seeing this in production? The API handles BR-CO-10 automatically. See the fix response →
Commonly Seen In
Frequently Asked Questions
It means cac:LegalMonetaryTotal/cbc:LineExtensionAmount (BT-106) does not equal the sum of the individual line net amounts (BT-131). The Schematron sums the line values, rounds to two decimals, and compares.
Because rounding was applied at the wrong point. The rule sums values that are already rounded per line, so you must round each line to two decimals first and then sum. Summing unrounded values and rounding once at the end produces a one-cent drift.
Yes, at 0.95 confidence. The correct BT-106 is fully derivable from the lines already in the document, so Invoice Navigator recomputes and rewrites the header total without needing any external input.
No. BR-CO-10 checks the document-level sum of line net amounts. BR-CO-14 checks that each VAT category's taxable amount matches the lines in that category. They often fire together but have different causes and different fixes.
Usually yes. BT-106 feeds TaxExclusiveAmount (BR-CO-13) and through it TaxInclusiveAmount (BR-CO-15) and the amount due. Recalculate the full totals chain after changing the line sum.
Related Errors
Related Content
Last updated: 18 August 2026
Validate your invoice
Drop your XML here to check for BR-CO-10
Auto-fix BR-CO-10 in seconds
Upload your invoice and we fix this error automatically. Financial fields are never touched.