Source: PINT-AE BIS Invoice v1.0.2 Schematron — PINT UBL Validation Rules (standard)

Rule at a Glance

ID Severity Context (XPath)
Series ref. BR-108 | Schematron ID: ibr-co-16 Fatal (error) cac:LegalMonetaryTotal

Assert text: [ibr-co-16]-Amount due for payment (ibt-115) = Invoice total amount with Tax (ibt-112) - Paid amount (ibt-113) + Rounding amount (ibt-114).

Test: a four-branch expression covering each combination of cbc:PrepaidAmount and cbc:PayableRoundingAmount being present or absent, each branch requiring cbc:PayableAmount to satisfy the equation above after two-decimal rounding.

Classification

Transaction Data. The rule closes the calculation chain that began with the line net amounts, fixing the final figure a buyer is asked to pay.

What the Rule Is Checking

The amount due for payment (IBT-115) must equal the tax-inclusive total, less any amount already paid (IBT-113), plus any rounding amount (IBT-114) applied to bring the payable figure to a convenient value. When neither optional element is present, payable must simply equal the tax-inclusive total. When a prepayment is present, it must be subtracted exactly; when a rounding amount is present, the payable figure net of that rounding must still reconcile.

Why This Rule Exists

Advance payments give this rule its practical weight in the UAE. Where an advance was received and invoiced, the final invoice shows the full tax-inclusive value while the amount due reflects only the balance — the prepaid element is the bridge between the two, and it is also the figure that keeps VAT from being collected twice on the same consideration. A payable amount that ignores a declared prepayment overbills the buyer; one that subtracts more than was declared understates the receivable. Either way the document contradicts itself, and the validation layer rejects it before payment logic on the receiving side can act on the wrong number.

UAE Data Example

PASSES ✓

<cac:LegalMonetaryTotal>
  <cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="AED">1000.00</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="AED">4250.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

FAILS ✗

<cac:LegalMonetaryTotal>
  <cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="AED">1000.00</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="AED">5250.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

A declared prepayment of 1000.00 with a payable amount still at the full gross value asks the buyer to pay the advance twice. The arithmetic contradiction fails the invoice.

What Your ERP / IT Team Must Ensure

  • Map the advance-settlement value from the billing document into PrepaidAmount and derive PayableAmount by calculation, rather than mapping both from source fields that can move independently.
  • Trace how down-payment clearing works in the ERP — in SAP-style processes the cleared advance often sits in separate accounting lines, and the mapping layer must pick up the settled value, with the invoice’s own tax point unaffected.
  • Use PayableRoundingAmount only for genuine payable rounding (for example rounding to the nearest fils denomination), and include it in the equation when present.
  • Test the four presence combinations explicitly: no prepaid and no rounding, each alone, and both together — each is a separate branch of the schematron test.

Related Rules