# BR-CO-13: Fix a total without VAT that does not follow from the other totals

The total without VAT must equal the line total minus the document allowance total plus the document charge total, to two decimals.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Totals
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-13/
- Explanation last updated: 2026-09-20

## The short answer

`BR-CO-13` fails when `cbc:TaxExclusiveAmount` is not `cbc:LineExtensionAmount` minus `cbc:AllowanceTotalAmount` plus `cbc:ChargeTotalAmount`, all four taken from `cac:LegalMonetaryTotal`. Recalculate the total without VAT from the other three and write it to two decimals.

This finding often arrives as a consequence. If `BR-CO-10`, `BR-CO-11` or `BR-CO-12` is reported alongside it, fix that total first: the total without VAT may already be right for the corrected figure.

## What the rule checks

The rule reads only the four totals inside `cac:LegalMonetaryTotal`. It does not look at the lines or at the individual `cac:AllowanceCharge` elements; those are tied to their totals by other rules.

An allowance total or charge total that is left out contributes nothing. With neither present, the total without VAT must simply equal the line total.

The calculated figure is rounded to two decimals and compared exactly. A total without VAT of 68.51 where the other totals give 68.50 fails.

| Term | Meaning | UBL element |
|---|---|---|
| BT-109 | Invoice total amount without VAT | `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` |
| BT-106 | Sum of Invoice line net amount | `cac:LegalMonetaryTotal/cbc:LineExtensionAmount` |
| BT-107 | Sum of allowances on document level | `cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount` |
| BT-108 | Sum of charges on document level | `cac:LegalMonetaryTotal/cbc:ChargeTotalAmount` |

## How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

- The total without VAT is copied from the source system while one of the other totals is recalculated during mapping, so the four figures come from two different calculations.
- Document-level allowances are added instead of subtracted, or charges subtracted instead of added.
- The allowance or charge total is dropped from the XML although it was used to compute the total without VAT.
- Line-level allowances are subtracted a second time, although they are already inside the line total.
- The total without VAT is derived backwards from a VAT-inclusive figure and lands a penny away from the forward calculation.

## How to fix it

1. Settle the inputs first: the line total (`BR-CO-10`), the allowance total (`BR-CO-11`) and the charge total (`BR-CO-12`).
2. Compute line total minus allowance total plus charge total with decimal arithmetic and round to two decimals.
3. Write the result to `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount`.
4. Carry the new figure forward: the total with VAT is this amount plus the VAT total, which `BR-CO-15` checks.

The recorded example has a line total of 66.00, one document allowance and one document charge.

```text
Expected total without VAT: 66.00 - 1.00 + 3.50 = 68.50
Total without VAT sent (BT-109): 69.50, so BR-CO-13 fails
Total with VAT sent: 80.20, which is 68.50 + 11.70
Against the 69.50 that was sent, BR-CO-15 expects 69.50 + 11.70 = 81.20, so it fails too
```

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: 66.00 - 1.00 + 3.50 is 68.50, but the total without VAT says 69.50

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="GBP">69.50</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="GBP">1.00</cbc:AllowanceTotalAmount>
  <cbc:ChargeTotalAmount currencyID="GBP">3.50</cbc:ChargeTotalAmount>
  <!-- prepaid, rounding and payable amounts omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the total without VAT follows from the other three

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="GBP">68.50</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="GBP">1.00</cbc:AllowanceTotalAmount>
  <cbc:ChargeTotalAmount currencyID="GBP">3.50</cbc:ChargeTotalAmount>
  <!-- prepaid, rounding and payable amounts omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

Only `cbc:TaxExclusiveAmount` differs: 69.50 in the failing document, 68.50 in the corrected one. The failing document also reports `BR-CO-15`, because the total with VAT of 80.20 was built on 68.50 and does not equal the 69.50 that was sent plus the VAT total of 11.70. Correcting the total without VAT clears both.

### What the validator reported

- The failing invoice reports **BR-CO-13** and [BR-CO-15](https://ironfang.uk/docs/finance/rules/BR-CO-15.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CO-13-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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 `Invoice` and `CreditNote` alike; the totals have the same names in both and a credit note with the same mistake reports the same two findings.
- Because only the totals are read, this rule can pass while a total is itself wrong. `BR-CO-10`, `BR-CO-11` and `BR-CO-12` are the checks that tie each total to the lines, allowances and charges.
- The rule compares the numbers only. It does not read `currencyID` and converts nothing.

## Related rules

- [BR-CO-10 checks the line total this calculation starts from](https://ironfang.uk/docs/finance/rules/BR-CO-10.md)
- [BR-CO-11 checks the allowance total that is subtracted](https://ironfang.uk/docs/finance/rules/BR-CO-11.md)
- [BR-CO-12 checks the charge total that is added](https://ironfang.uk/docs/finance/rules/BR-CO-12.md)
- [BR-CO-15 adds the VAT total to this amount to check the total with VAT](https://ironfang.uk/docs/finance/rules/BR-CO-15.md)

## 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-20.

[The official definition of BR-CO-13](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-13/) 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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-CO-13)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp