Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-101 | Schematron ID: ibr-122 | Fatal (error) | cbc:ChargeTotalAmount (document totals block) |
Assert text: [ibr-122]-Document level charge amount (ibt-108) MUST have no more than 2 decimals.
Test: string-length(substring-after(cbc:ChargeTotalAmount, '.')) <= 2
Classification
Transaction Data. The rule checks the number of decimal places carried in a single monetary total on a specific invoice, not how the invoicing system is configured to round generally.
What the Rule Is Checking
Document Level Charge Amount (IBT-108) is the total of all document-level charges added to the invoice — freight, packaging, or similar surcharges applied at header level rather than to individual lines. The rule counts the digits after the decimal point in that value and fails if there are more than two. It sits alongside near-identical checks on the allowance total (IBT-107), the tax-exclusive total (IBT-109) and the tax-inclusive total (IBT-112) — every monetary total field in the document carries the same two-decimal ceiling.
Why This Rule Exists
AED, like most currencies represented in PINT-AE, has two decimal places as its minor unit. A value like 125.4567 is a figure the currency cannot actually settle in, and it signals that a rounding or calculation step upstream produced a raw floating-point result that was never normalised before being written to the payload. Because the document-level charge total also feeds the cross-field arithmetic checks that tie invoice totals together (ibr-co-12, ibr-co-13 and related rules), an over-precise value here does not just fail on its own — it can silently break the totals reconciliation those rules perform.
UAE Data Example
PASSES ✓
<cbc:ChargeTotalAmount currencyID="AED">150.00</cbc:ChargeTotalAmount>FAILS ✗
<cbc:ChargeTotalAmount currencyID="AED">150.004</cbc:ChargeTotalAmount>The value has three decimal places. Whatever calculation produced 150.004 — a percentage-based freight surcharge, most likely — was never rounded to currency precision before being written into the field.
What Your ERP / IT Team Must Ensure
- Apply currency-precision rounding at the point a charge total is calculated, not at the point it is serialised into XML — the mapping layer should receive an already-rounded value, not perform the rounding itself as an afterthought.
- Audit any percentage-based or formula-driven charge (freight surcharges calculated as a percentage of line value, tiered handling fees) specifically, since these are the most common source of a three-or-more-decimal result.
- Confirm the rounding method used (round-half-up versus round-half-even) is consistent across the ERP's finance configuration and the invoicing mapping layer — a mismatch here produces totals that pass this rule individually but fail the cross-field reconciliation rules.
- Test invoices carrying multiple stacked document-level charges, since compounding calculations are where precision drift is most likely to surface.