Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| BR-07 | Fatal (error) | ubl:Invoice |
| Series reference: BR-07 | Schematron ID: Spec req. | ||
Classification
Master Data — BR-07 enforces the presence of at least one buyer-side reference that links the invoice to a procurement context or buyer account, enabling the receiving party to match the document against an order or contract.
What the Rule Is Checking
BR-07 requires that an invoice contains at least one of the following: a Buyer reference (cbc:BuyerReference, BT-10) or a Purchase order reference (cac:OrderReference/cbc:ID, BT-13). The rule fails fatally if neither is present.
In the PINT-AE context, BT-10 is commonly used to carry the buyer's internal cost centre code, project code, or departmental reference. BT-13 carries the buyer's purchase order number. Either satisfies the rule — both may be present simultaneously.
Why This Rule Exists
In B2B transactions, an invoice that arrives without any buyer-side reference creates a matching problem for the buyer's accounts payable team. Without BT-10 or BT-13, automated three-way matching (invoice vs. PO vs. goods receipt) fails, and the invoice typically enters a manual review queue. At scale, this becomes a material operational cost.
In the UAE context, the FTA's objective is not merely to collect tax data but to enable continuous transaction controls. Buyer references are a prerequisite for automated AP-side validation and for the Inbound Tax Assurance Gap™ closure that e-invoicing mandates are designed to achieve. Without them, the 5-Corner model delivers the document but cannot anchor it to the buyer's procurement record.
Standard / Code List
BT-10 is a free-text string — no code list applies. BT-13 must match the buyer's actual purchase order number. Some large UAE buyers (government entities, major corporates) specify BT-10 format requirements contractually; these are commercial obligations layered on top of the BR-07 technical requirement.
UAE Data Example
PASSES ✓ — Buyer reference only:
<cbc:BuyerReference>COST-CTR-4521</cbc:BuyerReference>
PASSES ✓ — Purchase order reference only:
<cac:OrderReference>
<cbc:ID>PO-2025-00817</cbc:ID>
</cac:OrderReference>
PASSES ✓ — Both present:
<cbc:BuyerReference>PROJ-AUH-112</cbc:BuyerReference>
<cac:OrderReference>
<cbc:ID>PO-2025-00817</cbc:ID>
</cac:OrderReference>
FAILS ✗ — Neither element present:
<!-- No cbc:BuyerReference and no cac:OrderReference/cbc:ID -->What Your ERP / IT Team Must Ensure
- Your invoice creation workflow must make BT-10 or BT-13 a mandatory input field. A UX pattern that allows invoices to be submitted without either will produce BR-07 failures at the ASP validation stage.
- For recurring invoices (monthly service fees, retainers), where no PO exists, establish a standing BT-10 convention with each buyer — for example, their supplier code in your system or their cost centre reference from the contract.
- For ERP systems generating invoices automatically from sales orders, map the buyer's PO reference from the sales order header into BT-13. Do not leave BT-13 blank if the originating transaction was PO-driven.
- For B2G (business-to-government) invoices in the UAE, government buyers often mandate a specific contract number or project code in BT-10. Confirm the required format with each government buyer before go-live.
- Test the null case: run a schematron validator against an invoice with both fields absent to confirm BR-07 fires as expected before connecting to your ASP.
Related Rules
BR-01 (Specification identifier), BR-08 (Seller name mandatory), UAE E-Invoicing Master Data Readiness