# BR-14: Add the total amount with VAT to the monetary totals

`cac:LegalMonetaryTotal` has no `cbc:TaxInclusiveAmount`. Add the total with VAT: the total without VAT plus the VAT total, the base of the amount due.

- 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-14/
- Explanation last updated: 2026-09-28

## The short answer

`BR-14` fails when `cac:LegalMonetaryTotal` contains no `cbc:TaxInclusiveAmount`. Add it after `cbc:TaxExclusiveAmount`, holding the total without VAT plus the VAT total from `cac:TaxTotal/cbc:TaxAmount`, rounded to two decimals: 25.00 + 5.00 = 30.00 in the recorded example.

Two arithmetic checks lose their input while it is missing. `BR-CO-15` cannot confirm the VAT sum and `BR-CO-16` cannot confirm the amount due, so both are reported beside `BR-14`, and all three clear together.

## What the rule checks

The rule runs on `cac:LegalMonetaryTotal` and asks only whether a `cbc:TaxInclusiveAmount` child is there. The figure itself belongs to `BR-CO-15`: when tried, a total with VAT of 25.00 instead of 30.00 passed `BR-14` and reported `BR-CO-15` and `BR-CO-16`.

No empty form of the element gets through. When tried, a self-closing `cbc:TaxInclusiveAmount` with only its `currencyID` was rejected by the XSD layer, and the EN 16931 and Peppol layers were skipped.

The test has no condition attached, so the element is needed on every document, including one with no VAT due, where it simply repeats the total without VAT.

| Term | Meaning | UBL element |
|---|---|---|
| BT-112 | Invoice total amount with VAT | `cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount` |
| BT-109 | Invoice total amount without VAT | `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` |
| BT-110 | Invoice total VAT amount | `cac:TaxTotal/cbc:TaxAmount` |
| BT-115 | Amount due for payment | `cac:LegalMonetaryTotal/cbc:PayableAmount` |

## How an integration ends up here

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

- The export writes only the figures the source stores, such as the net total and the amount due, and derives nothing in between.
- The mapping treats the total with VAT as redundant when nothing has been prepaid, because it then equals the amount due, and drops it.
- The gross total is mapped straight to `cbc:PayableAmount`, and the element that should also hold it is never written.
- The VAT calculation step returns null for the gross figure and the serialiser skips the element.

## How to fix it

1. Settle the VAT total first: `cac:TaxTotal/cbc:TaxAmount` in the document currency, which `BR-CO-14` checks against the VAT breakdown.
2. Add it to `cbc:TaxExclusiveAmount` with decimal arithmetic and round the result to two decimals.
3. Write the result as `cbc:TaxInclusiveAmount`, with the document currency in `currencyID`, after `cbc:TaxExclusiveAmount` and before `cbc:AllowanceTotalAmount`.
4. Check the amount due against it: total with VAT minus `cbc:PrepaidAmount` plus `cbc:PayableRoundingAmount`, which `BR-CO-16` recalculates.

## 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 totals jump from the total without VAT to the allowance total

```xml
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="GBP">5.00</cbc:TaxAmount>
  <!-- VAT breakdown omitted from this fragment -->
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="GBP">25.00</cbc:TaxExclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="GBP">0.00</cbc:AllowanceTotalAmount>
  <!-- charge total, prepaid and rounding amounts omitted from this fragment -->
  <cbc:PayableAmount currencyID="GBP">30.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the total with VAT of 30.00 follows the total without VAT

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="GBP">25.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="GBP">30.00</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="GBP">0.00</cbc:AllowanceTotalAmount>
  <!-- charge total, prepaid and rounding amounts omitted from this fragment -->
  <cbc:PayableAmount currencyID="GBP">30.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

The corrected invoice has a `cbc:TaxInclusiveAmount` of 30.00 between the total without VAT and the allowance total; the failing invoice lacks it and is otherwise identical. Beside `BR-14`, the failing document reports `BR-CO-15` at the document root, which cannot show that 25.00 plus the VAT of 5.00 gives the total with VAT, and `BR-CO-16` at the monetary totals, which cannot show that the amount due of 30.00 follows from it. The one element clears all three.

### What the validator reported

- The failing invoice reports **BR-14**, [BR-CO-15](https://ironfang.com/docs/finance/rules/BR-CO-15.md) and [BR-CO-16](https://ironfang.com/docs/finance/rules/BR-CO-16.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-14-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/invoice-minimal.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 `Invoice` and `CreditNote` in the same way. When tried, a credit note without the element reported the same three rules, and so did the rich invoice, whose amount due of 70.00 also depends on a prepaid amount and a rounding amount.
- The UBL schema lets the element be left out, so a document without it passes the XSD layer and only the EN 16931 rules notice.
- Nothing on the Peppol layer reacts to the gap; it passed the recorded failing invoice.
- The limit of two decimals on this amount is a separate rule, `BR-DEC-14`.

## Related rules

- [BR-13 requires the total without VAT that this figure is built on](https://ironfang.com/docs/finance/rules/BR-13.md)
- [BR-CO-15 checks that the total with VAT is the total without VAT plus the VAT total](https://ironfang.com/docs/finance/rules/BR-CO-15.md)
- [BR-CO-16 derives the amount due from this total, the prepaid amount and the rounding amount](https://ironfang.com/docs/finance/rules/BR-CO-16.md)
- [BR-DEC-14 limits the total with VAT to two decimals](https://ironfang.com/docs/finance/rules/BR-DEC-14.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of BR-14](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-14/) 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.com/docs/finance/rules/BR-14)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp