Skip to content

Ironfang Finance - Rule reference

BR-DEC-28: Write the base amount of a line charge with no more than two decimals

A percentage charge on an invoice line has a cbc:BaseAmount with more than two digits after the decimal point. Write the charge base with two at most.

EN 16931Fatal: the document is invalidAllowances and chargesLines and prices

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.

TermMeaningUBL element
BT-142Invoice line charge base amountcac: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

  1. Round the base amount of the charge to two decimals, then calculate the charge from the rounded base.
  2. Write the rounded base to cbc:BaseAmount, after cbc:Amount, in the line cac:AllowanceCharge.
  3. Keep cbc:MultiplierFactorNumeric alongside it: a base amount without a percentage is rejected by PEPPOL-EN16931-R042.
  4. 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

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 Invoice and CreditNote. When tried, a credit note line carrying the same surcharge with a base of 25.000 reported the same pair.
  • The base of a document-level charge is checked by BR-DEC-06 instead. When tried, the document charge base of the rich example invoice written as 35.000 reported BR-DEC-06 and UBL-DT-01.
  • Line allowances have the mirror rule BR-DEC-25 for their base amount.
  • A base amount is only expected together with a percentage. When tried, the padded base with cbc:MultiplierFactorNumeric removed reported PEPPOL-EN16931-R042 as well.

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.