Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-87 | Fatal (error) | cac:PostalAddress (Seller, Buyer, and Delivery addresses) |
| Schematron ID: ibr-128-ae | Fields: ibt-039, ibt-054, ibt-068, ibt-079 — Country subdivision | ||
Classification
Master Data — a code list constraint on address data captured once, at onboarding, and reused across every subsequent invoice.
What the Rule Is Checking
Wherever the country code on an address is AE, the country subdivision field must be one of exactly seven values: AUH, DXB, SHJ, UAQ, FUJ, AJM, RAK — the seven emirates. Any other value, including a free-text emirate name spelled out in full ("Dubai," "Abu Dhabi"), a city name entered into the subdivision field by mistake, or a blank value, fails.
Why This Rule Exists
The rule closes a gap that's specific to how UAE businesses have historically captured address data. Most invoicing and CRM systems built for the UAE market never needed a controlled emirate code — free text was good enough for a printed invoice a human would read. PINT-AE removes that tolerance because the country subdivision field feeds structured reporting and location-based validation downstream, and a structured field with inconsistent values (some records say "Dubai," others say "DXB," others say "Dubai, UAE") can't be reconciled programmatically.
This becomes a real project risk specifically because it's invisible in normal business operations. An invoice with "Dubai" typed into the subdivision field looks completely correct to a human reader and has looked correct for years. The failure only appears the first time that customer or supplier record flows through PINT-AE validation.
Standard / Code List
The seven codes: AUH (Abu Dhabi), DXB (Dubai), SHJ (Sharjah), UAQ (Umm Al Quwain), FUJ (Fujairah), AJM (Ajman), RAK (Ras Al Khaimah). The rule applies identically across Seller postal address (ibt-039), Buyer postal address (ibt-054), Delivery address (ibt-079), and the equivalent tax representative address field (ibt-068).
UAE Data Example
PASSES ✓ — correctly coded Dubai address:
<cac:PostalAddress>
<cbc:CityName>Dubai</cbc:CityName>
<cbc:CountrySubentity>DXB</cbc:CountrySubentity>
<cac:Country><cbc:IdentificationCode>AE</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>FAILS ✗ — the emirate name entered as free text, the most common failure pattern seen in migrated master data:
<cbc:CountrySubentity>Dubai</cbc:CountrySubentity>What Your ERP / IT Team Must Ensure
- Run a one-time data cleanse converting every UAE customer and supplier address's subdivision field to the seven-code list before go-live — this is almost always a bulk update, not a one-by-one fix.
- Replace any free-text emirate field in the ERP's address entry screen with a constrained dropdown limited to the seven codes, so the problem can't recur through new master data entry.
- Check third-party integrations (e-commerce platforms, POS systems, CRM) that feed customer addresses into the ERP, since these often capture emirate as unconstrained free text and are easy to miss in an ERP-focused cleanse.
- Extend the check to delivery addresses separately from billing addresses — they're stored in different tables in most ERPs and a cleanse of one won't touch the other.
Related Rules
ibr-011 requires the buyer country code itself. ibr-142-ae and ibr-152-ae require delivery address detail (street, city, subdivision) for e-commerce and export transaction types respectively. ibr-143-ae and ibr-144-ae require the same three-field completeness for seller and buyer addresses generally.