Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-88 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: aligned-ibrp-001-ae | Field: ibt-024 — Specification identifier (Customisation ID) | ||
Classification
Syntax & Integration — a document-header declaration that tells every downstream system, including the ASP and the FTA's platform, which rulebook to validate against.
What the Rule Is Checking
The Customisation ID must start with either urn:peppol:pint:billing-1@ae-1 or urn:peppol:pint:selfbilling-1@ae-1. This is the first thing a receiving system reads, and it determines which entire set of schematron rules — UAE jurisdiction-aligned rules included — gets applied to the rest of the document. Get this value wrong and every other rule in this series becomes irrelevant, because the document is validated against the wrong specification, or not recognised as a UAE PINT invoice at all.
Why This Rule Exists
PINT is a base international specification that individual jurisdictions extend with their own rules. The UAE's extension is one of several — Singapore, Malaysia, Japan, and others each have their own PINT variant with their own suffix. The Customisation ID is the mechanism that tells a receiving system, before it parses a single business field, which of these variants it's looking at. A UAE ASP that receives a document without the correct @ae-1 suffix cannot assume UAE rules apply; it has to reject the document rather than guess.
For self-billing arrangements specifically — where the buyer issues the invoice on the supplier's behalf, common in retail concession and marketplace structures — the identifier also has to declare that distinct billing type, since self-billing carries a different accountability chain that later validations depend on.
Standard / Code List
The two permitted prefixes correspond to the two invoicing models the UAE mandate recognises: standard billing and self-billing. This field pairs with the Business process identifier (ibt-023, checked under aligned-ibrp-002-ae), which must independently confirm the process is urn:peppol:bis:billing or urn:peppol:bis:selfbilling — the two fields have to agree with each other, not just individually pass.
UAE Data Example
PASSES ✓ — a standard UAE billing invoice:
<cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>FAILS ✗ — the generic international PINT identifier without the UAE suffix, typically left over from a proof-of-concept build against the base PINT specification before the jurisdiction-specific rules were implemented:
<cbc:CustomizationID>urn:peppol:pint:billing-1@1.0</cbc:CustomizationID>What Your ERP / IT Team Must Ensure
- Hard-code the Customisation ID at the invoice generation layer for UAE-issued documents — this is not a field that should ever be user-editable or dynamically constructed.
- Confirm the value used in testing and staging environments matches the production UAE identifier exactly; a common failure mode is testing against a generic or sandbox namespace and never updating it for go-live.
- For any self-billing arrangement, verify both the Customisation ID and the Business process ID (ibt-023) are set to the self-billing variant together — setting one without the other fails aligned-ibrp-002-ae even where this rule passes.
- Treat a validation failure on this field as an integration-configuration issue to escalate immediately, not a data-quality issue to queue for later — it blocks every invoice from that source until fixed.
Related Rules
aligned-ibrp-002-ae requires the Business process identifier to match the billing or self-billing pattern declared here. ibr-001 requires the Specification identifier field to be non-empty at the base PINT layer, before the UAE-specific pattern check applies. ibr-193-ae requires the invoice's unique identifier (UUID), another header-level field checked at the same validation pass.