# BR-DEC-18: Write the amount due with no more than two decimals
`cbc:PayableAmount` has more than two digits after the decimal point. Round the amount due for payment to two decimals and format it that way.
- 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-18/
- Explanation last updated: 2026-09-24
## The short answer
`BR-DEC-18` fails when `cac:LegalMonetaryTotal/cbc:PayableAmount` has more than two characters after the decimal point. Write the amount due for payment with two decimals at most: `70.00`, not `70.000`.
Padding alone triggers it: the recorded `70.000` is the correct amount written with one zero too many. `UBL-DT-01` reports the same element alongside.
## What the rule checks
The rule runs on `cac:LegalMonetaryTotal`, takes the text of `cbc:PayableAmount`, and fails when more than two characters follow the decimal point. A trailing zero counts like any other digit.
The format is checked independently of the arithmetic that produced the figure. When tried, `70.004` was reported by this rule and `UBL-DT-01` only: with a rounding amount present, `BR-CO-16` rounds the amount due before comparing, so it did not object.
The prepaid amount and the rounding amount beside it have decimals rules of their own. When tried, a rounding amount of `-0.200` reported `BR-DEC-17` with `UBL-DT-01`, not this rule.
| Term | Meaning | UBL element |
|---|---|---|
| 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 amount due is derived from a total with VAT held at higher precision, minus a prepayment, and written without a final rounding.
- Cash rounding to a coarser step, such as 0.05, is computed in a type that keeps three decimals and the result is written at that scale.
- Amounts are held as floating point and formatted with a fixed three decimal places.
## How to fix it
1. Compute the amount due from the written totals: total with VAT minus prepaid amount plus rounding amount.
2. Round the result to two decimals and format it with at most two, without whitespace.
3. Write it to `cac:LegalMonetaryTotal/cbc:PayableAmount`, the last element of the monetary totals.
4. Format any `cbc:PrepaidAmount` and `cbc:PayableRoundingAmount` the same way, since each is held to two decimals 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: 80.20 - 10.00 - 0.20 is written as 70.000
```xml
80.20
10.00
-0.20
70.000
```
Fragment of the corrected invoice: the amount due written as 70.00
```xml
80.20
10.00
-0.20
70.00
```
Only `cbc:PayableAmount` is written differently, `70.000` in the failing document and `70.00` in the corrected one; the amount due is the same 80.20 - 10.00 - 0.20 in both. The failing document reports `BR-DEC-18` at the monetary totals and `UBL-DT-01` at the payable amount itself. `UBL-DT-01` is the UBL data type check that holds every amount element to two decimals, bar the item net price and the amounts of an allowance on the price, which is why it repeats this finding for the amount due. Correcting the format clears both.
### What the validator reported
- The failing invoice reports **BR-DEC-18** 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-18-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. When tried, a credit note with an amount due of `70.000` reported the same two findings.
- A negative amount due, as on some credit notes or overpaid invoices, is counted the same way: the minus sign sits before the decimal point and plays no part.
- The rule ignores the currency. It does not forbid two decimals for a currency without a minor unit, and it does not allow a third for a currency whose minor unit has three digits.
## Related rules
- [UBL-DT-01 reports the same amount due, as the general two-decimal limit on amounts](https://ironfang.uk/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-16 checks the value of the amount due against the total with VAT, the prepaid amount and the rounding amount](https://ironfang.uk/docs/finance/rules/BR-CO-16.md)
- [BR-DEC-12 applies the same limit to the total without VAT](https://ironfang.uk/docs/finance/rules/BR-DEC-12.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-18](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-18/) 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-18)
- [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