# BR-DEC-09: Write the sum of line net amounts with no more than two decimals

`cbc:LineExtensionAmount` in `cac:LegalMonetaryTotal` has more than two digits after the decimal point. Write the sum of the line net amounts to two decimals.

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

## The short answer

`BR-DEC-09` fails when the line total at document level, `cac:LegalMonetaryTotal/cbc:LineExtensionAmount`, is written with more than two characters after the decimal point. Write it as `66.00`, not `66.000`.

Each line carries an element with the same name, and those are counted by `BR-DEC-23`. This finding is located at `cac:LegalMonetaryTotal`, which tells you that the total, not a line, needs rounding; `UBL-DT-01` reports the total too.

## What the rule checks

The rule reads the `cbc:LineExtensionAmount` that is a child of `cac:LegalMonetaryTotal`, and fails when more than two characters follow its first full stop. The line amounts of the same name are not looked at.

When tried with the minimal invoice, padding both its single line and its line total to `25.000` gave four findings: this rule at the monetary totals, `BR-DEC-23` at the line, and `UBL-DT-01` once for each element.

An unrounded line total fails the arithmetic as well. When tried, `66.004` also reported `BR-CO-10`, which rounds the sum of the lines to 66.00 and compares exactly; `BR-CO-13` did not object, because it rounds 66.004 + 3.50 - 1.00 back to 68.50.

| Term | Meaning | UBL element |
|---|---|---|
| BT-106 | Sum of Invoice line net amount | `cac:LegalMonetaryTotal/cbc:LineExtensionAmount` |

## How an integration ends up here

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

- The line total is added up from line amounts before they are rounded, then written at the precision of the sum.
- The total is summed in floating point and formatted with three fixed decimal places.
- The same formatter writes the item net prices, which may keep more decimals, and the document totals.

## How to fix it

1. Round each line net amount to two decimals first, then add the rounded amounts for the total.
2. Write the sum to `cac:LegalMonetaryTotal/cbc:LineExtensionAmount` with at most two decimals and no whitespace.
3. Derive the total without VAT from the same rounded figure, so that `BR-CO-10` and `BR-CO-13` both agree with what is written.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: lines of 58.00, 10.00 and -2.00 totalled as 66.000

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">66.000</cbc:LineExtensionAmount>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <!-- note and quantity omitted from this fragment -->
  <cbc:LineExtensionAmount currencyID="GBP">58.00</cbc:LineExtensionAmount>
  <!-- rest of line 1 omitted from this fragment -->
</cac:InvoiceLine>
<!-- lines 2 and 3 omitted from this fragment -->
```

Fragment of the corrected invoice: the same total written as 66.00

```xml
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="GBP">66.00</cbc:LineExtensionAmount>
  <!-- remaining totals omitted from this fragment -->
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <!-- note and quantity omitted from this fragment -->
  <cbc:LineExtensionAmount currencyID="GBP">58.00</cbc:LineExtensionAmount>
  <!-- rest of line 1 omitted from this fragment -->
</cac:InvoiceLine>
<!-- lines 2 and 3 omitted from this fragment -->
```

The line total in `cac:LegalMonetaryTotal` is `66.000` in the failing invoice and `66.00` in the corrected one, while the three lines, 58.00, 10.00 and -2.00, are unchanged. The total is the right sum, so `BR-CO-10` passes in both. The failing document reports `BR-DEC-09` at `cac:LegalMonetaryTotal` and `UBL-DT-01` at the `cbc:LineExtensionAmount` inside it. `UBL-DT-01` covers every element whose name ends in `Amount` apart from item prices and price-level allowance amounts, and the sum of the line net amounts is not exempt, so the two appear as a pair.

### What the validator reported

- The failing invoice reports **BR-DEC-09** 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-09-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 UBL `Invoice` and `CreditNote`. When tried, a credit note with a line total of `66.000` reported the same two findings.
- The limit is the same two decimals in any currency.
- The line total is mandatory under `BR-12`, so in a complete document this rule always has a value to count.

## Related rules

- [UBL-DT-01 reports the padded line total as well, under its limit for all amounts](https://ironfang.com/docs/finance/rules/UBL-DT-01.md)
- [BR-CO-10 checks that the line total is the rounded sum of the line net amounts](https://ironfang.com/docs/finance/rules/BR-CO-10.md)
- [BR-DEC-23 counts the decimals of each line net amount](https://ironfang.com/docs/finance/rules/BR-DEC-23.md)
- [BR-DEC-10 applies the same limit to the allowance total in the same block](https://ironfang.com/docs/finance/rules/BR-DEC-10.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-09](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-DEC-09/) 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-09)
- [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