Attestwire

Rule reference

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

The allowed maximum number of decimals for the Invoice total VAT amount (BT-110) is 2, but you declared 285.0004, 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. Applying a percentage produces a long decimal almost every time — 1 234.56 x 19% is 234.5664. VAT is rounded per VAT breakdown group (BR-CO-17) and the rounded group amounts are then summed, so the total should never carry more than two decimals.

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-110
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-13",
  "field": "BT-110",
  "severity": "fatal",
  "message": "The allowed maximum number of decimals for the Invoice total VAT amount (BT-110) is 2, but you declared 285.0004, 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. Applying a percentage produces a long decimal almost every time — 1 234.56 x 19% is 234.5664. VAT is rounded per VAT breakdown group (BR-CO-17) and the rounded group amounts are then summed, so the total should never carry more than two decimals.",
  "fix": "Round declaredTotals.taxAmount to two decimals before assigning it (285.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\": { \"taxAmount\": 285.00 }",
  "xpath": "/ubl:Invoice/cac:TaxTotal/cbc:TaxAmount",
  "docsUrl": "https://attestwire.com/rules/BR-DEC-13"
}

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": { "taxAmount": 285.00 }

The fix

Round declaredTotals.taxAmount to two decimals before assigning it (285.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-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; BR-DEC-12 — The allowed maximum number of decimals for the Invoice total amount without VAT (BT-109) is 2, but you declared 1500.001, which has 3; 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.

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.