BR-DEC-18 The allowed maximum number of decimals for the Amount due for payment (BT-115) is 2, but you declared 1785.0011, which has 4
The allowed maximum number of decimals for the Amount due for payment (BT-115) is 2, but you declared 1785.0011, which has 4. The rule is written against the serialised value — the schematron measures the digits after the decimal point in the XML — so a value that merely *displays* as two decimals still fails if the underlying number carries more. This is the figure the buyer actually pays. No payment system can settle a fraction of a cent, which is why the rounding amount (BT-114) exists as a separate, disclosed business term rather than being hidden in the payable amount.
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-115- Severity
fatal
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "BR-DEC-18",
"field": "BT-115",
"severity": "fatal",
"message": "The allowed maximum number of decimals for the Amount due for payment (BT-115) is 2, but you declared 1785.0011, which has 4. The rule is written against the serialised value — the schematron measures the digits after the decimal point in the XML — so a value that merely *displays* as two decimals still fails if the underlying number carries more. This is the figure the buyer actually pays. No payment system can settle a fraction of a cent, which is why the rounding amount (BT-114) exists as a separate, disclosed business term rather than being hidden in the payable amount.",
"fix": "Round declaredTotals.payableAmount to two decimals before assigning it (1785.00 here), using half-up rounding away from zero. This package exports round2() for exactly this, and it avoids the two JavaScript traps: Math.round(1.005 * 100) / 100 gives 1.00, and (2.675).toFixed(2) gives \"2.67\". Alternatively drop declaredTotals and let the library compute the totals, which it always rounds correctly.",
"example": "\"declaredTotals\": { \"payableAmount\": 1785.00 }",
"xpath": "/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount",
"docsUrl": "https://attestwire.com/rules/BR-DEC-18"
}
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
"declaredTotals": { "payableAmount": 1785.00 }The fix
Round declaredTotals.payableAmount to two decimals before assigning it (1785.00 here), using half-up rounding away from zero. This package exports round2() for exactly this, and it avoids the two JavaScript traps: Math.round(1.005 * 100) / 100 gives 1.00, and (2.675).toFixed(2) gives "2.67". Alternatively drop declaredTotals and let the library compute the totals, which it always rounds correctly.