Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-72 | Fatal (error) | cac:InvoiceLine | cac:CreditNoteLine |
| Schematron ID: ibr-089 | Field: ibt-128 — Invoice line object identifier, within ibg-25 | ||
Classification
Syntax & Integration — the rule constrains cardinality rather than content, and the breach originates in how the sending system composes a line rather than in any individual field value.
What the Rule Is Checking
Within a single invoice line, at most one cac:DocumentReference carrying cbc:DocumentTypeCode of 130 may appear. Code 130 marks the reference as an invoiced object identifier — the identity of the physical or contractual thing the line relates to. Zero occurrences pass. Two or more fail.
The invoiced object carries a meter point, a vehicle, a subscription or telephone number, an asset tag or an equipment serial. It answers which specific instance of a thing the charge attaches to.
Why This Rule Exists
The value of an object identifier depends on it being unambiguous. A buyer's accounts payable engine reads the object reference to route the cost to the right asset, cost centre or contract. An authority reconciling a claimed input deduction against a registered asset needs one identifier to reconcile against. A line carrying three meter numbers tells the recipient that the charge relates to some combination of three things without saying how it divides between them.
For utilities, fleet operators, equipment lessors and telecoms billers in the UAE this is the rule that forces a change in invoice shape. Legacy billing frequently aggregates: one line for the month's consumption across a site with several meters, one line for a fleet's fuel across several vehicles. That aggregation is efficient for the biller and opaque to everyone downstream, and the profile resolves the tension by requiring the split.
The consequence is a line count increase, sometimes a large one. An invoice that carried 40 aggregated lines may carry 400 once each object is separated. That has implications for document size, for transmission throughput through the Accredited Service Provider, and for the buyer's ability to process the document without manual intervention. Those are capacity decisions to be taken in design, not discovered in a volume test three weeks before go-live.
Standard / Code List
Two coded values sit in this structure and they draw on different lists. The document type code 130 qualifies the reference as an invoiced object identifier, separating it from other references carried in the same element, and is tested as a literal. The optional schemeID attribute on the identifier states what kind of object identifier it is, and that attribute alone is coded from UN/CEFACT 1153, the invoiced object identifier scheme list, under rule ibr-cl-07.
UAE Data Example
PASSES ✓: A utilities line for one meter, with a single cac:DocumentReference where cbc:DocumentTypeCode is 130 and cbc:ID carries the meter number.
PASSES ✓: A standard goods line with no invoiced object reference at all.
FAILS ✗: A single consolidated line for a commercial site listing three meter numbers as three references with document type code 130.
FAILS ✗: A fleet fuel line naming two vehicle registrations, produced by a billing routine that groups by cost centre rather than by asset.
What Your ERP / IT Team Must Ensure
- Set the billing granularity to one object per line in the source system, rather than splitting lines in the mapping layer where the split will not be reflected in the accounting document.
- Size the change. Count how many current invoice lines carry more than one object identifier and model the resulting line volume before committing to an architecture.
- Confirm the Accredited Service Provider's document size and line count limits against that modelled volume.
- Check the credit-note path, since the rule context covers
cac:CreditNoteLineon the same terms and reversal routines often rebuild lines differently from the original. - Keep other document references — despatch advice, receiving advice, contract — out of the type code 130 structure, since a mistyped code turns an unrelated reference into a second invoiced object.
Related Rules
The same rule context carries the maximum-once constraints on the referenced purchase order line identifier and on the invoice line period, and a line rebuilt to satisfy this rule commonly trips those at the same time. The document-level single-reference rules cover the equivalent constraint on project and contract references.