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

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.

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.

Validate your corrected invoice

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

<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

<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.

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
• BR-CO-16 adds the rounding amount when it checks the amount due
• BR-DEC-16 applies the same limit to the paid amount before it
• BR-DEC-18 applies the same limit to the amount due that the rounding produces
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

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 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.