Source: PINT-AE BIS Invoice v1.0.2 Schematron

Rule at a Glance

ID Severity Context (XPath)
Series ref. BR-74 Fatal (error) cac:LegalMonetaryTotal
Schematron ID: ibr-091  |  Field: ibt-115 — Amount due for payment

Classification

Transaction Data — a formatting constraint on the single number the buyer actually settles against.

What the Rule Is Checking

The assert reads string-length(substring-after(cbc:PayableAmount, '.')) <= 2. It takes everything after the decimal point in the payable amount and counts the characters. Three or more, and the document is rejected.

Two properties of that test matter in practice. It is a string test, not a numeric one, so 1500.500 fails even though it is arithmetically identical to 1500.50. And substring-after returns an empty string when there is no decimal point at all, which means a whole-number amount such as 1500 passes cleanly. The rule sets a ceiling on precision, not a requirement to state it.

Why This Rule Exists

The amount due for payment is the figure that reconciles the invoice to a bank transfer. A third decimal cannot be paid, so it has to be resolved somewhere — and if the sender and the receiver resolve it differently, the AP ledger and the AR ledger disagree by fractions that accumulate across thousands of documents and surface months later as unexplained residual balances.

PINT applies the same two-decimal ceiling to the other monetary totals through ibr-121 to ibr-125, covering document level allowances and charges, the total without tax, the total tax amount and the total with tax. ibr-091 closes the set at the payable figure. Rounding is therefore a decision the sender must make and record before transmission.

Standard / Code List

No code list applies. The constraint is on the lexical form of a UBL Amount value, and the currency attribute is governed separately by the ISO 4217 rules covered in the currency-code post in this series.

UAE Data Example

PASSES ✓

<cac:LegalMonetaryTotal>
  <cbc:TaxExclusiveAmount currencyID="AED">12500.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="AED">13125.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="AED">13125.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

A value of 13125 with no decimal component would also pass.

FAILS ✗

<cbc:PayableAmount currencyID="AED">13125.375</cbc:PayableAmount>

Three decimals. This is the classic output of a five per cent VAT calculation on an odd line total that has been carried through to the header without an explicit rounding step. 13125.750 fails for the same reason despite being a clean half-fils figure, because the trailing zero is counted as a character.

What Your ERP / IT Team Must Ensure

  • Round the payable amount to two decimals at the point the value is written into the XML, not at the point it is displayed on a PDF or a screen.
  • Check the serialisation layer for trailing zeros. Some XML binding libraries emit the scale of the underlying decimal type, so a BigDecimal carrying a scale of three will serialise as three decimals even when the third is zero.
  • Confirm the rounding rule is applied consistently across all six amount fields, so the payable amount still equals the total with tax less the prepaid amount plus any rounding amount after each has been truncated.
  • Where the invoice is in a foreign currency with an AED tax accounting currency, apply the same check to the AED-denominated fields required by ibr-175-ae.
  • Add a pre-transmission assertion in the ASP integration layer so a three-decimal amount is caught before it consumes a Corner 2 rejection cycle.

Related Rules

ibr-015 makes the amount due for payment mandatory on every invoice. ibr-121 through ibr-125 impose the same two-decimal ceiling on the remaining monetary totals. ibr-127-ae requires a payment due date whenever the payable amount is greater than zero, outside credit notes and deemed supplies.