# BR-DEC-12: Write the total without VAT with no more than two decimals

`cbc:TaxExclusiveAmount` in the monetary totals has more than two digits after the decimal point. Write the total without VAT to two decimals at most.

- 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-DEC-12/
- Explanation last updated: 2026-09-24

## The short answer

`BR-DEC-12` fails when `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` is written with more than two digits after the decimal point. Write the total without VAT with two decimals at most, for example `68.50` rather than `68.500`.

The check is on the written form, not the value, so one padding zero is enough to fail it. `UBL-DT-01` reports the same element in the same run.

## What the rule checks

The rule runs on `cac:LegalMonetaryTotal`, reads the text of its `cbc:TaxExclusiveAmount`, and allows at most two characters after the decimal point. Fewer are fine; when tried, `68.5` validated cleanly.

Each monetary total has a decimals rule of its own, so a formatter that pads all of them brings one finding per total. This rule covers only the total without VAT; the amount due, for instance, is `BR-DEC-18`.

The arithmetic is checked elsewhere. When tried, an unrounded `68.504` also reported `BR-CO-13`, because it is not the line total minus allowances plus charges, while `BR-CO-15` still passed, since that rule rounds its own sum before comparing.

| Term | Meaning | UBL element |
|---|---|---|
| BT-109 | Invoice total amount without VAT | `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` |

## How an integration ends up here

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

- The total without VAT is summed from line amounts held at three or four decimals and never rounded before it is written.
- A decimal column with a scale of three or four is serialised at full scale, so a stored 68.5 comes out as `68.500`.
- The formatter chosen for quantities and prices, which may carry more decimals, is reused for the totals.

## How to fix it

1. Compute the total without VAT from the rounded line, allowance and charge totals and round the result to two decimals.
2. Format it with at most two decimals and no whitespace, and write it to `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount`.
3. Use the same two-decimal formatting for every amount in the document, not only this one; each total and breakdown amount is held to the same limit.
4. If rounding changed the value, recalculate the total with VAT from the rounded figure.

## 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 without VAT is written as 68.500

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="GBP">68.500</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the same total written as 68.50

```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>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

The two documents differ only in how the total without VAT is written: `68.500` against `68.50`. The value is the same, so no total that depends on it is disturbed. The failing document reports `BR-DEC-12` at `cac:LegalMonetaryTotal` and `UBL-DT-01` at the `cbc:TaxExclusiveAmount` itself. `UBL-DT-01` is the syntax-level limit covering every amount element apart from item prices and the amounts of a price-level allowance; the total without VAT is not exempt, so for this element the two findings always come together.

### What the validator reported

- The failing invoice reports **BR-DEC-12** and [UBL-DT-01](https://ironfang.uk/docs/finance/rules/UBL-DT-01.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-DEC-12-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` in the same way. When tried, a credit note with a total without VAT of `68.500` reported the same two findings.
- The limit does not change with the currency, since `currencyID` is not read.
- The schema rejects a decimal comma in any amount, so such a value fails the XSD layer before this rule could run.

## Related rules

- [UBL-DT-01 is reported on the same element whenever this rule fails](https://ironfang.uk/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-13 checks the value of the total without VAT, where this rule checks only its form](https://ironfang.uk/docs/finance/rules/BR-CO-13.md)
- [BR-13 requires the total without VAT to be present](https://ironfang.uk/docs/finance/rules/BR-13.md)
- [BR-DEC-18 applies the same limit to the amount due](https://ironfang.uk/docs/finance/rules/BR-DEC-18.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-24.

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