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-107 | Schematron ID: ibr-co-15 Fatal (error) /ubl:Invoice | /cn:CreditNote

Assert text: [ibr-co-15]-Invoice total amount with Tax (ibt-112) = Invoice total amount without Tax (ibt-109) + Invoice total Tax amount (ibt-110).

Test: cac:TaxTotal/cbc:TaxIncludedIndicator = true() or (cac:LegalMonetaryTotal/xs:decimal(cbc:TaxInclusiveAmount) = round((cac:LegalMonetaryTotal/xs:decimal(cbc:TaxExclusiveAmount) + cac:TaxTotal/xs:decimal(cbc:TaxAmount[@currencyID=/*/cbc:DocumentCurrencyCode])) * 10 * 10) div 100)

Classification

Transaction Data. The rule sits at the document root and reconciles the three headline figures of the invoice against each other.

What the Rule Is Checking

The tax-inclusive total (IBT-112) must equal the tax-exclusive total (IBT-109) plus the total VAT amount (IBT-110), rounded to two decimals. Two details in the test matter in practice. First, only the TaxAmount expressed in the document currency participates — an invoice issued in USD that also carries the mandatory AED tax amount must add the USD figure here, and a mapping that picks the wrong occurrence fails the rule. Second, the whole check is bypassed when TaxIncludedIndicator is true, the arrangement where line prices already contain VAT and the addition would double-count it.

Why This Rule Exists

These three figures are the ones every downstream consumer reads first: the buyer's AP system posts the gross amount, the seller's AR ledger carries the net, and the FTA's interest is the VAT between them. An invoice where gross minus net disagrees with the declared VAT is ambiguous about the single number that matters most for tax purposes. The exchange network refuses such a document at validation rather than letting two parties and an authority each resolve the ambiguity differently.

UAE Data Example

PASSES ✓

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="AED">250.00</cbc:TaxAmount>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <cbc:TaxExclusiveAmount currencyID="AED">5000.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="AED">5250.00</cbc:TaxInclusiveAmount>
</cac:LegalMonetaryTotal>

FAILS ✗

<cbc:DocumentCurrencyCode>USD</cbc:DocumentCurrencyCode>
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="AED">918.75</cbc:TaxAmount>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <cbc:TaxExclusiveAmount currencyID="USD">5000.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="USD">5250.00</cbc:TaxInclusiveAmount>
</cac:LegalMonetaryTotal>

On a USD invoice the test looks for a USD TaxAmount. Supplying only the AED conversion leaves the addition with nothing in document currency to add, and the rule fails even though every individual figure is plausible.

What Your ERP / IT Team Must Ensure

  • Serialise a TaxAmount in the document currency on every invoice, alongside any AED conversion required for foreign-currency documents.
  • Derive IBT-112 by addition at mapping time rather than mapping gross and net from independent source fields that can round differently.
  • Confirm how the source system represents tax-inclusive pricing — the TaxIncludedIndicator bypass exists for that model, and using it accidentally suppresses a check you want.
  • Regression-test foreign-currency invoices specifically; the currency filter in this test is the branch domestic-only test data never exercises.

Related Rules