On this page
The short answer
BR-DEC-27 fails when a charge on a line, a cac:AllowanceCharge inside cac:InvoiceLine or cac:CreditNoteLine whose cbc:ChargeIndicator is true, has a cbc:Amount with more than two digits after the decimal point. Round the charge to two decimals and write it as, for example, 2.50.
A line charge is added to the line net amount, so it has to be a figure that can be paid. Unlike a discount, it has no price-level form that could keep extra decimals: PEPPOL-EN16931-R044 does not allow charges inside cac:Price at all.
What the rule checks
The rule picks out the line allowances and charges whose indicator is true and counts what follows the decimal point in their cbc:Amount. More than two characters fail, so the recorded 2.500 fails although its value is 2.5.
Fewer decimals are always accepted. When tried, the same surcharge written as 2.5 passed every layer.
Whether the charge is a percentage makes no difference. When tried, a fixed surcharge of 2.500 with no base amount or percentage reported this rule and UBL-DT-01, exactly as the percentage charge did.
An unrounded charge can break the arithmetic too. When tried, 2.525 also brought PEPPOL-EN16931-R040 and PEPPOL-EN16931-R120, because it is more than 0.02 away from 10 percent of 25.00 and from the line net amount it should produce; 2.504 stayed within both tolerances and reported only the decimals findings.
| Term | Meaning | UBL element |
|---|---|---|
| BT-141 | Invoice line charge amount | cac:InvoiceLine/cac:AllowanceCharge/cbc:Amount (cac:CreditNoteLine/cac:AllowanceCharge/cbc:Amount 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 surcharge is calculated as a percentage of the line value and written with the precision of the calculation.
- Charges and unit prices share one number format, set to three decimals because some prices need them.
- A charge stored in a column with a scale of three or four is serialised at full scale.
How to fix it
- Round the line charge to two decimals at the point it is calculated, using the rounding rule of your invoicing system.
- Write the rounded value to
cbc:Amountin the linecac:AllowanceChargewhosecbc:ChargeIndicatoristrue, without padding and without whitespace. - Use the rounded charge, not the unrounded one, when you build the line net amount, and keep it within 0.02 of base amount times percentage divided by 100 if you send both.
- Format the base amount of the charge, if there is one, with the same two-decimal rule; it is checked 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 surcharge on 25.00 written as 2.500
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="GBP">27.50</cbc:LineExtensionAmount>
<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.500</cbc:Amount>
<cbc:BaseAmount currencyID="GBP">25.00</cbc:BaseAmount>
</cac:AllowanceCharge>
<!-- item and price omitted from this fragment -->
</cac:InvoiceLine>Fragment of the corrected invoice: the surcharge written as 2.50, with two units at 12.5 making up the rest of the 27.50
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="GBP">27.50</cbc:LineExtensionAmount>
<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>
<!-- item omitted from this fragment -->
<cac:Price>
<cbc:PriceAmount currencyID="GBP">12.5</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>
</cac:InvoiceLine>Only the surcharge cbc:Amount changes: 2.500 in the failing invoice, 2.50 in the corrected one. Both equal 10 percent of the 25.00 base, and two units at 12.5 plus the surcharge make the 27.50 line net amount in each, so the Peppol arithmetic passes either way. The failing document reports BR-DEC-27 at the line cac:AllowanceCharge and UBL-DT-01 at its cbc:Amount: every amount outside the item price and price-level discounts is capped at two decimals, a line charge included. Rewriting the one value clears both.
What the validator reported
- The failing invoice reports BR-DEC-27 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 with the same surcharge written as2.500reported the same pair. - Document-level charges are outside this rule;
BR-DEC-05limits them in the same way. - The EN 16931 layer reports it. The Peppol layer checks values rather than their written form, so it only joins in when the charge is also arithmetically wrong, as the
2.525case above shows.
Related rules
- BR-DEC-28 limits the base amount of the same line charge
- UBL-DT-01 is reported on the charge amount alongside this rule
- PEPPOL-EN16931-R120 checks that the line net amount includes the line charges
- BR-DEC-05 is the same limit for charges at document level
- 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-27 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.

