Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-62 | Fatal (error) | Invoice | CreditNote |
| Schematron ID: ibr-078 | Field: Invoiced object (ibt-018), cac:AdditionalDocumentReference[cbc:DocumentTypeCode='130'] | ||
Classification
Transaction Data — a cardinality constraint on a document-level reference tied to the specific commercial transaction being invoiced.
What the Rule Is Checking
The invoiced object reference is carried as an AdditionalDocumentReference with document type code 130, and the rule counts how many such references exist at document level. There may be zero, but never more than one. Any additional document references for other purposes — contracts, despatch advices, project references — use different document type codes and don't count toward this limit.
Why This Rule Exists
The invoiced object field exists to point at a single external artefact that the invoice is billing against — a specific order, a specific contract line, a specific delivery. Allowing more than one would make it structurally ambiguous which object the invoice amount actually corresponds to, which defeats the purpose of the field. This is one of a family of "occurs at most once" rules across the document header, each protecting a specific reference from being duplicated into an unresolvable state.
Standard / Code List
Document type code 130 is drawn from UNCL1001, the same invoice/document type code list referenced elsewhere in the PINT-AE schema for distinguishing reference purposes within the generic AdditionalDocumentReference structure.
UAE Data Example
PASSES ✓: A single <cac:AdditionalDocumentReference> block with <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode> pointing to the specific work order the invoice bills against, alongside a separate reference block using a different type code for the delivery note.
FAILS ✗: An ERP integration that maps every linked document from a multi-document sales order into type code 130, producing two or three invoiced-object references on the same invoice because the mapping logic didn't distinguish invoiced-object references from other reference types.
What Your ERP / IT Team Must Ensure
Check the mapping logic that assigns document type code 130 specifically — it should be reserved for the one object the invoice is genuinely billing against, not applied generically to every linked document. Where a transaction genuinely relates to more than one external object, use the correct distinct type codes for each rather than reusing 130, and confirm the invoiced-object field is populated from a single, deterministic source field in the originating sales or purchasing document.
Related Rules
Part of the same family of document-level single-occurrence checks as the project reference rule — see BR-63 below for the empty-element rule that governs the same reference structures at a more basic syntactic level.