The short answer
BR-CO-11 fails when cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount is not the sum of the document-level allowances. Add up cbc:Amount for every cac:AllowanceCharge directly under the document root whose cbc:ChargeIndicator is false, round the sum to two decimals, and write that figure as the allowance total.
Line-level allowances are not part of this sum. They are already inside each line net amount.
What the rule checks
The rule compares one total with the amounts it summarises. It reads only cac:AllowanceCharge elements that are children of the Invoice or CreditNote root and have cbc:ChargeIndicator set to false. Charges, and any cac:AllowanceCharge inside a line or a price, are ignored.
The comparison is exact after the sum is rounded to two decimals. There is no tolerance: a total of 2.00 against allowances of 1.99 fails.
The total may be left out only when there are no document-level allowances at all. An allowance with no total fails. With no allowances, an explicit total of 0.00 passes and any other total fails.
| Term | Meaning | UBL element |
|---|---|---|
| BT-107 | Sum of allowances on document level | cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount |
| BT-92 | Document level allowance amount | cac:AllowanceCharge[cbc:ChargeIndicator = false]/cbc:Amount |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The total is taken from a header field in the source system while the allowance elements are built from a separate table, and the two disagree.
- Line discounts are added into the document total as well as being netted into the line amounts.
- A charge is emitted with
cbc:ChargeIndicatoroffalse, or an allowance withtrue, so the amount lands in the wrong sum. - Amounts are summed as binary floating point and the result drifts by a penny before it is formatted.
- The allowance elements are emitted but the total is left out because the source system treats it as optional.
How to fix it
- List the
cac:AllowanceChargeelements directly under the document root and keep those withcbc:ChargeIndicatoroffalse. - Sum their
cbc:Amountvalues using decimal arithmetic, then round the result to two decimals. - Write that value to
cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount. If the list is empty, omit the element. - Recalculate the total without VAT from the corrected figure: line total minus allowance total plus charge total.
BR-CO-13checks that next.
The recorded example has one document-level allowance and one document-level charge.
Document-level allowances: 1.00 Allowance total (BT-107): 1.00 Total without VAT: 66.00 - 1.00 + 3.50 = 68.50
Validate your corrected invoice
Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: the total says 2.00, the only allowance is 1.00
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Example document discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">1.00</cbc:Amount>
<!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="GBP">68.50</cbc:TaxExclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="GBP">2.00</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="GBP">3.50</cbc:ChargeTotalAmount>
</cac:LegalMonetaryTotal>Fragment of the corrected invoice: the total is the sum of the allowances
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="GBP">68.50</cbc:TaxExclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="GBP">1.00</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="GBP">3.50</cbc:ChargeTotalAmount>
</cac:LegalMonetaryTotal>Only cbc:AllowanceTotalAmount differs. The failing document also reports BR-CO-13, because the total without VAT of 68.50 was calculated from an allowance total of 1.00 and no longer agrees with the 2.00 that was sent. Correcting the allowance total clears both.
What the validator reported
- The failing invoice reports BR-CO-11 and BR-CO-13. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected XML
Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.
Where it applies
- Applies to UBL
InvoiceandCreditNotealike; the elements have the same names in both. - The amounts are in the document currency. The rule does not convert currencies or look at the VAT accounting currency.
- Each document-level allowance still needs its own VAT category and reason, which other rules check. This rule is only about the sum.
Related rules
- BR-CO-12 is the same check for document-level charges
- BR-CO-13 uses the allowance total to check the total without VAT
- BR-CO-10 checks the line total that the allowances are taken from
- PEPPOL-EN16931-R040 checks each allowance amount against its base amount and percentage
- Browse every rule in the reference
Scope and source
Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.
The official definition of BR-CO-11 carries the normative wording and test. This page is our explanation of it, not a copy.
Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.
