A cent is the most dangerous bug in a money system, because nothing in the system is built to notice it.
A missing payment gets escalated the same day. A rounding remainder passes validation, passes the tests, sits far below any alerting threshold, and reads like noise in a report.
The mechanics are mundane. You split an amount pro-rata across several parties (multiple investors in one deal, a settlement across obligations) and you round each share on its own. Every share is correct in isolation. Their sum is not the amount you started with. Someone now owns a remainder that no row in the system claims.
That gap does not stay a gap. It compounds per deal, per payout, per cycle, and it surfaces eventually in the one place it becomes visible: reconciliation against what the bank actually settled. By then the mismatch has no single cause you can point at. It is months of arithmetic, and rounding drift looks the same as a real attribution error.
What I do instead: money stays in integer minor units, the split derives the last share from the total instead of computing it independently, the remainder gets an explicit owner by policy, and sum-equals-total is an assertion at write time that fails loudly.
Small bugs turn into production problems when the system holds no invariant capable of detecting them. No better rounding mode fixes that. What fixes it is making "the parts must equal the whole" something the code refuses to violate.
So the question is where you enforce it: in the ledger write, or in a job that checks afterwards.