Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-93 | Fatal (error) | cac:InvoiceLine | cac:CreditNoteLine |
| Schematron ID: ibr-109 | Field: ibt-132 — Referenced purchase order line reference | ||
Classification
Transaction Data — this is about how the billing document is built from order and delivery data, and it is the rule in this group with the most direct effect on the buyer's ability to automate.
What the Rule Is Checking
Each invoice line may carry at most one cac:OrderLineReference/cbc:LineID. The field ties a line on the invoice to the specific line on the buyer's purchase order that it bills.
Why This Rule Exists
Three-way matching is the reason. A buyer's accounts payable system matches invoice line to PO line to goods receipt, and it releases the payment without human review when the three agree. A one-to-one reference makes that match deterministic. A line referencing two PO lines forces the AP engine either to guess an allocation or to drop the invoice into an exception queue, and in practice it does the second.
Under the UAE mandate this matters more than it did under paper or PDF billing. The inbound invoice arrives as structured XML through the buyer's ASP, and the buyer's controls over what they claim as input tax now run against that structured data. Where the reference is ambiguous, the buyer cannot evidence which commitment the invoice satisfies, and the invoice sits unmatched. This is the practical shape of the Inbound Tax Assurance Gap™: the supplier's data quality determines whether the buyer's recovery position is defensible, and the supplier bears none of the consequence.
The failure pattern to look for is the consolidated line — where a seller bills 500 units against a PO that was raised in two tranches of 250, and the billing job attaches both order line references to the single invoice line rather than splitting it. Splitting is the correct answer.
UAE Data Example
PASSES ✓ — each invoice line resolving to one order line:
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="H87">250</cbc:InvoicedQuantity>
<cac:OrderLineReference><cbc:LineID>00010</cbc:LineID></cac:OrderLineReference>
</cac:InvoiceLine>FAILS ✗ — two order lines consolidated onto one invoice line:
<cac:OrderLineReference><cbc:LineID>00010</cbc:LineID></cac:OrderLineReference>
<cac:OrderLineReference><cbc:LineID>00020</cbc:LineID></cac:OrderLineReference>What Your ERP / IT Team Must Ensure
- Configure billing so that invoice line granularity follows order line granularity — if two order lines are being billed, produce two invoice lines.
- Confirm the line identifier emitted matches the numbering the buyer uses on their PO, including any leading zeros; a technically valid but unmatched reference passes validation and still lands in the buyer's exception queue.
- Where the order reference is captured as free text in the sales order, add a validation at order entry rather than leaving it to fail at transmission.
- On the inbound side, treat a missing or unmatched order line reference as a control point in your own AP process, since it determines whether the input tax claim on that invoice can be evidenced.
Related Rules
The line-level order reference sits under the document-level purchase order reference (ibt-013), and both are read together by a matching engine. ibr-107 and ibr-108 govern the delivery group that carries the third leg of the three-way match. The 17-module course covers inbound matching and the Continuous Controls Environment™ that sits around it in more depth than a rule note allows.