The short answer
BR-DEC-01 fails when the cbc:Amount of a document-level allowance, a cac:AllowanceCharge directly under the root with cbc:ChargeIndicator of false, has more than two characters after the decimal point. Round the allowance to two decimals and write it with no more.
The recorded 1.000 equals 1.00 as a number and still fails, because the check reads the text as written. UBL-DT-01 is reported for the same cbc:Amount, since it applies the same two-decimal limit to amounts generally.
What the rule checks
The rule selects each cac:AllowanceCharge that is a direct child of the Invoice or CreditNote root and whose cbc:ChargeIndicator is false, takes the text of its cbc:Amount, and counts what follows the first full stop. More than two characters fails.
A whole number has nothing after a decimal point to count; when tried, a document allowance of 1 validated cleanly.
Every character after the point counts, digits or not. When tried, 1.00 followed by a space inside the element failed this rule, although the schema accepts it as a number.
Neighbouring amounts have rules of their own. A document-level charge is BR-DEC-05, the allowance base amount is BR-DEC-02, and allowances on a line are BR-DEC-24. When tried, a document charge of 3.500 reported BR-DEC-05 and UBL-DT-01, not this rule.
| Term | Meaning | UBL element |
|---|---|---|
| BT-92 | Document level allowance amount | cac:AllowanceCharge/cbc:Amount (where cac:AllowanceCharge/cbc:ChargeIndicator is false) |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The discount is stored with three or four decimal places and serialised at the full scale of the column.
- One number formatter serves the whole document and is set to the precision the unit prices need.
- The allowance is a percentage of a total and is written before rounding. When tried, an unrounded
1.005also brokeBR-CO-11, because the allowance total of 1.00 no longer matched it.
How to fix it
- Round the allowance amount to two decimals once, when it is calculated, using the rounding your invoicing rules specify.
- Format the value with at most two decimals and no surrounding whitespace, and write it to
cbc:Amountin the document-levelcac:AllowanceCharge. - Build
cbc:AllowanceTotalAmountfrom the rounded allowance amounts, then the total without VAT from that, so every figure agrees with what is written. - If the allowance is a percentage of a base amount, write the base with two decimals as well; it has its own limit.
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: the document discount is written as 1.000
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Example document discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">1.000</cbc:Amount>
<!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>Fragment of the corrected invoice: the same discount written as 1.00
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Example document discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">1.00</cbc:Amount>
<!-- tax category omitted from this fragment -->
</cac:AllowanceCharge>Only the text of the allowance cbc:Amount differs: 1.000 in the failing invoice, 1.00 in the corrected one, which is the same value. The allowance total and the other totals were built on 1.00, so none of them is disturbed. The failing document reports two EN 16931 findings for the one element: BR-DEC-01 located at the cac:AllowanceCharge, and UBL-DT-01 located at its cbc:Amount. UBL-DT-01 limits every element whose name ends in Amount to two decimals, leaving out only the item net price and allowances inside cac:Price, so a document allowance that fails this rule fails that one too. Writing two decimals clears both.
What the validator reported
- The failing invoice reports BR-DEC-01 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 allowance of1.000reported the same pair of findings. - The count is the same for every currency, including ones whose minor unit is not two digits, because
currencyIDplays no part in it. - A decimal comma never reaches this rule. When tried,
1,00failed the XSD layer and the EN 16931 and Peppol layers were skipped.
Related rules
- UBL-DT-01 is reported beside this rule, applying the same limit to every amount element
- BR-CO-11 checks that the allowance total equals the sum of the document allowances
- BR-DEC-24 is the same limit for allowances on a line
- PEPPOL-EN16931-R040 checks an allowance amount against its base amount and percentage
- 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-01 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.
