Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-90 | Fatal (error) | cac:PayeeParty |
| Schematron ID: ibr-106 | Field: ibt-061 — Payee legal registration identifier | ||
Classification
Master Data — this is a registry-identity field, and getting it wrong is a vendor-master problem that surfaces at transmission rather than a transaction-entry problem.
What the Rule Is Checking
Where the payee is a different party from the seller, cac:PayeeParty/cac:PartyLegalEntity/cbc:CompanyID may appear at most once. The exemption is the same as under ibr-105: if the payee name equals the seller's registered legal name, the check is skipped. The distinction between this field and the payee identifier under ibr-105 matters. ibt-060 is a general-purpose identifier for the party; ibt-061 is specifically the registration number issued by an official registry.
Why This Rule Exists
A legal registration identifier is the field an auditor uses to establish who, in law, received the money. It has to point at one registered entity. Groups with several registrations for the same trading name — a mainland licence and a free zone licence, or a UAE registration alongside a foreign parent's company number — will populate whichever their master data holds, and where the master record holds two, an unconstrained mapping emits both.
For the buyer, the consequence is a payment made to an entity that the invoice never unambiguously named. For the seller, it is a defensibility problem: the audit trail supporting the payment leg of the transaction does not resolve to a single counterparty.
Standard / Code List
The registration identifier is scheme-qualified from the Peppol EAS/ICD list. Where a national scheme is declared, the base PINT rules validate the number's format against that country's algorithm — ibr-115 for an Italian Codice Fiscale, ibr-127 for a Swedish organisation number, ibr-069 for a Norwegian one. For UAE-registered payees the practical value is the Corporate Tax registration number, consistent with how the mandate identifies participants generally.
UAE Data Example
PASSES ✓ — a payee legal entity carrying a single registration:
<cac:PayeeParty>
<cac:PartyName><cbc:Name>Emirates Group Treasury FZE</cbc:Name></cac:PartyName>
<cac:PartyLegalEntity>
<cbc:CompanyID schemeID="0235">100567891200003</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:PayeeParty>FAILS ✗ — both the free zone licence number and the Corporate Tax registration emitted together, because the vendor master holds both and neither was marked as the reporting identity:
<cac:PartyLegalEntity>
<cbc:CompanyID>FZE-DMCC-88214</cbc:CompanyID>
<cbc:CompanyID schemeID="0235">100567891200003</cbc:CompanyID>
</cac:PartyLegalEntity>What Your ERP / IT Team Must Ensure
- Designate one registration number per payee entity in the vendor master as the e-invoicing identity, and flag it explicitly rather than relying on which record happens to be first.
- Keep trade licence numbers out of this field unless the licence is the registration you have designated; the field is for registry identity, not for every reference number attached to the party.
- Review payees that trade under one name across multiple licences — these are the records that hold two candidate values and will fail intermittently depending on which entity the transaction cites.
- Where the payee is a foreign factoring or treasury entity, confirm the scheme code matches the registry the number actually comes from, because the format rule that fires is chosen by the scheme you declare.
Related Rules
ibr-105 applies the same single-occurrence constraint to the payee identifier (ibt-060). ibr-017 makes the payee name mandatory whenever the payee differs from the seller. ibr-sr-59 limits the payee postal address line (ibt-174) to one occurrence, part of the same family of cardinality controls over the payee group.