# BR-DEC-17: Write the rounding amount with no more than two decimals

`cbc:PayableRoundingAmount` has more than two digits after the decimal point. Write the rounding amount, positive or negative, 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-17/
- Explanation last updated: 2026-09-28

## The short answer

`BR-DEC-17` fails when `cac:LegalMonetaryTotal/cbc:PayableRoundingAmount` has more than two characters after the decimal point. Write the rounding amount with two decimals at most: `-0.20`, not `-0.200`.

In the recorded invoice the adjustment itself is right and only padded: it takes 80.20 - 10.00 down to an amount due of 70.00. `UBL-DT-01` reports the same element.

## What the rule checks

The rule counts what follows the decimal point in the `cbc:PayableRoundingAmount` of `cac:LegalMonetaryTotal`. The minus sign of a downward rounding comes before the point and is not counted; when tried, `-0.2` validated.

A small unrounded error can pass the amount due check and still fail here. When tried, `-0.204` reported only this rule and `UBL-DT-01`, because `BR-CO-16` rounds 70.00 + 0.204 to 70.20 before comparing. With `-0.206` the sum rounds to 70.21, and `BR-CO-16` was added.

A zero rounding amount must also be written with two decimals or fewer. When tried, the minimal invoice failed this rule with `0.000` in the element, and validated with the element removed.

| Term | Meaning | UBL element |
|---|---|---|
| BT-114 | Rounding amount | `cac:LegalMonetaryTotal/cbc:PayableRoundingAmount` |

## How an integration ends up here

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

- Cash rounding is computed in a type that keeps three or more decimals, and the difference between the rounded and unrounded amount due is written as it stands.
- The rounding difference is derived from an unrounded total with VAT, so it inherits the extra digits.
- A zero rounding amount is always sent, formatted with the precision used for prices.

## How to fix it

1. Round the total with VAT to two decimals, subtract the paid amount, then round the result to the payment step you use.
2. Take the rounding amount as the rounded figure minus the unrounded one, so that it is negative when you round down; with two-decimal inputs it has two decimals.
3. Write it to `cac:LegalMonetaryTotal/cbc:PayableRoundingAmount` with its sign and at most two decimals, or leave the element out when no rounding is applied.

## 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 rounding of -0.20 to an amount due of 70.00, written as -0.200

```xml
<cac:LegalMonetaryTotal>
  <!-- totals before the paid amount omitted from this fragment -->
  <cbc:PrepaidAmount currencyID="GBP">10.00</cbc:PrepaidAmount>
  <cbc:PayableRoundingAmount currencyID="GBP">-0.200</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="GBP">70.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: the rounding amount written as -0.20

```xml
<cac:LegalMonetaryTotal>
  <!-- totals before the paid amount omitted from this fragment -->
  <cbc:PrepaidAmount currencyID="GBP">10.00</cbc:PrepaidAmount>
  <cbc:PayableRoundingAmount currencyID="GBP">-0.20</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="GBP">70.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

Only the rounding amount is written differently, `-0.200` in the failing invoice and `-0.20` in the corrected one; the amount due is 70.00 in both, and `BR-CO-16` accepts either. The failing document reports `BR-DEC-17` at `cac:LegalMonetaryTotal` and `UBL-DT-01` at the `cbc:PayableRoundingAmount`. Because `UBL-DT-01` limits every amount element outside the item price and price-level allowances to two decimals, and the rounding amount is one of those elements, the two findings are reported together.

### What the validator reported

- The failing invoice reports **BR-DEC-17** 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-17-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 rounding amount of `-0.200` reported the same pair.
- The sign of the rounding amount makes no difference to the count, and neither does the currency.

## Related rules

- [UBL-DT-01 reports the rounding amount beside this rule](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-16 adds the rounding amount when it checks the amount due](https://ironfang.com/docs/finance/rules/BR-CO-16.md)
- [BR-DEC-16 applies the same limit to the paid amount before it](https://ironfang.com/docs/finance/rules/BR-DEC-16.md)
- [BR-DEC-18 applies the same limit to the amount due that the rounding produces](https://ironfang.com/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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

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