On this page
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
- Round each line net amount to two decimals first, then add the rounded amounts for the total.
- Write the sum to
cac:LegalMonetaryTotal/cbc:LineExtensionAmountwith at most two decimals and no whitespace. - Derive the total without VAT from the same rounded figure, so that
BR-CO-10andBR-CO-13both agree with what is written.
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: lines of 58.00, 10.00 and -2.00 totalled as 66.000
<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
<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. 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 UBL
InvoiceandCreditNote. When tried, a credit note with a line total of66.000reported 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
- BR-CO-10 checks that the line total is the rounded sum of the line net amounts
- BR-DEC-23 counts the decimals of each line net amount
- BR-DEC-10 applies the same limit to the allowance total in the same block
- 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-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.

