Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-64 | Fatal (error) | cac:AccountingCustomerParty/cac:Party |
| Schematron ID: ibr-080 | Field: ibt-049 — Buyer electronic address | ||
Classification
Master Data — the value comes from the customer master record, not from anything the invoice clerk enters at transaction time.
What the Rule Is Checking
Inside the buyer party block, a cbc:EndpointID element must be present. The schematron test is a bare existence check. No value, no valid invoice.
Under the UAE profile that element carries a scheme identifier of 0235, the Peppol EAS code allocated to the UAE, and the value itself is the buyer's Corporate Tax TIN. Where the buyer sits outside the UAE network — an export transaction, for instance — the profile uses the reserved placeholder value 1XXXXXXXXX, which several of the UAE-specific rules (ibr-149-ae, ibr-135-ae) then explicitly carve out of their conditional logic.
Why This Rule Exists
The buyer electronic address is the routing instruction for the whole transaction. In a five-corner model the sending access point has to resolve which receiving access point holds the buyer, and it does that by looking up the endpoint identifier in the network directory. An invoice without one cannot be delivered to anybody — a document with no address on the envelope.
Because it is delivery-critical rather than a reporting field, the failure is fatal at validation rather than something the authority queries later. That is the practical difference between this and most other master data rules: getting it wrong stops the invoice moving at all.
Standard / Code List
The scheme identifier attribute on this field draws from the Peppol EAS / ICD code list, covered in Peppol EAS and ICD Participant Identifiers. UAE-registered buyers use 0235.
UAE Data Example
PASSES ✓: <cbc:EndpointID schemeID="0235">1001234567</cbc:EndpointID> — the ten-digit Corporate Tax TIN of a UAE-registered buyer.
PASSES ✓: <cbc:EndpointID schemeID="0235">1XXXXXXXXX</cbc:EndpointID> on an export invoice where the buyer has no UAE network presence.
FAILS ✗: The buyer party block contains name, address and VAT registration but no cbc:EndpointID at all — the usual outcome when a customer master was migrated from a pre-mandate ERP where no such field existed.
What Your ERP / IT Team Must Ensure
- Add a dedicated endpoint identifier field to the customer master. Reusing the VAT registration field produces the wrong value, since the endpoint is the Corporate Tax TIN.
- Make the field mandatory at customer creation for any counterparty flagged as domestic B2B, enforced in the master data workflow rather than checked at invoice posting.
- Set the export placeholder automatically from the transaction type code rather than leaving it to manual entry.
- Run a completeness report across the existing customer base well before go-live. Collecting several thousand TINs from counterparties takes months, not weeks.
- Confirm the scheme identifier attribute is written as
0235. A populated value with a missing scheme attribute passes this rule and fails others downstream.
Related Rules
The mirror rule on the seller side is BR-65 (ibr-081). The UAE-specific conditionals ibr-149-ae, ibr-135-ae and ibr-180-ae all key off the value written here, so a wrong endpoint tends to cascade into three or four further failures rather than one.