The repayment landed. Every investor got paid. The deal still would not close.
Multi-investor loan, pro-rata returns. The distribution code took the incoming repayment, multiplied it by each investor's share, rounded, and wrote the payouts. Each row was correct on its own. The sum was not the amount that had actually arrived.
The gap was smaller than the smallest unit anyone cared about. It still sat in the ledger as an unexplained delta on that deal, so reconciliation flagged it and refused to mark the repayment settled. One deal, then a handful. Eventually the people doing moderation stopped trusting the settled flag and started checking deals by hand.
That was the real cost. Nobody lost money. What got lost was the ability to believe a field, and a field you don't believe has to be replaced by a human.
The fix was not better rounding. It was treating distribution as splitting integer minor units instead of multiplying decimals: allocate the floors, then hand out the leftover units by largest remainder. The residual gets an explicit owner instead of quietly disappearing. Then check that the parts sum to the total inside the same transaction as the write, not in a nightly job afterwards.
Now I write that invariant before the business rule. Anywhere money fans out to several parties, I assume the shares will not sum, and I make the code prove they do.
I write more about this kind of production detail on my blog: https://polycratia.com/c/c037db37
If your system splits money across parties, someone owns the remainder: you should be able to name them...