Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-79 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-099 | Field: ibt-028 — Seller trading name | ||
Classification
Master Data — a cardinality constraint on the seller party record as it is projected onto the invoice.
What the Rule Is Checking
The assert is count(cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name) <= 1, evaluated from the document root. The seller trading name is optional, so zero occurrences pass. Two or more fail with a fatal error, and the document does not reach the recipient.
The trading name is a different field from the seller legal name in cac:PartyLegalEntity/cbc:RegistrationName, which ibr-006 makes mandatory and ibr-098 separately caps at one. A UAE entity registered as Gulf Facilities Management LLC and trading as GFM Services carries the first in the legal entity group and the second here.
Why This Rule Exists
The recipient's system reads the trading name as the human-facing label for the supplier — it is what appears on an approval screen, in a supplier match, and on a printed rendering. Two trading names give the recipient two candidate labels with no rule for choosing between them, and any choice it makes is arbitrary. The constraint pushes that decision back to the party that knows the answer.
The commercial consequence sits in accounts payable. A UAE group whose entities trade under multiple brands often holds several trading names against one master record in the ERP, and an integration that concatenates or emits all of them turns a supplier-matching convenience into a transmission failure. The invoice is rejected at validation rather than posted with an ambiguous name.
Standard / Code List
No code list applies. The field is free text. The identifiers that carry coded structure for the same party sit elsewhere — the endpoint identifier under scheme 0235, the legal registration identifier under ibr-100, and the tax identifier under aligned-ibrp-sr-12.
UAE Data Example
PASSES ✓ — a Sharjah supplier trading under a brand distinct from its licensed name:
<cac:PartyName>
<cbc:Name>GFM Services</cbc:Name>
</cac:PartyName>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Gulf Facilities Management LLC</cbc:RegistrationName>
</cac:PartyLegalEntity>FAILS ✗ — two brands emitted from a multi-brand master record:
<cac:PartyName>
<cbc:Name>GFM Services</cbc:Name>
</cac:PartyName>
<cac:PartyName>
<cbc:Name>GFM Technical</cbc:Name>
</cac:PartyName>Where two brands genuinely operate as separate businesses, the correct answer is usually separate seller records with separate trade licences, not two names on one document.
What Your ERP / IT Team Must Ensure
- Map exactly one ERP field to
PartyName/Name— typically the sales-organisation or business-unit trading name, decided once rather than per interface. - Check for loops in the extract that iterate a name table; a one-to-many relationship in the vendor or company-code master is the usual source of the second occurrence.
- Keep the trading name out of the legal entity group; ibr-098 caps
RegistrationNameindependently and confusing the two produces a different failure. - Where the trading name is blank in the master, omit the group entirely rather than emitting an empty element.
- Decide which brand appears on invoices as a governance question, since it is the label the customer's AP team will use to identify you.
Related Rules
ibr-098 caps the seller legal name at one occurrence. ibr-112 applies the identical limit to the buyer trading name (ibt-045). ibr-006 makes the seller legal name mandatory. ibr-co-26 requires at least one of the seller identifier, legal registration identifier or tax identifier to be present.