BR-CO-15 error: fix the invoice total with VAT

ARLing s. r. o. · 25 September 2026

What BR-CO-15 compares, element by element

The rule text is short: "[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)."

In a UBL invoice the three business terms sit in these elements:

• BT-112, total with VAT: cbc:TaxInclusiveAmount inside cac:LegalMonetaryTotal
• BT-109, total without VAT: cbc:TaxExclusiveAmount inside cac:LegalMonetaryTotal
• BT-110, total VAT: cbc:TaxAmount directly inside cac:TaxTotal, with a currencyID equal to cbc:DocumentCurrencyCode

The official schematron test does two things. First it counts the VAT totals in the invoice currency and wants exactly one. Then it compares BT-112 with BT-109 plus BT-110 rounded to two decimals, written as round((BT-109 + BT-110) * 10 * 10) div 100, and any difference is fatal.

In CII, the syntax inside Factur-X and ZUGFeRD, the same terms are ram:GrandTotalAmount, ram:TaxBasisTotalAmount and ram:TaxTotalAmount, whose currencyID has to match ram:InvoiceCurrencyCode, all inside ram:SpecifiedTradeSettlementHeaderMonetarySummation. The CII test has one extra branch: it also passes when the total with VAT equals the total without VAT.

BR-CO-15 is one link in a chain of totals rules, and its neighbors can show where a wrong figure came from:

1. BR-CO-10: the line net amounts add up to BT-106
2. BR-CO-13: BT-109 is BT-106 minus document allowances plus document charges
3. BR-CO-14: BT-110 is the sum of the VAT amounts in the breakdown (BT-117)
4. BR-CO-15: BT-112 is BT-109 plus BT-110
5. BR-CO-16: the amount due (BT-115) is BT-112 minus the paid amount (BT-113) plus the rounding amount (BT-114)

Because it is a core EN 16931 rule, the same check runs under Peppol BIS Billing 3.0 and XRechnung with the same code.

The one-cent case: two rounding methods in one file

Take a made-up Peppol invoice with three lines of 19.99 each at the Slovak standard rate of 23%. The same three lines give different figures depending on where you round:

• VAT per category: 59.97 × 0.23 = 13.7931, rounded 13.79
• VAT per line: 19.99 × 0.23 = 4.5977, rounded 4.60, three times 13.80
• Gross per line: 19.99 × 1.23 = 24.5877, rounded 24.59, three times 73.77

If the software writes the VAT per category (13.79) but builds the total with VAT by adding up the rounded gross lines (73.77), our checker returns exactly one error: "The invoice total with VAT (BT-112) should be the total without VAT 59.97 plus the VAT 13.79, that is 73.76. The file says 73.77. Correct the total in the invoice header, not the individual lines."

The VAT breakdown itself is not the problem. BR-CO-17 and BR-S-09 accept a VAT amount per category that differs from taxable amount times rate by less than one unit of currency, so both 13.79 and 13.80 pass there. The totals chain has no such margin, which is why the cent surfaces in BR-CO-15 and nowhere earlier.

Both consistent versions passed our checker with zero errors: VAT 13.79 with a total of 73.76, and VAT 13.80 per line with a total of 73.77. Pick one method and derive BT-112 from BT-109 and BT-110 instead of adding up gross lines.

The corrected part of the file, with the old figure kept in comments:

<cac:TaxTotal>
        <cbc:TaxAmount currencyID="EUR">13.79</cbc:TaxAmount>
        <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">59.97</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">13.79</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>23.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
        </cac:TaxSubtotal>
      </cac:TaxTotal>
      <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="EUR">59.97</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="EUR">59.97</cbc:TaxExclusiveAmount>
        <!-- was 73.77 -->
        <cbc:TaxInclusiveAmount currencyID="EUR">73.76</cbc:TaxInclusiveAmount>
        <!-- was 73.77 -->
        <cbc:PayableAmount currencyID="EUR">73.76</cbc:PayableAmount>
      </cac:LegalMonetaryTotal>

Your own file may carry the same gap. Open it in our free e-invoice checker, and the message shows the two amounts it added and the total it expected.

Three other causes, and a near miss with decimals

A total typed in by hand. Our own sample with errors is this case: the total with VAT is one cent too high on a reverse charge invoice where the VAT is 0.00. The message reads "The invoice total with VAT (BT-112) should be the total without VAT 1500.00 plus the VAT 0.00, that is 1500.00. The file says 1500.01."

A VAT total in the wrong currency. When cbc:TaxAmount in cac:TaxTotal carries currencyID="CZK" on an invoice in EUR, there is no VAT total in the invoice currency, and BR-CO-15 fails even though the amounts add up. Our checker says "There has to be exactly one invoice total VAT amount (BT-110) in the invoice currency (EUR). We found 0." and adds PEPPOL-EN16931-R051 for the currency itself.

Two VAT totals in the invoice currency. Two cac:TaxTotal groups with an amount in EUR make the count two instead of one. Our checker reports BR-CO-15 with "We found 2." and PEPPOL-EN16931-R054, because a second cac:TaxTotal without a breakdown is allowed only with a VAT accounting currency (BT-6).

VAT with three decimals. A VAT total of 13.793 does not trip BR-CO-15, because 59.97 + 13.793 = 73.763 is rounded to 73.76 before the comparison. In the official schematron the file fails BR-CO-14 instead, which compares the unrounded 13.793 with the breakdown sum rounded to 13.79, and BR-DEC-20 flags the three decimals in the breakdown. BR-DEC-13 sets a two decimal limit for the VAT total, but its test in schematron 1.3.16 never selects the amount, so it does not fire.

Our checker handles this file differently from the official schematron. It reports BR-DEC-13 and BR-DEC-20 and misses BR-CO-14, because it rounds the VAT total to two decimals before comparing. The repair is the same either way: write 13.79 in the total and in the breakdown, as in the version that passed.

How to fix BR-CO-15, step by step

1. Read the two numbers in the message: our checker names BT-109, BT-110 and the result it expects, for example 59.97 plus 13.79, that is 73.76
2. Count the VAT totals: exactly one cac:TaxTotal/cbc:TaxAmount must carry the currencyID of cbc:DocumentCurrencyCode
3. Check that BT-110 equals the sum of the breakdown amounts to the cent, with no more than two decimals in either, or BR-CO-14 and BR-DEC-20 fail as well
4. Set cbc:TaxInclusiveAmount to BT-109 plus BT-110, rounded to two decimals
5. Set cbc:PayableAmount to that figure minus cbc:PrepaidAmount plus cbc:PayableRoundingAmount, or BR-CO-16 appears next
6. Check the whole file again, not just this one rule

If the invoice comes out of software, correct the calculation there as well, because a file fixed by hand does not change how the next export rounds. The Banqup help center points senders to the same place: the document, the customer card or the external software that produced the invoice.

If you received the invoice. BR-CO-15 is fatal, so a file that fails it does not comply with Peppol BIS, and the receiver may reject it. In Banqup, for example, received e-invoices are read-only and the sender has to correct the document and send it again, so ask the supplier for a corrected file and quote the rule code.

What our checker shows, and where it stops

Our e-invoice check is free, needs no account and reads the file in your browser without uploading it. It runs 332 rule codes from EN 16931, Peppol BIS Billing 3.0 and XRechnung 3.0 and prints the rule code, a sentence and the XPath for every finding, like the messages quoted above.

To see BR-CO-15 without a file of your own, click Load sample and then See the sample with 2 errors: the total with VAT is one cent too high and the IBAN has a typo. The result lists BR-CO-15 at /Invoice/cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount. Every rule also has a page of its own, this one included: BR-CO-15 in our rule list.

It is not a complete validation. It does not check the UBL 2.1 XSD schema or the UBL-CR, UBL-SR and UBL-DT rules, it runs the rules on UBL and not on CII, and passing it does not guarantee that your buyer or the Peppol network accepts the invoice. In the three decimal case above, its result also differs from the official schematron.

Frequently asked questions

Conclusion

BR-CO-15 is simple arithmetic with two traps around it: exactly one VAT total in the invoice currency, and no tolerance for a cent. Derive the total with VAT from the two amounts in the file, update the amount due with it, and check the whole file again. You can run the same check on your own XML in the free e-invoice checker, which shows the rule, the expected figure and the path to the element.