Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-103 | Schematron ID: ibr-124 | Fatal (error) | cac:TaxTotal/cbc:TaxAmount (document-level tax total) |
Assert text: [ibr-124]-Invoice total TAX amount (ibt-110) MUST have no more than 2 decimals.
Test: string-length(substring-after(cbc:TaxAmount, '.')) <= 2
Classification
Transaction Data. The rule checks the precision of the document-level VAT total specifically — the figure the FTA reads as the actual output tax the invoice asserts.
What the Rule Is Checking
Invoice Total Tax Amount (IBT-110) is the VAT payable on the invoice as a whole, summed from the tax category subtotals (IBT-117) that break the total down by rate. This rule requires the summed figure to carry no more than two decimal places. It sits directly alongside ibr-co-14, which checks that the total tax amount actually equals the sum of its category subtotals — a precision failure here is often the first symptom of a rounding mismatch that would also fail that arithmetic check.
Why This Rule Exists
This is the field with the most direct tax consequence of any total in the document: it is the VAT amount the invoice declares, and it is what an FTA reconciliation would compare against the seller's VAT return. A value carrying more than two decimals cannot represent an actual AED amount, which means either the underlying calculation produced a raw unrounded figure, or a currency conversion or apportionment step introduced precision the currency does not support. Either way, the figure written into the document is not one that could exist as a real payment obligation, and it undermines confidence in every other total derived alongside it.
UAE Data Example
PASSES ✓
<cac:TaxTotal>
<cbc:TaxAmount currencyID="AED">237.50</cbc:TaxAmount>
</cac:TaxTotal>FAILS ✗
<cac:TaxTotal>
<cbc:TaxAmount currencyID="AED">237.5049</cbc:TaxAmount>
</cac:TaxTotal>The tax total carries four decimal places, most likely because it was summed from tax category subtotals that were each calculated at higher precision and never rounded before the summation step.
What Your ERP / IT Team Must Ensure
- Round each VAT category subtotal to two decimals before summing them into the document-level tax total, rather than rounding only the final summed figure — the order of operations affects whether the total agrees with ibr-co-14's arithmetic check.
- Confirm the tax engine's rounding configuration matches across every VAT category present on mixed-rate invoices (standard-rated and zero-rated lines together), since a per-category rounding inconsistency compounds at the total level.
- Pay particular attention to invoices with foreign-currency lines converted to AED, where a currency conversion step is a common source of precision beyond two decimals reaching the tax total.
- Treat this field's validation as a priority in pre-transmission testing given its direct link to the declared VAT liability — a rejected invoice on this rule blocks the transaction, but an undetected rounding drift that somehow passed would be a VAT return discrepancy waiting to surface later.