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

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.

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.

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

<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

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

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
• BR-CO-16 subtracts the paid amount from the total with VAT to check the amount due
• BR-DEC-14 applies the same limit to the total with VAT that the paid amount is deducted from
• BR-DEC-17 applies the same limit to the rounding amount
• 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-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.