# BR-DEC-27: Write the line charge amount with no more than two decimals

A charge on an invoice line has a `cbc:Amount` with more than two digits after the decimal point. Round the line charge to two decimals before writing it.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Allowances and charges, Lines and prices
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-27/
- Explanation last updated: 2026-09-28

## 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

1. Round the line charge to two decimals at the point it is calculated, using the rounding rule of your invoicing system.
2. Write the rounded value to `cbc:Amount` in the line `cac:AllowanceCharge` whose `cbc:ChargeIndicator` is `true`, without padding and without whitespace.
3. 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.
4. Format the base amount of the charge, if there is one, with the same two-decimal rule; it is checked separately.

## 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

```xml
<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

```xml
<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](https://ironfang.com/docs/finance/rules/UBL-DT-01.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-DEC-27-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/line-surcharge-valid.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 `Invoice` and `CreditNote`. When tried, a credit note line with the same surcharge written as `2.500` reported the same pair.
- Document-level charges are outside this rule; `BR-DEC-05` limits 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.525` case above shows.

## Related rules

- [BR-DEC-28 limits the base amount of the same line charge](https://ironfang.com/docs/finance/rules/BR-DEC-28.md)
- [UBL-DT-01 is reported on the charge amount alongside this rule](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [PEPPOL-EN16931-R120 checks that the line net amount includes the line charges](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R120.md)
- [BR-DEC-05 is the same limit for charges at document level](https://ironfang.com/docs/finance/rules/BR-DEC-05.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-DEC-27)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp