Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-65 | Fatal (error) | cac:AccountingSupplierParty/cac:Party |
| Schematron ID: ibr-081 | Field: ibt-034 — Seller electronic address | ||
Classification
Master Data — a single company-level constant, configured once in the ERP rather than derived per transaction.
What the Rule Is Checking
The seller party block must contain a cbc:EndpointID. Like its buyer-side counterpart the test is pure existence, and like its counterpart it carries scheme identifier 0235 under the UAE profile with the seller's Corporate Tax TIN as the value.
This is the field that identifies who sent the document to every party in the chain: the sending access point, the receiving access point, the buyer's system, and the authority.
Why This Rule Exists
The seller endpoint is what makes the invoice attributable. A buyer receiving a document over the network needs a machine-readable answer to the question of which registered entity sent it, and that answer has to match the identifier the authority holds. Otherwise the two sides of the same transaction reconcile to different taxpayers.
A second reason matters more in multi-entity groups. Where one shared service centre issues invoices on behalf of several legal entities, the endpoint is what distinguishes them. Getting the mapping wrong sends a subsidiary's output tax into the parent's reported position, and because the document validates cleanly the error surfaces only at reconciliation.
Standard / Code List
Scheme identifiers are drawn from the Peppol EAS / ICD list — see Peppol EAS and ICD Participant Identifiers. The UAE allocation is 0235.
UAE Data Example
PASSES ✓: <cbc:EndpointID schemeID="0235">1009876543</cbc:EndpointID> in the supplier party block, matching the entity named as seller elsewhere in the document.
FAILS ✗: The seller endpoint is omitted because the ERP treats the issuing company code as implicit and writes only the company name and address.
Validates but is wrong: A group with five UAE entities configures the parent's TIN as a hard-coded constant in the XML mapping. Every invoice passes ibr-081 and every subsidiary's sales are attributed to the parent.
What Your ERP / IT Team Must Ensure
- Map the endpoint identifier from the issuing company code, never from a hard-coded constant in the output template.
- Where an ASP or shared service centre transmits on behalf of multiple entities, confirm the endpoint is resolved per document rather than per connection.
- Check that the seller endpoint agrees with the seller legal registration identifier written under ibr-150-ae, which the UAE profile requires whenever the scheme is
0235. - Include the endpoint in the pre-transmission reconciliation between the ERP company code and the entity registered with the accredited service provider.
Related Rules
The buyer-side mirror is BR-64 (ibr-080). Rules ibr-150-ae, ibr-173-ae and ibr-181-ae add UAE-specific requirements on the seller legal registration identifier that apply only when this endpoint carries scheme 0235.
