Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-81 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-101 | Field: ibt-033 — Seller additional legal information | ||
Classification
Master Data — a cardinality constraint on a free-text legal disclosure attached to the seller.
What the Rule Is Checking
The assert is count(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyLegalForm) <= 1. The field is optional; one occurrence or none passes, two fail fatally.
Despite the UBL element name, this is not a coded legal form. It is free text intended for the statutory statement some jurisdictions require on invoices — share capital, court of registration, or a company's status in liquidation. In the UAE reference examples it carries a short descriptor such as Merchant.
Why This Rule Exists
A statutory disclosure carries weight because it is the seller's own single statement about its legal standing. Splitting that statement across two elements leaves the recipient to decide whether they are two separate disclosures or one disclosure broken by a line feed, and the two readings are not equivalent when the text is later relied on. Where a seller has more to say than fits in one field, the answer is one longer field, not two fields.
The practical risk here is different from the other cardinality rules in this group. Free-text fields attract content that has nowhere else to go — a payment instruction, a bank detail, a standing contractual term. An ERP team that treats ibt-033 as a general remarks field will eventually emit two of them, and the rejection arrives without warning because the field was optional and nobody owned it.
Standard / Code List
No code list applies. The field is unconstrained text within the PINT-AE model, which is exactly why it needs a governance decision rather than a technical one. Structured seller attributes belong in their own fields: the legal name in RegistrationName, the registration identifier under ibr-100, and the tax identifier under aligned-ibrp-sr-12.
UAE Data Example
PASSES ✓ — a single legal descriptor alongside the registration data:
<cac:PartyLegalEntity>
<cbc:RegistrationName>Gulf Facilities Management LLC</cbc:RegistrationName>
<cbc:CompanyID schemeAgencyID="TL">112345678900003</cbc:CompanyID>
<cbc:CompanyLegalForm>Merchant</cbc:CompanyLegalForm>
</cac:PartyLegalEntity>FAILS ✗ — a legal form and a free-text remark emitted as two elements:
<cbc:CompanyLegalForm>Merchant</cbc:CompanyLegalForm>
<cbc:CompanyLegalForm>Registered with Dubai Economy and Tourism</cbc:CompanyLegalForm>Combining both into one string passes validation. Whether it should be there at all is the better question — the registration authority already appears in BTAE-12 under ibr-172-ae, and repeating it here duplicates data the recipient will read twice.
What Your ERP / IT Team Must Ensure
- Assign a single owner to this field — usually legal or company secretarial, not the integration team — and agree its exact content before go-live.
- Block it from being used as an overflow area for payment terms or bank details, which have dedicated fields elsewhere in the model.
- If the extract reads from a multi-row text table, concatenate to one string rather than emitting one element per row.
- Omit the element rather than sending an empty one where the master record has no value.
- Review the content annually alongside trade licence renewal, since a stale legal descriptor is worse than none.
Related Rules
ibr-098 and ibr-099 cap the seller legal and trading names. ibr-100 caps the seller legal registration identifier. ibr-172-ae requires the trade licence issuing authority name, which is where registration authority data belongs.