Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-57 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-072 | Field: IBG-24 Additional Supporting Documents — IBT-018 Invoice Object Identifier vs IBT-123 Document Description | ||
Classification
Syntax & Integration — like its twin BR-56 (ibr-071), this rule tests the internal consistency of the document structure rather than any business value on the invoice.
What the Rule Is Checking
Wherever an AdditionalDocumentReference block carries cbc:DocumentTypeCode 130 — marking it as the Invoice Object Identifier (IBT-018) — the assert requires that no cbc:DocumentDescription (IBT-123) appears in the same block. BR-56 bans attachments under code 130; this rule bans descriptive text. Between the two, a code-130 block is reduced to exactly what the identifier model intends: an ID value, its scheme, and nothing else.
Why This Rule Exists
The Document Description field exists to tell a human what a supporting document is — "signed delivery note", "insurance certificate". An identifier needs no such caption, and text placed there tempts integrators to smuggle in data that belongs in structured fields: a second reference, a cost centre, an approval note. Receiving systems in the five-corner model process IBT-018 mechanically, matching it against purchase orders, contracts or subscription records, and free text alongside the identifier either gets ignored or, worse, gets parsed by fragile downstream logic. The ruleset removes the option.
UAE Data Example
PASSES ✓: <cac:AdditionalDocumentReference><cbc:ID>SUB-88213</cbc:ID><cbc:DocumentTypeCode>130</cbc:DocumentTypeCode></cac:AdditionalDocumentReference> — a telecoms subscription reference travelling as a clean Invoice Object Identifier.
FAILS ✗: The same block with <cbc:DocumentDescription>Corporate mobile fleet — Q3 renewal</cbc:DocumentDescription> added so the buyer's AP clerk can see what the reference means. Helpful intent, fatal rejection.
What Your ERP / IT Team Must Ensure
Emit the Invoice Object Identifier as ID and type code only — any explanatory text belongs in the invoice note field (IBT-022) or at line level, where descriptions are structurally welcome. Review mapping templates inherited from other e-invoicing regimes, since several national formats do permit descriptions on reference blocks and a reused template will carry the habit across. Where business users ask for context alongside the reference, the answer is a second, non-130 document reference block, which BR-56 and this rule leave untouched.
Related Rules
BR-56 (ibr-071) bans attachments under the same code-130 block. The two rules enforce the same principle from opposite sides and are best implemented as a single mapping constraint.