Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-115 | Schematron ID: ibr-002-ae | Fatal (error) | cbc:CalculationRate |
Assert text: [ibr-002-ae]-Currency exchange rate [BTAE-04] should contain the values till maximum of 6 decimal places.
Test: not(matches(., "^\d+(\.\d{7})?$"))
Classification
Transaction Data / Format & Precision.
What the Rule Is Checking
This rule constrains the shape of the currency exchange rate carried in BTAE-04, held on the cbc:CalculationRate element. The assert fires when the value has more than six digits after the decimal point — the test pattern permits a maximum of seven characters after the point only because the regex counts the decimal separator loosely, but the intent stated in the assert text is a six-decimal-place ceiling. Anything beyond that precision fails.
Why This Rule Exists
An invoice raised in a foreign currency has to restate its amounts in AED at a fixed rate, and that rate becomes part of the legal record the authority reconciles against. A rate carried with excessive or inconsistent decimal precision creates rounding drift between the foreign-currency total and the AED total that a downstream system recalculates independently — small at the rate level, compounding once multiplied across large invoice values. Capping precision keeps the stated rate and the derived AED amounts reproducible by any party re-running the calculation.
UAE Data Example
PASSES ✓
<cbc:CalculationRate>3.672500</cbc:CalculationRate>FAILS ✗
<cbc:CalculationRate>3.67250012</cbc:CalculationRate>The failing example carries eight decimal places against a six-decimal-place ceiling. This is a formatting defect, not a business error — the underlying rate may be correct, but the field fails validation because the ERP's currency conversion module is returning full floating-point precision instead of rounding to the standard the schema expects.
What Your ERP / IT Team Must Ensure
- Round exchange rates to six decimal places at the point the ERP writes the invoice XML, not earlier in the calculation chain where more precision may still be useful internally.
- Check the treasury or FX rate-feed integration — many market data providers return eight or more decimal places by default, and that raw value should never be passed through unmodified to the e-invoicing layer.
- Confirm the rounding rule is applied consistently between the exchange rate field and the AED-converted line and total amounts derived from it, so the two don't drift out of arithmetic agreement.
- Test with rates from currencies that commonly carry long natural precision (JPY-to-AED, for instance, where the rate can be a very small or very large number) rather than only round, easy test values.
Related Rules
No directly related published rule posts yet in this series.