# BR-DEC-16: Write the paid amount with no more than two decimals

`cbc:PrepaidAmount` has more than two digits after the decimal point. Write the amount already paid, such as a deposit, with 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-16/
- Explanation last updated: 2026-09-28

## The short answer

`BR-DEC-16` fails when `cac:LegalMonetaryTotal/cbc:PrepaidAmount` has more than two characters after the decimal point. Write the paid amount with two decimals at most, `10.00` in place of `10.000`.

The prepayment of 10.00 in the recorded invoice is correct, and only its written form fails. `UBL-DT-01` reports the same `cbc:PrepaidAmount`.

## What the rule checks

The rule counts the characters after the decimal point in the `cbc:PrepaidAmount` of `cac:LegalMonetaryTotal` and allows two. A document without a paid amount has nothing to count; when tried, the minimal invoice validated with the element removed.

The amount due check does not always see a small error in the paid amount. When tried, `10.004` reported only this rule and `UBL-DT-01`, because `BR-CO-16` rounds 80.20 - 10.004 back to 70.20 before comparing. With `10.006` the difference rounds to 70.19, and `BR-CO-16` was reported too.

A zero prepayment is counted like any other value. When tried, the minimal invoice with `0.000` as its paid amount reported this rule and `UBL-DT-01`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-113 | Paid amount | `cac:LegalMonetaryTotal/cbc:PrepaidAmount` |

## How an integration ends up here

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

- The deposit is recorded in a payments ledger with three or four decimals and copied across as stored.
- The paid amount is computed as a share of the total with VAT and written unrounded.
- A default paid amount of zero is written by a formatter set to three decimals.

## How to fix it

1. Round the amount already received to two decimals, matching what was actually paid.
2. Write it to `cac:LegalMonetaryTotal/cbc:PrepaidAmount` with at most two decimals and no whitespace, or leave the element out if nothing was paid in advance.
3. Subtract the rounded paid amount from the total with VAT when you calculate the amount due, so that `BR-CO-16` agrees.

## 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 prepayment of 10.00 written as 10.000

```xml
<cac:LegalMonetaryTotal>
  <!-- line and net totals omitted from this fragment -->
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <!-- allowance and charge totals omitted from this fragment -->
  <cbc:PrepaidAmount currencyID="GBP">10.000</cbc:PrepaidAmount>
  <!-- rounding amount and amount due omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the prepayment written as 10.00

```xml
<cac:LegalMonetaryTotal>
  <!-- line and net totals omitted from this fragment -->
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <!-- allowance and charge totals omitted from this fragment -->
  <cbc:PrepaidAmount currencyID="GBP">10.00</cbc:PrepaidAmount>
  <!-- rounding amount and amount due omitted from this fragment -->
</cac:LegalMonetaryTotal>
```

The two invoices differ only in the paid amount: `10.000` in the failing one and `10.00` in the corrected one. The amount due of 70.00 is 80.20 - 10.00 - 0.20 in both, so `BR-CO-16` passes. The failing document reports `BR-DEC-16` at `cac:LegalMonetaryTotal` and `UBL-DT-01` at the `cbc:PrepaidAmount`. Every element whose name ends in `Amount` falls under `UBL-DT-01` except item prices and the amounts of a price-level allowance; the paid amount is an ordinary total in that respect, which is why its finding comes paired with this one.

### What the validator reported

- The failing invoice reports **BR-DEC-16** 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-16-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 a paid amount of `10.000` reported the same two findings.
- The limit does not change with `currencyID`.

## Related rules

- [UBL-DT-01 reports the paid amount in the same run](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-16 subtracts the paid amount from the total with VAT to check the amount due](https://ironfang.com/docs/finance/rules/BR-CO-16.md)
- [BR-DEC-14 applies the same limit to the total with VAT that the paid amount is deducted from](https://ironfang.com/docs/finance/rules/BR-DEC-14.md)
- [BR-DEC-17 applies the same limit to the rounding amount](https://ironfang.com/docs/finance/rules/BR-DEC-17.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-16](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-16/) 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-16)
- [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