money-movement

Money movement

Money that has left cannot be recalled by writing an inverse statement. There is no undo certificate for a refund, and claiming one is the single worst thing this skill exists to prevent.

A MONEY_MOVEMENT change always carries a SCOPE certificate. The claim is not "we can put it back". The claim is exactly these payments, to exactly these counterparties, for exactly this total — and explicitly not these others, for these reasons.

---

1. The four questions

1. How much, in minor units, and in which currency? Never work in decimal majors. A float somewhere in the pipeline is how £41,904.00 becomes £41,903.99 across a thousand rows and the reconciliation fails for a week.
2. To whom, counted as counterparties rather than as rows? Ten refunds to one customer is one angry phone call. One refund to ten thousand customers is a different event.
3. Has any of it already gone out? This is the failure that matters. See §3.
4. What is deliberately excluded, and why? The exclusion list is the part a reviewer actually reads.

---

2. Minor units, always

Compute, store, compare and report in the smallest unit of the currency. Convert to a display form exactly once, at the edge, for a human.

-- right
SELECT SUM(amount_minor) FROM charges WHERE ...;

-- wrong: introduces a float, and 0.1 + 0.2 is not 0.3
SELECT SUM(amount / 100.0) FROM charges WHERE ...;

Be careful with currencies that are not two-decimal. JPY and KRW have zero decimal places; BHD, KWD and TND have three. amount_minor / 100 is wrong for five of the currencies you are likely to meet. Read the currency, do not assume it.

Never sum across currencies to produce a single ceiling check. SUM(amount_minor) over mixed EUR and JPY is a meaningless number that will pass a ceiling it should not.

---

3. Double payment — the failure that matters

The dangerous scenario is not "the refund fails". It is "the refund succeeds twice". Three defences, and use all three.