# BR-DEC-10: Write the sum of document allowances with no more than two decimals

`cbc:AllowanceTotalAmount` has more than two digits after the decimal point. Write the sum of allowances on document level to two decimals, zero included.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Totals, Allowances and charges
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-10/
- Explanation last updated: 2026-09-28

## The short answer

`BR-DEC-10` fails when `cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount` has more than two characters after the decimal point. Write the allowance total with two decimals at most, `1.00` rather than `1.000`.

A zero total is counted too: an invoice with no document allowances that sends `0.000` fails in the same way. `UBL-DT-01` reports the element in either case.

## What the rule checks

The rule runs on `cac:LegalMonetaryTotal` and counts the characters after the decimal point in its `cbc:AllowanceTotalAmount`; more than two fail. The allowances it sums are counted separately by `BR-DEC-01`, one finding per allowance.

When tried, the minimal invoice, which has no allowances, failed this rule with its allowance total written as `0.000`, and validated cleanly with the element left out altogether.

An unrounded allowance total is also a wrong total. When tried, `1.004` reported `BR-CO-11` beside this rule and `UBL-DT-01`, because the allowances round to 1.00 and that comparison is exact.

| Term | Meaning | UBL element |
|---|---|---|
| BT-107 | Sum of allowances on document level | `cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount` |

## How an integration ends up here

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

- Every monetary total is written by one formatter with three decimals, so an empty allowance total becomes `0.000`.
- The allowance total is added up from percentage discounts before each of them is rounded.
- A fixed-scale decimal type from the database is serialised as held.

## How to fix it

1. Add up the rounded document allowance amounts and round the sum to two decimals.
2. Write it to `cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount` with at most two decimals and no whitespace, or leave the element out when there are no document allowances.
3. Use the same rounded figure when you subtract allowances to reach the total without VAT.

## Before and after

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

Fragment of the failing invoice: a document discount of 1.00, totalled as 1.000

```xml
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <!-- reason code and reason omitted from this fragment -->
  <cbc:Amount currencyID="GBP">1.00</cbc:Amount>
  <!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>
<!-- document charge and VAT breakdown omitted from this fragment -->
<cac:LegalMonetaryTotal>
  <!-- line, net and gross totals omitted from this fragment -->
  <cbc:AllowanceTotalAmount currencyID="GBP">1.000</cbc:AllowanceTotalAmount>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the allowance total written as 1.00

```xml
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <!-- reason code and reason omitted from this fragment -->
  <cbc:Amount currencyID="GBP">1.00</cbc:Amount>
  <!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>
<!-- document charge and VAT breakdown omitted from this fragment -->
<cac:LegalMonetaryTotal>
  <!-- line, net and gross totals omitted from this fragment -->
  <cbc:AllowanceTotalAmount currencyID="GBP">1.00</cbc:AllowanceTotalAmount>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

In the failing invoice `cbc:AllowanceTotalAmount` reads `1.000`; in the corrected invoice it reads `1.00`, the same as the one document discount it sums. Because the value is unchanged, `BR-CO-11` and `BR-CO-13` pass in both. The failing document reports `BR-DEC-10` at `cac:LegalMonetaryTotal` and `UBL-DT-01` at the allowance total itself: `UBL-DT-01` is the two-decimal limit on every element named as an amount, with item prices and price-level allowance amounts the only exceptions, so it fires on the same element.

### What the validator reported

- The failing invoice reports **BR-DEC-10** and [UBL-DT-01](https://ironfang.com/docs/finance/rules/UBL-DT-01.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-DEC-10-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/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`. When tried, a credit note with an allowance total of `1.000` reported the same pair.
- The element may be omitted when the document has no allowances, and `BR-CO-11` accepts its absence then; once it is written, this rule counts it.
- The limit ignores `currencyID`.

## Related rules

- [UBL-DT-01 reports the allowance total in the same run](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-11 checks the allowance total against the rounded sum of the document allowances](https://ironfang.com/docs/finance/rules/BR-CO-11.md)
- [BR-DEC-01 counts the decimals of each document allowance that goes into this total](https://ironfang.com/docs/finance/rules/BR-DEC-01.md)
- [BR-DEC-11 is the matching limit for the charge total](https://ironfang.com/docs/finance/rules/BR-DEC-11.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-DEC-10](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-10/) 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-DEC-10)
- [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