BR-DEC-23Write the line net amount with no more than two decimals

The short answer

BR-DEC-23 fails when cbc:LineExtensionAmount on a line is written with more than two digits after the decimal point. Round the line net amount to two decimals and format it that way: 25.00, not 25.000.

The check counts characters; it does not compare numbers. 25.000 is the same amount as 25.00 and still fails. The document reports UBL-DT-01 at the same time, which is the general form of the same limit for every amount element.

What the rule checks

For each cac:InvoiceLine or cac:CreditNoteLine, the rule takes the text of cbc:LineExtensionAmount, looks at whatever follows the first decimal point, and requires that to be at most two characters long.

Fewer decimals are fine. 25, 25.0 and 25.00 all pass.

Trailing zeros count towards the limit, and so does whitespace. 25.000 fails, and when tried, 25.00 followed by spaces inside the element failed as well, even though the schema accepts it as a number.

The rule reads only the line net amount. The item net price is not limited to two decimals: a price of 12.500 validated cleanly. The line total in cac:LegalMonetaryTotal has its own decimals rule.

How an integration ends up here

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

• The line net amount is formatted with the same precision as the unit price or the quantity, which legitimately carry more decimals.
• Quantity times price is written out unrounded, for example 3 at 19.995 giving 59.985.
• A database column of type decimal with three or four places is serialised with its full scale, trailing zeros included.
• A formatter pads the value to a fixed width and the padding ends up inside the element.

How to fix it

1. Calculate the line net amount with decimal arithmetic: quantity times net price, plus line charges, minus line allowances.
2. Round the result to two decimals once, at the end. Keep the extra precision on the price and quantity, where it is allowed.
3. Format with exactly two decimal places and no surrounding whitespace, and write that to cbc:LineExtensionAmount.
4. Build the document line total from the rounded line amounts, so the rounding does not open a gap that BR-CO-10 then reports.

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: the line net amount has three decimals

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.000</cbc:LineExtensionAmount>
  <!-- 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>

Fragment of the corrected invoice: the same amount with two decimals

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <!-- 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 formatting of cbc:LineExtensionAmount differs: 25.000 becomes 25.00. The failing document reports two findings in the EN 16931 layer. BR-DEC-23 is located at the line, and UBL-DT-01 at the amount element itself: that rule applies the two-decimal limit to every element whose name ends in Amount, apart from cbc:PriceAmount and the amounts of an allowance inside cac:Price, so a line net amount that breaks BR-DEC-23 breaks it too. One correction clears both. The second recorded example is a credit note with the same value on cac:CreditNoteLine, and it reports the same pair.

Where it applies

• Applies to cac:InvoiceLine in an Invoice and cac:CreditNoteLine in a CreditNote, with identical behaviour.
• The limit is two decimals whatever the currency. The rule does not look at currencyID.
• Other number formats never reach this rule. A comma as the decimal separator or an exponent such as 2.5E1 fails the XSD layer, and the EN 16931 and Peppol layers are then skipped.
• Negative amounts are treated the same way: the sign is before the decimal point and is not counted.

Related rules

• BR-CO-10 checks that the rounded line net amounts add up to the document line total
• PEPPOL-EN16931-R120 checks the line net amount against quantity, price, allowances and charges
• BR-27 is the other rule on the same line values: the net price must not be negative
• Browse every rule in the reference

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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.

The official definition of BR-DEC-23 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.