Attestwire › Rule reference › BR-DEC-15
BR-DEC-15 The VAT total in accounting currency may have at most two decimals
noun · EN 16931 · fatal · BT-111
For a sample invoice, the library reports: The invoice total VAT amount in accounting currency (BT-111) is 100.005, which carries 3 decimals; EN 16931 allows at most 2. The limit applies to the value as serialised, and it is not cosmetic — it is what makes the figure a *statement of tax due* rather than an intermediate result.
- Business term
BT-111- Severity
fatal
The fix
Round taxAmountInAccountingCurrency to 2 decimals yourself, using the rounding rule your tax authority prescribes for the conversion — which rounding is correct is a tax question rather than an arithmetic one, and only you know the answer. The generator will not let an over-precise value reach the XML (it writes every amount through formatAmount, which rounds half-up to 2 decimals), but that means it would silently substitute its own answer for yours, so fix the figure at source rather than relying on it.
A passing value
"vatAccountingCurrency": "PLN", "taxAmountInAccountingCurrency": 1218.45What the library returns
The full error returned by @attestwire/en16931. It includes the rule ID,
affected field and suggested correction. Developers can use this object in their application:
{
"rule": "BR-DEC-15",
"field": "BT-111",
"severity": "fatal",
"message": "The invoice total VAT amount in accounting currency (BT-111) is 100.005, which carries 3 decimals; EN 16931 allows at most 2. The limit applies to the value as serialised, and it is not cosmetic — it is what makes the figure a *statement of tax due* rather than an intermediate result. Converted amounts are where this goes wrong most often: multiplying by an exchange rate produces as many decimals as the rate has, and the rounding has to happen before the amount reaches the document, not after.",
"fix": "Round taxAmountInAccountingCurrency to 2 decimals yourself, using the rounding rule your tax authority prescribes for the conversion — which rounding is correct is a tax question rather than an arithmetic one, and only you know the answer. The generator will not let an over-precise value reach the XML (it writes every amount through formatAmount, which rounds half-up to 2 decimals), but that means it would silently substitute its own answer for yours, so fix the figure at source rather than relying on it.",
"example": "\"vatAccountingCurrency\": \"PLN\", \"taxAmountInAccountingCurrency\": 1218.45",
"xpath": "/ubl:Invoice/cac:TaxTotal[2]/cbc:TaxAmount",
"docsUrl": "https://attestwire.com/rules/BR-DEC-15"
}
xpath is always a UBL path. On a CII invoice, look for the
matching CII field instead.