On this page
The short answer
BR-DEC-05 fails when the cbc:Amount of a charge on the whole document, a root-level cac:AllowanceCharge whose cbc:ChargeIndicator is true, has more than two characters after the decimal point. Round the charge to two decimals and write 3.50 rather than 3.500.
In the recorded invoice the charge is 10 percent of 35.00, correctly 3.50, and fails only because of the third digit. UBL-DT-01 reports the same cbc:Amount.
What the rule checks
The rule selects every cac:AllowanceCharge that is a direct child of the root and has cbc:ChargeIndicator set to true, and counts what follows the decimal point in its cbc:Amount. More than two characters fail, whatever they are.
A small unrounded remainder is caught here even when the arithmetic rules let it through. When tried, a charge of 3.504 reported only this rule and UBL-DT-01: BR-CO-12 rounds the sum of the charges to 3.50 before comparing it with the charge total, and PEPPOL-EN16931-R040 allows 0.02 against 10 percent of 35.00. At 3.506 the sum rounds to 3.51, and BR-CO-12 was reported as well.
The base amount of the same charge is counted by BR-DEC-06, and the amount of a document allowance by BR-DEC-01: the value of cbc:ChargeIndicator decides which rule reads the element.
| Term | Meaning | UBL element |
|---|---|---|
| BT-99 | Document level charge amount | cac:AllowanceCharge[cbc:ChargeIndicator = true]/cbc:Amount |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- A percentage charge is calculated as base times rate and the product is written without rounding.
- Freight or handling fees are held in a price table with three decimals and copied into the charge as stored.
- The charge and the unit prices go through one formatter, configured for the precision of the prices.
How to fix it
- Calculate the charge, round it to two decimals, and write that figure to
cbc:Amountin the document-levelcac:AllowanceChargewithcbc:ChargeIndicatoroftrue. - Build
cbc:ChargeTotalAmountfrom the rounded charges, so thatBR-CO-12compares like with like. - Add the rounded charge to the taxable amount of its VAT category, so that the VAT breakdown agrees with it.
- Format the base amount of a percentage charge the same way;
BR-DEC-06applies to it separately.
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 10 percent charge on 35.00 written as 3.500
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Example document charge</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="GBP">3.500</cbc:Amount>
<cbc:BaseAmount currencyID="GBP">35.00</cbc:BaseAmount>
<!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>Fragment of the corrected invoice: the same charge written as 3.50
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Example document charge</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="GBP">3.50</cbc:Amount>
<cbc:BaseAmount currencyID="GBP">35.00</cbc:BaseAmount>
<!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>The document charge is 3.500 in the failing invoice and 3.50 in the corrected one; its percentage, base amount and tax category are the same, and the charge total of 3.50 fits both. The failing document reports BR-DEC-05 at the second cac:AllowanceCharge, which is the charge, and UBL-DT-01 at the cbc:Amount inside it. UBL-DT-01 holds every amount element to two decimals except the item net price and the amounts of a price-level allowance, and a document charge is not among those exceptions, so the two findings arrive together and one correction clears both.
What the validator reported
- The failing invoice reports BR-DEC-05 and UBL-DT-01. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
InvoiceandCreditNote. When tried, a credit note with a document charge of3.500reported the same pair. - Only charges on the document are in scope. A charge on a line is counted by
BR-DEC-27, and Peppol does not allow a charge insidecac:Priceat all (PEPPOL-EN16931-R044). - The currency does not change the limit:
currencyIDplays no part in the count.
Related rules
- UBL-DT-01 is reported for the same charge amount, as the general two-decimal limit on amounts
- BR-CO-12 checks that the charge total equals the rounded sum of the document charges
- BR-DEC-06 applies the same limit to the base amount of a document charge
- BR-DEC-11 applies the same limit to the charge total in the monetary totals
- 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-05 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.

