Attestwire

Rule reference

BR-DEC-14 The allowed maximum number of decimals for the Invoice total amount with VAT (BT-112) is 2, but you declared 1785.0011, which has 4

The allowed maximum number of decimals for the Invoice total amount with VAT (BT-112) 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. BT-112 is BT-109 + BT-110; if either of those is over-precise this one will be too.

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-112
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-14",
  "field": "BT-112",
  "severity": "fatal",
  "message": "The allowed maximum number of decimals for the Invoice total amount with VAT (BT-112) 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. BT-112 is BT-109 + BT-110; if either of those is over-precise this one will be too.",
  "fix": "Round declaredTotals.taxInclusiveAmount 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\": { \"taxInclusiveAmount\": 1785.00 }",
  "xpath": "/ubl:Invoice/cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount",
  "docsUrl": "https://attestwire.com/rules/BR-DEC-14"
}

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
"declaredTotals": { "taxInclusiveAmount": 1785.00 }

The fix

Round declaredTotals.taxInclusiveAmount 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.

All 292 rules →

Nearby: BR-DEC-15 — The invoice total VAT amount in accounting currency (BT-111) is 100.005, which carries 3 decimals; EN 16931 allows at most 2; BR-DEC-13 — The allowed maximum number of decimals for the Invoice total VAT amount (BT-110) is 2, but you declared 285.0004, which has 4; BR-DEC-16 — The paid amount (BT-113) is 10.005, which carries 3 decimals; EN 16931 allows at most 2.

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.