On this page
The short answer
BR-DEC-28 fails when a line-level cac:AllowanceCharge with cbc:ChargeIndicator of true has a cbc:BaseAmount with more than two digits after the decimal point. In the recorded example the surcharge is 10 percent of 25.000; write the base as 25.00.
The charge amount beside it can be perfectly formed and the rule still fails, because it reads the base amount alone. Rounding the base here does not change what the percentage produces, so no other figure has to move.
What the rule checks
The rule runs on every charge directly inside a line and reads only its cbc:BaseAmount. More than two characters after the decimal point fail; a charge that has no base amount passes.
When both figures of a charge are padded, each has its own rule. When tried, writing the surcharge as 2.500 on a base of 25.000 reported this rule, BR-DEC-27 and UBL-DT-01 twice, once for each element.
A base that is slightly off can pass the percentage check and still fail here. When tried, 24.995 reported only this rule and UBL-DT-01, since 10 percent of it is within 0.02 of the 2.50 charge.
The EN 16931 layer reads cbc:ChargeIndicator as a boolean when deciding what is a charge. When tried, an indicator of 1 still made this rule report the padded base, while the Peppol layer rejected the 1 with PEPPOL-EN16931-R043 and, no longer counting the charge in the line net amount, reported PEPPOL-EN16931-R120.
| Term | Meaning | UBL element |
|---|---|---|
| BT-142 | Invoice line charge base amount | cac:InvoiceLine/cac:AllowanceCharge/cbc:BaseAmount (cac:CreditNoteLine/cac:AllowanceCharge/cbc:BaseAmount in a credit note), where cbc:ChargeIndicator is true |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The base is the line value before the surcharge, calculated from a unit price with three decimals and never rounded.
- The code rounds the charge amount it writes but hands the base amount to the serialiser as the raw input of the calculation.
- A shared formatter pads every amount of the charge to the scale of its database column.
How to fix it
- Round the base amount of the charge to two decimals, then calculate the charge from the rounded base.
- Write the rounded base to
cbc:BaseAmount, aftercbc:Amount, in the linecac:AllowanceCharge. - Keep
cbc:MultiplierFactorNumericalongside it: a base amount without a percentage is rejected byPEPPOL-EN16931-R042. - Confirm that the charge amount is within 0.02 of the rounded base times the percentage divided by 100, and that the line net amount still adds up.
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 surcharge whose base is written as 25.000
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<!-- quantity and line net amount omitted from this fragment -->
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Out-of-hours surcharge</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="GBP">2.50</cbc:Amount>
<cbc:BaseAmount currencyID="GBP">25.000</cbc:BaseAmount>
</cac:AllowanceCharge>
<!-- item and price omitted from this fragment -->
</cac:InvoiceLine>Fragment of the corrected invoice: the same base written as 25.00
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Out-of-hours surcharge</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="GBP">2.50</cbc:Amount>
<cbc:BaseAmount currencyID="GBP">25.00</cbc:BaseAmount>
</cac:AllowanceCharge>The corrected invoice writes the surcharge base as 25.00 where the failing one has 25.000; the charge of 2.50, the percentage of 10 and the line net amount of 27.50 are the same in both. The failing document reports BR-DEC-28 at the line cac:AllowanceCharge and UBL-DT-01 at the cbc:BaseAmount, the general two-decimal limit on amounts reaching the same element. Nothing in the Peppol layer objects, because the value of the base is unchanged.
What the validator reported
- The failing invoice reports BR-DEC-28 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
InvoiceandCreditNote. When tried, a credit note line carrying the same surcharge with a base of25.000reported the same pair. - The base of a document-level charge is checked by
BR-DEC-06instead. When tried, the document charge base of the rich example invoice written as35.000reportedBR-DEC-06andUBL-DT-01. - Line allowances have the mirror rule
BR-DEC-25for their base amount. - A base amount is only expected together with a percentage. When tried, the padded base with
cbc:MultiplierFactorNumericremoved reportedPEPPOL-EN16931-R042as well.
Related rules
- BR-DEC-27 limits the amount of the same line charge to two decimals
- BR-DEC-25 applies the same limit to the base amount of a line allowance
- UBL-DT-01 reports the padded base amount together with this rule
- PEPPOL-EN16931-R042 requires a percentage wherever a charge gives a base 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-28 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.

