Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-82 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-102 | Field: ibt-044 — Buyer name | ||
Classification
Master Data — a cardinality constraint on the name that identifies the recipient of the supply.
What the Rule Is Checking
The assert is count(cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) <= 1. Read alongside ibr-007, which makes the buyer name mandatory, the effective requirement is exactly one occurrence. Zero fails ibr-007; two fail this rule.
The buyer trading name is a separate field, ibt-045, capped independently by ibr-112. A customer registered as Emirates Retail Holdings LLC and known commercially as ERH Stores carries the first here and the second in cac:PartyName.
Why This Rule Exists
The buyer name is the invoice's statement of who received the supply, and under the five-corner model that statement travels to the FTA in the same structured form the recipient gets. Where two names appear, the mirrored record the authority holds contains two candidate recipients for one transaction, and reconciling that against the buyer's own reported input tax becomes guesswork.
The failure mode this rule catches is specific to group structures. A UAE seller invoicing into a large group often holds both the ordering entity and the paying entity against one customer record, and an extract that emits both produces two RegistrationName elements. Where those are genuinely different legal persons, the model has fields for the distinction — the payee and the delivery party sit separately — and collapsing them into the buyer identity misstates who bore the tax.
Standard / Code List
No code list applies to the name itself. The coded buyer attributes sit in adjacent fields: the buyer identifier (ibt-046) capped by ibr-sr-16, the legal registration identifier (ibt-047) capped by ibr-103, and the buyer VAT identifier (ibt-048) capped by ibr-104 and made mandatory under reverse charge by ibr-103-ae.
UAE Data Example
PASSES ✓ — an Abu Dhabi customer identified by registered name and trade licence:
<cac:PartyLegalEntity>
<cbc:RegistrationName>Emirates Retail Holdings LLC</cbc:RegistrationName>
<cbc:CompanyID schemeAgencyID="TL">112345679000001</cbc:CompanyID>
</cac:PartyLegalEntity>FAILS ✗ — ordering entity and paying entity both written to the buyer name:
<cbc:RegistrationName>Emirates Retail Holdings LLC</cbc:RegistrationName>
<cbc:RegistrationName>ERH Trading FZE</cbc:RegistrationName>If the supply was made to the holding company and settled by the free zone entity, the buyer name states the first and the payment arrangement is carried elsewhere. Getting this wrong is a VAT recovery problem for the customer, not only a validation one.
What Your ERP / IT Team Must Ensure
- Derive the buyer name from the sold-to party's legal name field, chosen deliberately rather than from whichever partner function the extract reaches first.
- Confirm the customer master holds the name exactly as it appears on the customer's trade licence, since the FTA-side match is against registration data.
- Keep ship-to and payer relationships in their own fields; a group hierarchy in the master is the usual cause of a duplicate occurrence.
- Route the trading name to
PartyName, where ibr-112 applies its own single-occurrence limit. - Reconcile buyer name against buyer legal registration identifier at extract time, so a name change without an identifier change is caught internally.
Related Rules
ibr-007 makes the buyer name mandatory. ibr-098 applies the same cap to the seller name. ibr-112 caps the buyer trading name. ibr-103 caps the buyer legal registration identifier. ibr-sr-16 caps the buyer identifier.