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-106 | Schematron ID: ibr-co-11 Fatal (error) cac:LegalMonetaryTotal

Assert text: [ibr-co-11]-Sum of allowances on document level (ibt-107) = Σ Document level allowance amount (ibt-092).

Test: xs:decimal(cbc:AllowanceTotalAmount) = round(sum(../cac:AllowanceCharge[cbc:ChargeIndicator=false()]/xs:decimal(cbc:Amount)) * 10 * 10) div 100 or (not(cbc:AllowanceTotalAmount) and not(../cac:AllowanceCharge[cbc:ChargeIndicator=false()]))

Classification

Transaction Data. The rule reconciles the allowance summary in the monetary totals block against the individual allowance entries on the same document.

What the Rule Is Checking

Document-level allowances — discounts applied to the invoice as a whole rather than to a single line — are carried in cac:AllowanceCharge blocks with ChargeIndicator set to false. The ChargeIndicator flag is what separates an allowance from a charge: true marks a charge such as freight, and charges are summed by a separate rule into IBT-108. This rule sums every allowance amount (IBT-092), rounds to two decimals, and requires cbc:AllowanceTotalAmount (IBT-107) to equal that sum. The second branch of the test permits omitting the total entirely when the invoice carries no document-level allowances at all.

Why This Rule Exists

The allowance total feeds directly into the tax-exclusive amount: net of lines, minus allowances, plus charges. A declared allowance total that disagrees with the itemised allowances leaves the recipient unable to tell which figure the seller intended — and since document-level allowances usually carry their own VAT category, the discrepancy propagates into the tax calculation as well as the totals. Reconciling the summary against its detail at validation time closes that gap before the invoice reaches the buyer or the authority.

UAE Data Example

PASSES ✓

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:Amount currencyID="AED">100.00</cbc:Amount>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:Amount currencyID="AED">57.25</cbc:Amount>
</cac:AllowanceCharge>
<cac:LegalMonetaryTotal>
  <cbc:AllowanceTotalAmount currencyID="AED">157.25</cbc:AllowanceTotalAmount>
</cac:LegalMonetaryTotal>

FAILS ✗

<cac:LegalMonetaryTotal>
  <cbc:AllowanceTotalAmount currencyID="AED">150.00</cbc:AllowanceTotalAmount>
</cac:LegalMonetaryTotal>

The itemised allowances sum to 157.25; a summary figure of 150.00 — often a negotiated round number entered manually while the detail lines carried the exact amounts — fails validation.

What Your ERP / IT Team Must Ensure

  • Compute IBT-107 from the serialised allowance blocks at mapping time instead of mapping a separately maintained discount summary field.
  • Verify the ChargeIndicator mapping: an allowance accidentally serialised with true disappears from this sum and lands in the charge total, breaking both figures at once.
  • Omit AllowanceTotalAmount entirely on invoices with no document-level allowances — a zero-value element paired with no allowance blocks fails the first branch of the test.
  • Keep line-level discounts out of this calculation; they belong inside the line net amount, and mixing the two levels is a common source of reconciliation breaks.

Related Rules