Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| BR-17 | Fatal (error) | ubl:Invoice/cac:PayeeParty |
| Series reference: BR-17 | Schematron ID: ibr-017 | ||
Classification
Master Data — BR-17 governs the payee party block (IBG-10). A payee is the entity that receives payment and is different from the seller. This is common in factoring arrangements, assignment of receivables, or group treasury structures where one entity invoices but a different entity collects. BR-17 is only evaluated when the cac:PayeeParty block is present on the invoice.
What the Rule Is Checking
BR-17 has two conditions that must both be satisfied. First, a cac:PartyName/cbc:Name element must exist within cac:PayeeParty. Second, the payee name must differ from the seller name (cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name). If the payee name is present but identical to the seller name, the rule also fires — because a payee that is the same entity as the seller is not a payee in the legal sense and the block should be omitted entirely.
The rule is contextual: if no cac:PayeeParty block is present on the invoice at all (the payee is the seller, which is the default), BR-17 does not fire. It only activates when a system has explicitly included a payee block.
Why This Rule Exists
In UAE commercial law, invoices issued under a factoring or receivables assignment arrangement must clearly identify the entity to whom payment must be directed. Without a named payee that differs from the seller, the buyer cannot determine whether to remit payment to the original seller or to the acquiring financier. The FTA requires this distinction to be explicit so that the payment flow can be traced during an audit.
The rule also prevents a common integration error where a system includes an empty or default payee block copied from the seller record, creating a structurally present but meaningless element. BR-17 forces a positive assertion that the payee is a distinct, named entity.
Standard / Code List
No code list applies to the payee name itself. If the payee is identified by a business identifier scheme (e.g., UAE TRN or TIN), the identifier must be placed in cac:PayeeParty/cac:PartyIdentification with a valid scheme code. See Peppol EAS and ICD participant identifier schemes.
UAE Data Example
PASSES ✓ — payee is a named third party (e.g., factoring bank)
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName><cbc:Name>Acme Trading LLC</cbc:Name></cac:PartyName>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:PayeeParty>
<cac:PartyName><cbc:Name>Emirates Factoring Corp</cbc:Name></cac:PartyName>
</cac:PayeeParty>
FAILS ✗ — PayeeParty present but name missing
<cac:PayeeParty>
<!-- cac:PartyName absent — BR-17 fires as fatal -->
<cac:PartyIdentification><cbc:ID>100123456700003</cbc:ID></cac:PartyIdentification>
</cac:PayeeParty>
FAILS ✗ — PayeeParty name same as seller
<cac:PayeeParty>
<cac:PartyName><cbc:Name>Acme Trading LLC</cbc:Name></cac:PartyName>
<!-- Name matches seller — BR-17 fires because payee = seller -->
</cac:PayeeParty>
What Your ERP / IT Team Must Ensure
- Only include a
cac:PayeePartyblock when payment genuinely flows to a third party — omit it entirely when the seller and payee are the same entity. - If your organisation uses factoring or invoice discounting, configure the UBL mapper to populate the financier's legal name in
cac:PayeeParty/cac:PartyName/cbc:Name. - Ensure the payee name in your master data matches the legal name on the factoring agreement — discrepancies can trigger FTA audit queries even if the schematron passes.
- If a
cac:PayeePartyblock was included by default in your UBL template (copied from the seller party block), remove it or replace it with a genuinely distinct payee name before submission. - For UAE Tax Group invoices, the payee must be the Tax Group representative member if payment is pooled centrally — confirm this mapping with your tax adviser.
Related Rules
BR-18 (seller tax representative name mandatory when present), BR-19 (seller tax representative postal address mandatory when present). See also MD 243 definitions and 51 mandatory fields in PINT-AE.
