The bug class that scales worst in production is the one that is correct in every row and wrong only in the total.
Rounding is the cleanest example. Split a repayment across investors pro rata and you get fractions, and something has to happen to them. Round each share on its own and every single line is defensible (each investor got the mathematically nearest amount), while the sum of the shares no longer equals the payment that arrived. A fraction of a unit per distribution, invisible.
Nothing raises. No log line. Tests pass, because the unit tests assert per-share values, and per share the code is right.
It surfaces later as a ledger that will not close. By then the drift is smeared across months of distributions, and you cannot tell which ones to correct without replaying all of them.
So I treat conservation as an assertion instead of an assumption. The distribution function returns the shares and the remainder as separate outputs, and the remainder gets allocated to a defined party by an explicit rule rather than evaporating. The check that the parts equal the whole runs inside the same transaction that writes them, and a failure refuses the write instead of logging a warning.
Money bugs do not have to be big to be expensive. They have to be plausible in isolation.
Somewhere in your system there is probably an invariant that still gets checked per row only...