A borrower repaid in full, and the investor payouts came to one unit less than what came in.
One unit. On a single deal that is dust. The ledger filed it as an unmatched remainder and parked it, which is the only reason I ever saw it.
The cause was pro-rata rounding. Each investor's share of a repayment in a multi-investor deal has to be rounded to the smallest currency unit, and nothing in the code owned the gap between the sum of those rounded shares and the amount actually received. The split was computed, never reconciled. So on every repayment of every multi-investor deal, the remainder went somewhere: sometimes quietly absorbed, sometimes created out of nothing.
Nothing threw an error. To the person receiving it, every individual payout looked correct. The only visible symptom was a reconciliation queue growing slightly faster than it drained.
The missing unit was cheap. The expensive part was that for a stretch of time I could not prove the total, and proving it meant reconstructing splits from inputs I was lucky to have still retained.
What I do differently now: a distribution is not valid until the parts sum to the whole, and that assertion lives in the same transaction that writes the rows. The remainder gets an explicit owner, a deterministic rule for who absorbs it, stamped on the row instead of left to arithmetic. And money is integers in the smallest unit, not floats.
I write more about payment attribution and ledger invariants here: https://polycratia.com/c/eac71cd8
If you run a ledger that splits money between parties, the thing I would want to know is who owns your rounding remainder, and whether that rule is written down anywhere outside the code...