BR-DEC-18: Write the amount due with no more than two decimals

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.

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.

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: 80.20 - 10.00 - 0.20 is written as 70.000

<cac:LegalMonetaryTotal>
  <!-- line, net, allowance and charge totals omitted from this fragment -->
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="GBP">10.00</cbc:PrepaidAmount>
  <cbc:PayableRoundingAmount currencyID="GBP">-0.20</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="GBP">70.000</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Fragment of the corrected invoice: the amount due written as 70.00

<cac:LegalMonetaryTotal>
  <!-- line, net, allowance and charge totals omitted from this fragment -->
  <cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
  <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 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.

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
• BR-CO-16 checks the value of the amount due against the total with VAT, the prepaid amount and the rounding amount
• BR-DEC-12 applies the same limit to the total without VAT
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of 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.