Module arith 

Rounding and slack used by VAT/GST/SST derivation.

Four tolerance regimes — never mixed

Slack is a rule instance, never a crate constant applied to every amount, never InvoiceAmount policy.

1. Totals BR-CO-10…BR-CO-16 — exact. CEN. Absent ≠ 0; overflow is a finding, not wrap. Do not put ±1.00 or ±0.02 here.
2. VAT derivation (BR-CO-17, family -09) — ±1.00 exclusive on absolute values (|Δ| < 1; Δ = 1.00 fails). Artefact-only slack; EN 16931-1 §6.4.2 writes a plain equation. Credit notes use abs so a negative base still derives.
3. Peppol R120 / R040 — ±0.02 inclusive. Lives on those Peppol extra rules (P13), not here. R046 is exact (the classic trap of copying R120’s slack onto line VAT).
4. XRechnung HUF 0.5 — those two Peppol-shaped rules only, and out of this crate (P18). No HUF branch in core or Peppol.

Malaysian 5-sen cash rounding is BT-114, not slack. There is no fatal “payable multiple of 0.05” rule.

Why rounding needs its own module

The CEN artefacts spell derived tax in XPath:

round(abs(TaxableAmount) * (Percent div 100) * 10 * 10) div 100

and pick the zero-rate branch with round(Percent) = 0. Both rounds are XPath’s fn:round: closest integer, ties toward +∞ = floor(x + 0.5).

	round(0.5)	round(2.5)	round(-0.5)
XPath fn:round	1	3	0
Decimal::round (banker’s)	0	2	0
half away from zero	1	3	-1

A rate of 0.5 % (Spanish recargo) rounds to 1 for the artefact and to 0 for banker’s rounding, which sent BR-CO-17 down its zero-rate branch and rejected a valid invoice.

The producer ([crate::reconcile]) may use commercial rounding for the printed numbers; the validator uses xpath_round. The ±1.00 slack is what lets those two disagree by a unit.

Constants

VAT_TOLERANCE

The ±1.00 the artefacts allow on the VAT derivation family.

Functions

derived_vat

Artefact derived tax: round(|base| × rate) / 100.

within_vat_tolerance

Whether stated is within the artefacts’ ±1.00 of expected (exclusive).

xpath_round

XPath fn:round — closest integer, ties toward +∞.