Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-73 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-090 | Field: ibt-011 — Project reference, at document level | ||
Classification
Syntax & Integration — a cardinality constraint on a header field, and one of the few in the profile that counts occurrences across two separate XML structures in a single test.
What the Rule Is Checking
The test has two conditions and both must hold. The count of cac:ProjectReference elements must be one or fewer, and the count of cac:AdditionalDocumentReference elements whose cbc:DocumentTypeCode equals 50 must also be one or fewer.
The two counts are evaluated independently and joined by a logical and, so a document carrying one of each still passes.
Why This Rule Exists
A project reference at document level asserts that the whole invoice belongs to one project. That assertion drives cost allocation in the buyer's system and, on UAE construction and infrastructure work, the segregation of costs across contracts with different VAT treatments, retention terms and completion dates. Two references at header level leave the recipient with no rule for splitting the document.
Where an invoice genuinely spans two projects, the profile leaves one route: split the document. There is no line-level project reference to move it to — ibt-011 exists at document level only. The same single-occurrence pattern governs the contract reference in ibr-094 and the receiving advice reference in ibr-095.
The rule counts two structures because the two document types carry the reference differently. An invoice sends it in cac:ProjectReference/cbc:ID. A credit note has no such element, so there the reference travels as cac:AdditionalDocumentReference with document type code 50. One assertion spanning both counts polices invoices and credit notes without a separate test for each.
The exposure falls on mapping teams that populate both structures to hedge against which one the receiver reads. A system emitting two type-50 references — one from the project field, one from a generic reference block that already held the code — fails on the second condition while the first passes cleanly. The rejection message names ibt-011, and the offending element is an additional document reference the project mapping never touched.
Standard / Code List
The value 50 is a document type code, tested here as a literal. It is the marker the profile uses for a project reference carried in cac:AdditionalDocumentReference, in the same way code 130 marks an invoiced object reference. The profile narrows that structure further: where the project reference is sent this way, only cbc:ID and cbc:DocumentTypeCode are permitted inside the element.
UAE Data Example
PASSES ✓: A single cac:ProjectReference carrying the contractor's project code for a Dubai infrastructure package, with no type-50 additional document reference.
PASSES ✓: No project reference at all, on a routine goods invoice.
FAILS ✗: Two cac:ProjectReference elements on a consolidated invoice covering two phases of the same development, each phase carrying its own project code.
FAILS ✗: One cac:ProjectReference plus two cac:AdditionalDocumentReference elements with document type code 50, where the mapping wrote the project code into both the dedicated element and a generic reference block that already contained it.
What Your ERP / IT Team Must Ensure
- Map the project reference by document type:
cac:ProjectReferenceon invoices, a single type-50 additional document reference on credit notes. Emitting both to hedge against receiver behaviour is what creates the duplicate. - Audit any generic reference block that maps to
cac:AdditionalDocumentReferencefor code 50 values arriving from a second source field. - Split multi-project billing into one document per project. Repeating the header element is the failure, and no line-level project reference exists to carry the second one.
- Read the rejection message with the second condition in mind. A failure citing ibt-011 may be caused by an additional document reference the project team never touched.
- Apply the same review to the contract and receiving advice references, which carry equivalent maximum-once constraints in the same rule block.
Related Rules
Rules ibr-094 and ibr-095 constrain the contract reference and the receiving advice reference to a single occurrence each, and ibr-089 applies the same logic to the invoiced object at line level. Where a mapping duplicates one header reference it usually duplicates the others, so these are worth testing as a set.