# BR-DEC-25: Write the base amount of a line allowance with no more than two decimals

A line allowance has a `cbc:BaseAmount` with more than two digits after the decimal point. Write the base the percentage was applied to with two at most.

- 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-25/
- Explanation last updated: 2026-09-28

## The short answer

`BR-DEC-25` fails when an allowance on a line, a `cac:AllowanceCharge` inside `cac:InvoiceLine` or `cac:CreditNoteLine` with `cbc:ChargeIndicator` of `false`, has a `cbc:BaseAmount` with more than two digits after the decimal point. Write the amount the allowance percentage was applied to with two decimals at most, such as `40.00`.

In the recorded example only the base is at fault: the allowance amount of `2.00` and the percentage of 5 were already acceptable. The same element also brings `UBL-DT-01`, so one padded base produces two findings.

## What the rule checks

The rule selects each allowance directly inside a line and counts the characters after the first full stop in its `cbc:BaseAmount`; three or more fail. An allowance given as a fixed amount, with no base, has nothing to count and passes.

Only the written form counts, not the value. When tried, a base amount of `40` validated cleanly, while `40.004` failed in the same way as the recorded `40.000`.

The base of a discount on the price is the item gross price, in `cac:Price/cac:AllowanceCharge/cbc:BaseAmount`, and this rule does not reach it. When tried, a gross price written as `15.000` passed every layer.

The Peppol percentage check reads the same element, but by value. When tried, a base of `40.500`, which no longer gives the 2.00 allowance at 5 percent, also brought `PEPPOL-EN16931-R040`; `40.004` stayed within its tolerance of 0.02 and did not.

| Term | Meaning | UBL element |
|---|---|---|
| BT-137 | Invoice line allowance base amount | `cac:InvoiceLine/cac:AllowanceCharge/cbc:BaseAmount (cac:CreditNoteLine/cac:AllowanceCharge/cbc:BaseAmount in a credit note), where cbc:ChargeIndicator is false` |

## How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

- The base is the gross line value, quantity times a unit price held to three or four decimals, and it is serialised at that precision.
- The allowance amount is rounded before it is written, but the base it was calculated from is passed through untouched.
- The base is stored in a decimal column with a scale of three, and the serialiser writes every stored digit, turning 40 into `40.000`.

## How to fix it

1. Round the base amount to two decimals when the allowance is calculated, and apply the percentage to the rounded figure.
2. Write the result to `cbc:BaseAmount` in the line `cac:AllowanceCharge`, after `cbc:Amount`, with no digits beyond the second decimal and no whitespace.
3. Check the allowance amount against the rounded base: `PEPPOL-EN16931-R040` lets it differ from base times percentage divided by 100 by 0.02 at most.
4. If the discount was really given on the unit price, model it in `cac:Price/cac:AllowanceCharge` instead, where the gross price may keep its extra decimals.

## 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 5 percent line discount whose base is written as 40.000

```xml
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <!-- note, quantity, line net amount, accounting cost and order line reference omitted from this fragment -->
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Example discount</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>5</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="GBP">2.00</cbc:Amount>
    <cbc:BaseAmount currencyID="GBP">40.000</cbc:BaseAmount>
  </cac:AllowanceCharge>
  <!-- line charge, item and price omitted from this fragment -->
</cac:InvoiceLine>
```

Fragment of the corrected invoice: the same base written as 40.00

```xml
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Example discount</cbc:AllowanceChargeReason>
  <cbc:MultiplierFactorNumeric>5</cbc:MultiplierFactorNumeric>
  <cbc:Amount currencyID="GBP">2.00</cbc:Amount>
  <cbc:BaseAmount currencyID="GBP">40.00</cbc:BaseAmount>
</cac:AllowanceCharge>
```

The failing and corrected invoices differ in one element: the line allowance `cbc:BaseAmount` reads `40.000` in one and `40.00` in the other. Five percent of either is the 2.00 allowance both documents carry, so the Peppol percentage check and the line net amount of 58.00 are satisfied in each. The failing document reports `BR-DEC-25` at the line `cac:AllowanceCharge` and `UBL-DT-01` at the `cbc:BaseAmount` itself, because a base amount is an amount element like any other and is not among those `UBL-DT-01` exempts. Two decimals clear both.

### What the validator reported

- The failing invoice reports **BR-DEC-25** 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-25-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/invoice-rich.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 `cac:InvoiceLine` in an `Invoice` and `cac:CreditNoteLine` in a `CreditNote`. When tried, a credit note with a line allowance base of `40.000` reported the same two findings.
- Only allowances are selected. The base of a line charge belongs to `BR-DEC-28`, and the base of a document-level allowance to `BR-DEC-02`.
- A base amount without a percentage is a separate problem. When tried, removing `cbc:MultiplierFactorNumeric` from the failing line added `PEPPOL-EN16931-R042` to the two findings.

## Related rules

- [BR-DEC-24 holds the amount of the same line allowance to two decimals](https://ironfang.com/docs/finance/rules/BR-DEC-24.md)
- [BR-DEC-28 is the matching limit for the base amount of a line charge](https://ironfang.com/docs/finance/rules/BR-DEC-28.md)
- [UBL-DT-01 reports the base amount as well, as one of the amounts it limits to two decimals](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [PEPPOL-EN16931-R040 compares the allowance amount with this base amount and the percentage](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R040.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-25](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-25/) 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-25)
- [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