Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-89 | Fatal (error) | cac:PayeeParty |
| Schematron ID: ibr-105 | Field: ibt-060 — Payee identifier | ||
Classification
Master Data — the rule governs how a third-party payee is identified in the seller master record, and failures here almost always trace back to how the ERP stores alternate remittance parties rather than to anything the invoice clerk did.
What the Rule Is Checking
Where the invoice names a payee who is a different legal person from the seller, the payee may carry at most one identifier in cac:PayeeParty/cac:PartyIdentification/cbc:ID. Identifiers with a schemeID of SEPA are excluded from the count, because that slot carries a mandate reference rather than an identity. If the payee name matches the seller's registered legal name, the constraint does not apply, since the payee group is then redundant rather than a genuine third party.
Why This Rule Exists
A payee group exists so a buyer knows where to send money when that is somewhere other than the seller's own account — a factoring house, a group treasury entity, a collection agent. The identifier is what a paying system matches against its own vendor and bank master to decide the payment is legitimate. Two identifiers give the receiving system two candidate matches with no rule for choosing between them, and an automated payment run resolves that ambiguity silently, in whichever direction its own matching logic happens to prefer.
Restricting the field to one value forces the ambiguity to be resolved by the issuer, at the point where someone actually knows which identity is correct.
Standard / Code List
The identifier is scheme-qualified using the Peppol EAS/ICD list, the same list that governs participant identifiers elsewhere in the document. Where a scheme is declared, the base PINT rules apply that scheme's own format check — ibr-068 for a GLN, ibr-113 for a Belgian enterprise number, ibr-120 for an Australian Business Number, and so on. The SEPA exclusion in this rule's test is a European artefact carried over from the base specification; it has no practical effect on UAE-issued documents.
UAE Data Example
PASSES ✓ — a Dubai supplier invoicing a customer but assigning collection to a factoring company:
<cac:PayeeParty>
<cac:PartyIdentification>
<cbc:ID schemeID="0235">100234567800003</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName><cbc:Name>Gulf Receivables Finance LLC</cbc:Name></cac:PartyName>
</cac:PayeeParty>
FAILS ✗ — the same payee carrying both its trade licence number and a legacy internal vendor code, a pattern that appears whenever an ERP maps two source-system fields into the same UBL element:
<cac:PartyIdentification><cbc:ID schemeID="0235">100234567800003</cbc:ID></cac:PartyIdentification>
<cac:PartyIdentification><cbc:ID>VEND-4471</cbc:ID></cac:PartyIdentification>
What Your ERP / IT Team Must Ensure
- Map exactly one source field to the payee identifier and decide, as a documented rule, which identity that is — the payee's Corporate Tax TIN is the sensible default in the UAE, since it is the identifier the buyer can independently verify.
- Suppress internal vendor codes from the outbound XML entirely; they belong in your own records, not in a document the buyer's system will try to match against.
- Check whether your alternate-payee configuration writes a payee group even when the payee equals the seller. It will pass this rule, but it adds a party the buyer has to reconcile for no reason.
- Confirm the scheme code is populated whenever the identifier is a registered one, since the scheme-specific format rules only fire when the scheme is declared.
Related Rules
ibr-017 requires the payee name (ibt-059) to be present whenever the payee differs from the seller, and ibr-sr-19 restricts that name to a single occurrence under the same condition. ibr-106 applies the equivalent single-occurrence constraint to the payee legal identifier (ibt-061). ibr-192-ae requires a payment account identifier whenever the payment means is credit transfer — the field the payee group ultimately points at.
