Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-40 | Fatal (error) | cac:AccountingCustomerParty/cac:Party |
Schematron ID: ibr-010 | Field: cac:PostalAddress (Buyer postal address group, IBG-08) |
||
Classification
Master Data — the buyer's postal address sits in the customer master record long before an invoice is ever raised. If it is missing at invoice creation, the fault is almost never a transaction error; it is a gap in the customer master that ERP master data governance should have caught first.
What the Rule Is Checking
The rule tests for the existence of a cac:PostalAddress element within the Buyer party block (cac:AccountingCustomerParty/cac:Party). It does not check the quality or completeness of the address — that is governed separately by rules such as ibr-144-ae, which require street, city, and country subdivision within the address once it exists. BR-40 only asks whether the postal address block is present at all. An invoice with a buyer name, tax number, and endpoint ID but no postal address block fails this check regardless of how complete everything else is.
Why This Rule Exists
PINT-AE inherits this obligation from the underlying Peppol BIS Billing model, which treats seller and buyer postal addresses as structurally symmetric — both parties get the same mandatory address group (IBG-05 for seller, IBG-08 for buyer). The FTA's use case is jurisdictional: without a buyer address, there is no reliable way to determine which emirate or which trade zone status applies to a domestic transaction, and no way to distinguish a domestic supply from an export at the address level. Buyer address absence also breaks any downstream reconciliation against the buyer's own trade licence records.
UAE Data Example
PASSES ✓: Buyer party block includes a populated cac:PostalAddress with street name, city, and country code, even if some optional sub-fields such as postal zone are left blank.
FAILS ✗: The Buyer party block contains cac:PartyLegalEntity, cac:PartyTaxScheme, and cbc:EndpointID, but no cac:PostalAddress element at all — a common outcome when an ERP customer master record was created through a quick-add flow that skipped the address step.
What Your ERP / IT Team Must Ensure
Make the postal address field block mandatory at customer master creation, not optional. Run a pre-go-live sweep of the customer master for any accounts missing address data, since these are usually legacy records opened before address capture was enforced. Confirm the ERP-to-PINT-AE mapping populates cac:PostalAddress from the same source field the seller address mapping uses, so the two party blocks are built the same way. Flag walk-in or one-off buyer records for manual review before they generate an invoice, since these are the accounts most likely to lack a stored address.
Related Rules
ibr-143-ae and ibr-144-ae govern the completeness of the seller and buyer address once present (street, city, country subdivision). ibr-008 imposes the equivalent mandatory-presence obligation on the seller side.