Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-116 | Schematron ID: ibr-055-ae | Fatal (error) | Invoice (root) with InvoiceTypeCode 381 or 81 |
Assert text: [ibr-055-ae]-Preceding invoice reference (IBG-03) is must when invoice type code (IBT-003) is 381 (Credit note) or 81 (Credit note related to goods or services) except when the [BTAE-03] Credit note reason code is 'VD'.
Test: ((cbc:InvoiceTypeCode = "381" or cbc:InvoiceTypeCode = "81") and (((cac:BillingReference) and (cac:DiscrepancyResponse/cbc:ResponseCode != "VD")) or (not(cac:BillingReference) and (cac:DiscrepancyResponse/cbc:ResponseCode = "VD")))) or not(cbc:InvoiceTypeCode = "381" or cbc:InvoiceTypeCode = "81")
Classification
Transaction Data / Conditional (document-type-driven).
What the Rule Is Checking
The rule applies only when Invoice type code (IBT-003) is 381 (Credit note) or 81 (Credit note related to goods or services). In that case it checks a paired condition: either a Billing Reference (IBG-03) pointing to the original invoice is present and the credit note reason code is anything other than 'VD', or the Billing Reference is absent and the reason code is exactly 'VD'. Both combinations pass; a credit note with a Billing Reference and a 'VD' reason code, or one with neither a reference nor that reason code, fails.
Why This Rule Exists
'VD' marks a credit note issued to void a document that should never have been raised at all — there is no original invoice to reference because the transaction is being cancelled outright rather than adjusted. Every other credit note is correcting or reducing an amount on a real, prior supply, and the authority needs the Billing Reference to tie that correction back to the invoice it modifies. The rule exists to stop the two document types from being conflated: a genuine correction must carry its lineage, and a void must not carry a reference it cannot legitimately have.
UAE Data Example
PASSES ✓
<cbc:InvoiceTypeCode>381</cbc:InvoiceTypeCode>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>INV-2026-04521</cbc:ID>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:DiscrepancyResponse>
<cbc:ResponseCode>PQ</cbc:ResponseCode>
</cac:DiscrepancyResponse>FAILS ✗
<cbc:InvoiceTypeCode>381</cbc:InvoiceTypeCode>
<!-- no BillingReference -->
<cac:DiscrepancyResponse>
<cbc:ResponseCode>PQ</cbc:ResponseCode>
</cac:DiscrepancyResponse>A credit note that reduces a real invoice but omits the Billing Reference fails outright, because the reason code isn't 'VD' and the rule has no reference to validate against. The same structure with the reason code changed to 'VD' and the reference genuinely absent would pass — the fields have to agree with each other, not just be individually populated correctly.
What Your ERP / IT Team Must Ensure
- Make Billing Reference a mandatory field in the credit note workflow whenever the reason code selected is anything other than 'VD', and lock it out entirely when 'VD' is selected.
- Treat the BTAE-03 reason code dropdown and the invoice-reference lookup as linked controls in the AR module's credit note screen — changing one should re-validate the other before the document can be finalised.
- Reconcile the referenced invoice number against the original invoice register before submission, since a Billing Reference pointing to a non-existent or already-cancelled invoice will fail downstream even if this rule alone passes.
- Build a 'void' path in the credit note workflow that is structurally distinct from a 'correction' path, rather than relying on staff to remember to leave the reference blank.
Related Rules
No directly related published rule posts yet in this series.