Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-91 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-107 | Field: ibg-13 — Delivery information | ||
Classification
Transaction Data — the failure is created by how the invoice is assembled from delivery documents, so the fix sits in the billing process rather than in any master record.
What the Rule Is Checking
The cac:Delivery group may appear at most once in the document. Delivery information carries the deliver-to party, the deliver-to address, the actual delivery date (ibt-072) and the despatch advice reference. One invoice describes one delivery event to one location.
Why This Rule Exists
In the UAE this constraint carries direct compliance weight rather than being a modelling nicety. Two of the jurisdiction-aligned rules make delivery address fields mandatory based on the invoice transaction type code: ibr-142-ae requires deliver-to address line 1 (ibt-075), city (ibt-077) and country subdivision (ibt-079) where the transaction is an e-commerce supply, and ibr-152-ae requires the same fields for exports. Both rules interrogate a single delivery group. Where an invoice carried two, there would be no defined answer to the question of which address the place-of-supply determination rests on.
The practical consequence is a billing-design decision. A consolidated invoice covering shipments to three emirates cannot represent those three destinations in the delivery group. Either the invoice is split by destination, or the destination detail moves to the line level and the header delivery group is left to describe the transaction as a whole. For an e-commerce or export supply the first option is usually the only defensible one, because the mandatory address fields are header fields.
UAE Data Example
PASSES ✓ — one delivery, complete enough to satisfy the e-commerce address requirement:
<cac:Delivery>
<cbc:ActualDeliveryDate>2027-03-14</cbc:ActualDeliveryDate>
<cac:DeliveryLocation><cac:Address>
<cbc:StreetName>Al Wasl Road, Villa 42</cbc:StreetName>
<cbc:CityName>Dubai</cbc:CityName>
<cbc:CountrySubentity>Dubai</cbc:CountrySubentity>
<cac:Country><cbc:IdentificationCode>AE</cbc:IdentificationCode></cac:Country>
</cac:Address></cac:DeliveryLocation>
</cac:Delivery>FAILS ✗ — a consolidated monthly invoice where the billing job emitted one delivery group per despatch note:
<cac:Delivery>...Dubai...</cac:Delivery>
<cac:Delivery>...Abu Dhabi...</cac:Delivery>What Your ERP / IT Team Must Ensure
- Set the invoice split criteria so that ship-to location is a splitting key for e-commerce and export transactions, before the XML is built rather than after validation rejects it.
- Where consolidation across destinations is a commercial requirement, confirm with tax that the transaction type code applied to the consolidated document does not trigger ibr-142-ae or ibr-152-ae.
- Check that the delivery group is populated from one despatch document, not looped over a collection.
- Treat the actual delivery date as a determination input, not a descriptive field — it drives the tax point, and a single delivery group means a single date.
Related Rules
ibr-108 limits the deliver-to party name (ibt-070) within that single delivery group to one occurrence. ibr-057 requires every deliver-to address to carry a country code (ibt-080). ibr-142-ae and ibr-152-ae make the street, city and country subdivision mandatory for e-commerce supplies and exports respectively. ibr-sr-56 caps the delivery postal address line (ibt-165) at one occurrence.