Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-77 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-096 | Field: ibt-016 — Despatch advice reference, at document level | ||
Classification
Syntax & Integration — a cardinality constraint on a header reference field.
What the Rule Is Checking
The assert is count(cac:DespatchDocumentReference/cbc:ID) <= 1. Evaluated from the document root, it counts identifier elements inside header-level despatch document references and permits at most one. Zero is acceptable; the rule sets a ceiling, not a requirement.
The count targets cbc:ID rather than the parent element, so two cac:DespatchDocumentReference blocks each carrying one identifier fail on the same footing as one block carrying two.
Why This Rule Exists
A header despatch reference is a statement that the whole invoice relates to one delivery. Two of them contradict that statement while still claiming header scope, and the recipient has no basis for allocating lines between them. The correct structure for a multi-delivery invoice is line-level referencing, which PINT supports through ibt-184 and which ibr-092 then requires to be used exclusively.
Where this bites in practice is consolidated billing. A monthly invoice to a UAE distributor covering fifteen deliveries has fifteen legitimate despatch notes, and a mapping written to concatenate or repeat them at header level will fail validation on every transmission. The reference structure has to reflect the shape of the transaction rather than the convenience of the extract.
Standard / Code List
No code list applies. The value is a free-text identifier drawn from the seller’s despatch documentation.
UAE Data Example
PASSES ✓
<cac:DespatchDocumentReference>
<cbc:ID>DN-2027-004417</cbc:ID>
</cac:DespatchDocumentReference>An invoice for a service supply with no despatch reference at all also passes.
FAILS ✗
<cac:DespatchDocumentReference>
<cbc:ID>DN-2027-004417</cbc:ID>
</cac:DespatchDocumentReference>
<cac:DespatchDocumentReference>
<cbc:ID>DN-2027-004418</cbc:ID>
</cac:DespatchDocumentReference>A single block containing both identifiers fails identically. So does the workaround of packing them into one value as DN-2027-004417/004418 — that passes the count but produces an identifier the buyer’s matching engine cannot resolve to either delivery, which is a worse outcome than a rejection.
What Your ERP / IT Team Must Ensure
- Route multi-delivery invoices to line-level despatch referencing and leave the header field empty.
- Check any mapping that loops over delivery documents to confirm it writes into the line structure rather than repeating a header element.
- Reject concatenated identifiers in your own pre-validation, since the schematron will not catch them.
- Confirm the same logic applies to credit notes, which share the rule context.
- Where an invoice legitimately covers one delivery, keep the header reference — it is simpler for the buyer to match than a line-level equivalent repeated across every line.
Related Rules
ibr-092 prohibits the header reference entirely once any line carries one. ibr-096 governs the header field when it is the only one in use.