Skip to content

BR-DEC-16: Paid amount (BT-113) has more than two decimals

Official message

[BR-DEC-16] The allowed maximum number of decimals for the Paid amount (BT-113) is 2.

EN 16931 (CII) · Error · Message language: English · Version: xrechnung-3.0.2-validator-configuration-2026-08-31

[BR-DEC-16] The allowed maximum number of decimals for the Paid amount (BT-113) is 2.

EN 16931 (UBL) · Error · Message language: English · Version: xrechnung-3.0.2-validator-configuration-2026-08-31

[BR-DEC-16] The allowed maximum number of decimals for the Paid amount (BT-113) is 2.

Factur-X / ZUGFeRD EN 16931 · Error · Message language: English · Version: Factur-X 1.08 / ZUGFeRD 2.4
Severity
Error The invoice is invalid and may be rejected by the recipient.
Applies to
EN 16931 (CII), EN 16931 (UBL), Factur-X / ZUGFeRD EN 16931
Affected fields
BT-113

What does this mean?

The paid amount (BT-113) may have at most two decimals. In the invoice the amount has more than two decimals.

Typical causes

The amount was entered with more than two decimals or taken over from another system.
The generating system writes amounts with a fixed number of three or four decimals, e.g. 100.0000; trailing zeros count as well.

How to fix the error

Round the amount to two decimals and write it without further digits, e.g. 100.00 instead of 100.0000.
Recalculate the amount due for payment (BT-115) with the rounded amount (BR-CO-16).
CII: ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:TotalPrepaidAmount, UBL: cac:LegalMonetaryTotal/cbc:PrepaidAmount.
Generate and validate the invoice again.

In E-Rechnungsfreund

In the invoice form, section "Belegsummen (BG-22)" (document totals), check the field "Bereits gezahlt (BT-113)" (already paid). When the XML is generated the value is rounded to two decimals; then validate the invoice again.

Example

Wrong

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  ...
  <ram:TotalPrepaidAmount>500.000</ram:TotalPrepaidAmount>
  ...
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Correct

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  ...
  <ram:TotalPrepaidAmount>500.00</ram:TotalPrepaidAmount>
  ...
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
For developers: test expression per syntax

EN 16931 (CII) (CII)

Context: //ram:SpecifiedTradeSettlementHeaderMonetarySummation

string-length(substring-after(ram:TotalPrepaidAmount,'.'))<=2

EN 16931 (UBL) (UBL)

Context: cac:LegalMonetaryTotal

string-length(substring-after(cbc:PrepaidAmount,'.'))<=2

Factur-X / ZUGFeRD EN 16931 (CII)

Technical ID in the source: FX-SCH-A-000127

Context: //ram:SpecifiedTradeSettlementHeaderMonetarySummation

string-length(substring-after(ram:TotalPrepaidAmount,'.'))<=2

Related validation rules

  • BR-DEC-01: Document level allowance amount (BT-92) has more than two decimals
  • BR-DEC-02: Document level allowance base amount (BT-93) has more than two decimals
  • BR-DEC-05: Document level charge amount (BT-99) has more than two decimals
  • BR-DEC-06: Document level charge base amount (BT-100) has more than two decimals
  • BR-DEC-09: Sum of invoice line net amounts (BT-106) has more than two decimals
  • BR-DEC-10: Sum of allowances on document level (BT-107) has more than two decimals

Frequently asked questions

Is 100.000 allowed because its value equals 100.00?

No. The check counts the characters after the decimal point, not the numeric value. 100.000 has three decimals and triggers the rule; 100, 100.0 and 100.00 are allowed.

Last updated:
Explanation of the validation rule, not legal or tax advice.