Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-86 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-140-ae | Field: ibt-006 — Tax accounting (VAT) currency code | ||
Classification
Contextual — a value constraint that only applies when the optional field is populated at all.
What the Rule Is Checking
The assert is not(cbc:TaxCurrencyCode) or cbc:TaxCurrencyCode = "AED": the field may be omitted altogether, and where it is present the only value that clears validation is AED.
Why This Rule Exists
UBL's tax currency code field exists to let a document state VAT amounts in a currency different from the invoice's main document currency, which some jurisdictions use to accept reporting in a currency other than the local one. The FTA expresses its VAT position in AED in every case, so AED is the only value this field can meaningfully carry on a UAE PINT-AE invoice, and any other value would declare a second reporting currency the FTA has no mechanism to interpret.
The rule matters operationally because it's one of the few fields in the schema where an ERP's global tax configuration can silently override country-specific requirements. A multinational running one tax engine across several markets may have a default tax currency setting inherited from a different jurisdiction's configuration, and that default can leak into the UAE output unless someone deliberately overrides it.
Standard / Code List
The currency value itself follows ISO 4217. Omitting the field is only safe where the document currency is AED: Guidelines V1.1 makes the tax accounting currency field mandatory once the document currency is something other than AED, so the schematron's tolerance for an absent field is narrower in practice than the assert alone suggests. ibr-175-ae builds directly on this field: where the invoice currency differs from AED and the tax accounting currency is set to AED, the invoice total VAT amount in the tax accounting currency (ibt-111) and a supporting AED-equivalent total (BTAE-20) both become mandatory.
UAE Data Example
PASSES ✓ — field omitted entirely on an AED invoice, which is the most common valid case:
<cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>
<!-- cbc:TaxCurrencyCode not present -->PASSES ✓ — field explicitly set to AED on a foreign-currency invoice:
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>AED</cbc:TaxCurrencyCode>FAILS ✗ — an inherited value from a global tax configuration:
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>GBP</cbc:TaxCurrencyCode>What Your ERP / IT Team Must Ensure
- Confirm the tax currency field on UAE-registered company codes is either left blank or hard-coded to AED, and that the value comes from the UAE configuration rather than a group-level default.
- If the ERP's tax engine is shared across multiple countries, isolate the UAE output mapping so a configuration change made for another jurisdiction cannot alter this field.
- Where the tax currency is set to AED and the document currency is not, confirm the downstream fields ibr-175-ae requires (the AED VAT total and the AED-equivalent gross total) are also populated, since setting the currency code alone isn't sufficient.
Related Rules
ibr-159-ae requires an exchange rate whenever the document currency isn't AED. ibr-175-ae requires AED-equivalent totals once the tax accounting currency is AED and the document currency differs. ibr-153-ae governs the source/target currency mapping on the pricing exchange rate block under the same condition.