BR-DEC-18 — E-Invoice Validation Rule & Fix

Fixture ID: overPreciseTotals · XPath: /ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount

1. Why This Rule Triggers (Diagnostic 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.

2. How to Fix BR-DEC-18

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.

3. Valid Code / Payload Example

"declaredTotals": { "payableAmount": 1785.00 }