Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-56 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-071 | Field: IBG-24 Additional Supporting Documents — IBT-018 Invoice Object Identifier vs IBT-125 Attachment | ||
Classification
Syntax & Integration — the rule polices the internal consistency of the document structure. No master data value or tax figure is being tested; what fails is a contradictory combination of elements inside a single cac:AdditionalDocumentReference block.
What the Rule Is Checking
UBL uses the same AdditionalDocumentReference structure for two different jobs. With cbc:DocumentTypeCode set to 130, the block carries the Invoice Object Identifier (IBT-018) — a reference code such as a project number, subscription reference or utility meter point that the invoice as a whole relates to. Without code 130, the block carries a supporting document (IBG-24), which may embed a file as an attachment (IBT-125). The assert checks that no block does both: wherever code 130 appears, there must be no cac:Attachment beneath it. The assert text says "should", but the flag is fatal — the invoice is rejected, not warned.
Why This Rule Exists
Code 130 converts the block from "here is a supporting document" into "here is an identifier". An attachment under an identifier block is semantically unresolvable — the receiving system cannot tell whether it holds a reference code with a stray file, or a supporting document mislabelled as a reference. In a five-corner model that ambiguity would propagate to the buyer's ASP and the buyer's own AP automation, so the ruleset stops the document at validation instead. The practical instruction hiding in the rule: identifiers and attachments belong in separate AdditionalDocumentReference blocks, and the same invoice can legitimately carry both, separately.
UAE Data Example
PASSES ✓: A facilities-management invoice carries two blocks — one with DocumentTypeCode 130 holding the contract reference "FM-2026-0442" as the Invoice Object Identifier, and a second block, without code 130, embedding the signed completion certificate as a Base64 attachment.
FAILS ✗: The supplier's mapping consolidates all references into a single block, so the contract reference gets code 130 and the completion certificate is attached beneath it. One block, both roles, fatal rejection.
What Your ERP / IT Team Must Ensure
Map the Invoice Object Identifier and supporting attachments to separate AdditionalDocumentReference instances rather than merging them for compactness. Check that middleware does not "helpfully" consolidate reference blocks during transformation — consolidation logic written for other document formats is the usual source of this failure. If your invoices carry project or contract references today in a free-text field, moving them to IBT-018 is the structurally correct home, provided the attachment stays elsewhere.
Related Rules
BR-57 (ibr-072) is this rule's twin — the same code-130 block must not carry a Document Description either. Together they keep the Invoice Object Identifier a bare identifier.