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

Assert text: [ibr-co-10]-Sum of Invoice line net amount (ibt-106) = Σ Invoice line net amount (ibt-131).

Test: xs:decimal(cbc:LineExtensionAmount) = round(sum(//(cac:InvoiceLine|cac:CreditNoteLine)/xs:decimal(cbc:LineExtensionAmount)) * 10 * 10) div 100

Classification

Transaction Data. The rule tests arithmetic inside one assembled invoice — the header total against the lines beneath it — and touches no master data or configuration.

What the Rule Is Checking

Every invoice line carries a net amount (IBT-131) in cbc:LineExtensionAmount. The header block cac:LegalMonetaryTotal repeats the figure once as Sum of Invoice line net amount (IBT-106). This rule adds up every line net amount, rounds the result to two decimals, and requires the header figure to equal that sum exactly. The same arithmetic applies to credit notes, where the lines are cac:CreditNoteLine.

Why This Rule Exists

IBT-106 is the first figure in the calculation chain that ends at the amount due for payment, and it is the figure a recipient system or an FTA reconciliation recomputes first. If the header total drifts from the lines — a stale mapped value, a total computed before a line was dropped, or line-level rounding performed differently from header rounding — every downstream total inherits the error. Failing the invoice at this point is cheaper for everyone than letting an internally inconsistent document into the exchange network, where sender and receiver would each book different numbers from the same file.

UAE Data Example

PASSES ✓

<cac:InvoiceLine>... <cbc:LineExtensionAmount currencyID="AED">4200.00</cbc:LineExtensionAmount> ...</cac:InvoiceLine>
<cac:InvoiceLine>... <cbc:LineExtensionAmount currencyID="AED">1837.50</cbc:LineExtensionAmount> ...</cac:InvoiceLine>
<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="AED">6037.50</cbc:LineExtensionAmount>
</cac:LegalMonetaryTotal>

FAILS ✗

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="AED">6037.00</cbc:LineExtensionAmount>
</cac:LegalMonetaryTotal>

The lines still sum to 6037.50. A header figure of 6037.00 — typically a value mapped from a source-system field that was rounded or edited independently — fails the invoice outright.

What Your ERP / IT Team Must Ensure

  • Derive IBT-106 by summing the serialised line amounts at mapping time, rather than mapping a separately stored header total that can drift from the lines.
  • Round once, at the point the rule rounds: the sum of lines is rounded to two decimals, so line amounts themselves should already be two-decimal values (see the precision rules BR-101 to BR-103).
  • Apply identical logic to credit notes — the rule reads cac:CreditNoteLine through the same test.
  • Test high line-count invoices, where cumulative rounding differences between a source system's header total and the line-by-line sum surface most often.

Related Rules