Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-76 | Fatal (error) | cac:PrepaidPayment[1] |
| Schematron ID: ibr-093 | Field: ibt-180 — Paid amount; ibt-113 — Total paid amount | ||
Classification
Transaction Data — a conditional presence rule tying a detail structure to its header summary.
What the Rule Is Checking
The rule takes the first cac:PrepaidPayment element as its context and asserts exists(../cac:LegalMonetaryTotal/cbc:PrepaidAmount). If the invoice records a prepayment in detail, the header monetary total must also carry a prepaid amount.
The predicate [1] is what makes this efficient rather than repetitive: the rule fires once per document regardless of how many prepaid payment entries exist. The test is presence only. It does not check that the header total equals the sum of the detail entries, which means a document can satisfy ibr-093 while still being internally inconsistent.
Why This Rule Exists
The amount due for payment is derived, not asserted independently: total with tax, less prepaid amount, plus any rounding amount. If a prepayment is recorded in the detail structure but omitted from the header total, the payable amount computes as though nothing had been paid and the buyer is invoiced twice for the same value.
In the UAE this matters beyond cash. A deposit against a future supply is a tax point event, and the invoice that recognises it forms part of the audit trail an FTA reviewer follows when reconciling output tax to consideration received. A document that shows a prepayment in one structure and not the other gives two defensible readings of the same transaction — and under continuous transaction controls, the reading the authority takes is the one recorded in the transmitted XML, not the one in the seller’s subledger.
Standard / Code List
No code list applies. Both fields are UBL Amount values and are subject to the currency rules governing the rest of the monetary totals.
UAE Data Example
PASSES ✓ — an AED 5,000 deposit taken at order stage, appearing in both structures:
<cac:PrepaidPayment>
<cbc:ID>DEP-2027-00118</cbc:ID>
<cbc:PaidAmount currencyID="AED">5000.00</cbc:PaidAmount>
<cbc:ReceivedDate>2027-03-04</cbc:ReceivedDate>
</cac:PrepaidPayment>
<cac:LegalMonetaryTotal>
<cbc:TaxInclusiveAmount currencyID="AED">13125.00</cbc:TaxInclusiveAmount>
<cbc:PrepaidAmount currencyID="AED">5000.00</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="AED">8125.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>FAILS ✗ — the same prepaid payment block with cbc:PrepaidAmount absent from the monetary total. Note that a document showing a header prepaid amount of 4000.00 against detail of 5000.00 would pass this rule, because ibr-093 tests existence rather than arithmetic. Consistency between the two has to be enforced in your own controls.
What Your ERP / IT Team Must Ensure
- Map the header prepaid amount from the same source as the detail entries, so the two cannot diverge through separate mapping logic.
- Where multiple deposits are applied to one invoice, write the sum into the header field and confirm it reconciles to the detail before transmission.
- Add an internal equality check between the sum of paid amounts and the header prepaid amount. The schematron will not catch a mismatch.
- Verify that the payable amount is recalculated after the prepaid amount is applied, rather than carried forward from the pre-deposit billing document.
- Confirm the deposit and the final invoice do not both report the same output tax, which is a reconciliation failure rather than a validation failure.
Related Rules
ibr-015 makes the amount due for payment mandatory, and ibr-091 caps it at two decimals. The relationship between the prepaid amount and the payable amount is enforced through the monetary total arithmetic rules rather than by ibr-093 itself.