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
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.
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-111- 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-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 locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"vatAccountingCurrency": "PLN", "taxAmountInAccountingCurrency": 1218.45The 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.