Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| BR-15 | Fatal (error) | ubl:Invoice/cac:LegalMonetaryTotal |
| Series reference: BR-15 | Schematron ID: ibr-015 | ||
Classification
Transaction Data — The amount due for payment (IBT-115) is the final net payable figure after deducting any prepaid amounts (IBT-113) from the total with tax (IBT-112) and applying any rounding (IBT-114). It is the operationally critical field for accounts payable — the figure that drives payment instructions and settlement records.
What the Rule Is Checking
BR-15 fires when the cac:LegalMonetaryTotal block does not contain a cbc:PayableAmount element. This element holds IBT-115 and is the last mandatory field in the legal monetary total sequence. It must always be present even when IBT-115 equals IBT-112 (i.e., no prepayment has been made). A zero-value PayableAmount is valid — it simply means the invoice has been fully prepaid.
Why This Rule Exists
IBT-115 is the field that drives downstream payment processing. In an automated AP workflow, the buyer's ERP reads IBT-115 to post the payment obligation. Without it, the system cannot determine whether a balance remains outstanding or has been cleared by a prior payment, making automated three-way matching (purchase order, goods receipt, invoice) impossible.
From the FTA's perspective, IBT-115 is the figure that must reconcile with the buyer's claimed input tax position. If the invoice records a zero amount due because a prepayment cleared it, the input tax on the prepayment invoice must already have been recognised. The audit trail depends on IBT-115 being present and correctly calculated.
Standard / Code List
No code list applies. The value is a decimal in the invoice currency (IBT-005). A zero value (0.00) is valid and indicates a fully prepaid invoice. Negative values are not permitted on an invoice (only on credit notes).
UAE Data Example
PASSES ✓ — standard invoice, no prepayment
<cac:LegalMonetaryTotal>
<cbc:TaxExclusiveAmount currencyID="AED">5000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="AED">5250.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
PASSES ✓ — fully prepaid invoice
<cac:LegalMonetaryTotal>
<cbc:TaxExclusiveAmount currencyID="AED">5000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
<cbc:PrepaidAmount currencyID="AED">5250.00</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="AED">0.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
FAILS ✗
<cac:LegalMonetaryTotal>
<cbc:TaxExclusiveAmount currencyID="AED">5000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
<!-- PayableAmount missing — BR-15 fires as fatal -->
</cac:LegalMonetaryTotal>What Your ERP / IT Team Must Ensure
- Always output
cbc:PayableAmount— even when the value is0.00. Omitting the element entirely is the failure mode BR-15 targets. - Calculate IBT-115 as: IBT-112 minus IBT-113 (PrepaidAmount) plus IBT-114 (PayableRoundingAmount). Hardcoding the value from the gross total without checking for prepayments is a common integration error.
- Ensure your ERP advance payment or deposit logic writes a PrepaidAmount element when a deposit has been applied, so IBT-115 reflects the true outstanding balance.
- For UAE advance payment invoices (where a deposit is received before the final invoice), the final invoice must show the original prepayment reference and reduce IBT-115 accordingly.
- Include IBT-115 in your pre-clearance validation — a missing PayableAmount causes a fatal rejection at the ASP before the document reaches the PEPPOL network.
Related Rules
BR-13 (IBT-109 — net total), BR-14 (IBT-112 — total with tax), BR-CO-16 (mathematical relationship: IBT-115 = IBT-112 - IBT-113 + IBT-114). See also advance payments and retention in UAE e-invoicing.