Attestwire

Rule reference

BR-DEC-24 The allowed maximum number of decimals for the invoice line allowance amount (BT-136) is 2, but lines[0].allowances[0].amount is 1.005, which has 3

The allowed maximum number of decimals for the invoice line allowance amount (BT-136) is 2, but lines[0].allowances[0].amount is 1.005, which has 3. The constraint is on the serialised value, so it is about what reaches the XML rather than about what your variable holds — and the line is where over-precision starts, since every document total downstream of it inherits the drift. A line allowance is subtracted from the line net amount (BT-131), and BT-131 must land on two decimals. Rounding the line total while leaving the allowance long only hides the extra digits from your own display — they still reach the XML.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BT-136
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "BR-DEC-24",
  "field": "BT-136",
  "severity": "fatal",
  "message": "The allowed maximum number of decimals for the invoice line allowance amount (BT-136) is 2, but lines[0].allowances[0].amount is 1.005, which has 3. The constraint is on the serialised value, so it is about what reaches the XML rather than about what your variable holds — and the line is where over-precision starts, since every document total downstream of it inherits the drift. A line allowance is subtracted from the line net amount (BT-131), and BT-131 must land on two decimals. Rounding the line total while leaving the allowance long only hides the extra digits from your own display — they still reach the XML.",
  "fix": "Round lines[0].allowances[0].amount to two decimals before assigning it (1.00 here). Use half-up rounding away from zero — this package exports round2(), which handles the cases Math.round and toFixed get wrong.",
  "example": "\"amount\": 1.00",
  "xpath": "/ubl:Invoice/cac:InvoiceLine[1]/cac:AllowanceCharge[1]/cbc:Amount",
  "docsUrl": "https://attestwire.com/rules/BR-DEC-24"
}

xpath locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"amount": 1.00

The fix

Round lines[0].allowances[0].amount to two decimals before assigning it (1.00 here). Use half-up rounding away from zero — this package exports round2(), which handles the cases Math.round and toFixed get wrong.

All 292 rules →

Nearby: BR-DEC-25 — The allowed maximum number of decimals for the invoice line allowance base amount (BT-137) is 2, but lines[0].allowances[0].baseAmount is 10.005, which has 3; BR-DEC-23 — The amount due for payment, at two decimals; BR-DEC-27 — The allowed maximum number of decimals for the invoice line charge amount (BT-141) is 2, but lines[0].charges[0].amount is 1.005, which has 3.

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.