A rounding remainder is the cheapest bug in a money system, and the one that scales worst.
One cent. No exception, no alert, no failed request.
The mechanics are what make it dangerous. Split a repayment across multiple investors pro rata and every line rounds correctly on its own, while the sum of the lines no longer equals the amount that actually arrived. The code is locally right and globally wrong, and that is exactly the shape of bug a unit test misses: the assertion you write is about one share, not about conservation.
Then it compounds. The remainder has to land somewhere, so it lands on whoever the loop happened to touch last. If the allocation iterates over an unordered query, "last" changes between runs, and the moment a payout gets retried the same input produces a different distribution. By then you don't have a rounding bug. You have an idempotency bug wearing a rounding bug's clothes.
So I treat distribution as a conservation problem before an arithmetic one: integer minor units, deterministic ordering, an explicit remainder policy, and one invariant checked at the boundary. The sum of allocations equals the source amount, or the distribution refuses to commit at all.
A balance that is off by a cent is not a small error. It is a ledger you can no longer prove.
I write up more of these failure modes on my blog: https://polycratia.com/c/34a9acd6
Worth knowing where your system puts the remainder today, and whether you could re-derive the same split twice...