Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-102 | Schematron ID: ibr-123 | Fatal (error) | cbc:TaxExclusiveAmount (document totals block) |
Assert text: [ibr-123]-Invoice total amount without TAX (ibt-109) MUST have no more than 2 decimals.
Test: string-length(substring-after(cbc:TaxExclusiveAmount, '.')) <= 2
Classification
Transaction Data. The rule checks the precision of one specific total on one specific invoice at the moment it is transmitted.
What the Rule Is Checking
Invoice Total Amount Without Tax (IBT-109) is the net value of the invoice before VAT — the figure derived from summing line net amounts and adjusting for document-level allowances and charges. This rule requires that value to carry no more than two digits after the decimal point. It is the same precision check applied across every monetary total in the document, but this particular field carries extra weight because it is the base figure the arithmetic reconciliation rules (ibr-co-13 and related) use to verify that line totals, allowances, charges and the tax-exclusive total all agree with each other.
Why This Rule Exists
The tax-exclusive total is the anchor value for the whole totals block: VAT is calculated against it, the tax-inclusive total is derived from it, and the amount due for payment traces back through it. A rounding inconsistency at this single point propagates through every downstream figure. Holding it to exactly two decimals is what allows a receiving system, an ASP, or the FTA's own reconciliation logic to re-derive the invoice total independently and confirm it matches what the sender declared — that check only works if every party is rounding to the same precision at the same point in the calculation.
UAE Data Example
PASSES ✓
<cbc:TaxExclusiveAmount currencyID="AED">4750.00</cbc:TaxExclusiveAmount>FAILS ✗
<cbc:TaxExclusiveAmount currencyID="AED">4750.0033</cbc:TaxExclusiveAmount>Four decimal places on the base figure that the VAT calculation, the tax-inclusive total and the payable amount are all derived from — the error does not stay contained to this one field.
What Your ERP / IT Team Must Ensure
- Round the tax-exclusive total to two decimals as the final step of the calculation chain in the source system, before the value reaches the PINT-AE mapping layer — not as a formatting step applied only when generating the XML.
- Confirm the summation logic (line net amounts plus charges minus allowances) uses consistent rounding at each intermediate step, since summing already-rounded lines can still drift by a cent from a total calculated on unrounded intermediate values — decide which approach the ERP uses and keep it consistent.
- Run reconciliation tests specifically on multi-currency or multi-line invoices, where compounding rounding differences are most likely to surface as a failure here even though each individual line passed its own precision check.
- Treat a failure on this rule as a signal to check the arithmetic reconciliation rules (ibr-co-13) as well — a precision failure here often means the totals relationship is also broken, not just the display format.