Divide one payment across many recipients and rounding stops being cosmetic.
Round each share on its own and the parts no longer sum to the whole. You end up a cent short, or a cent over. Nothing errors. It surfaces later, when the payout account drifts from the ledger and someone has to explain the difference in a meeting.
We hit this in lending flows, where a single borrower repayment is distributed pro rata across every investor in a deal.
What works for us: treat the split as one allocation function, not as N independent calculations. It takes the total and the shares, returns parts that provably sum back to the total, and applies a deterministic rule for the remainder (largest fractional part first, ties broken by a stable key, not by whatever order the database happened to return).
Then you write the remainder as a visible ledger entry instead of absorbing it quietly. If someone asks why they received an extra cent, the answer sits in the data, not in the source code.
The same goes for anything that gets divided: fees, refunds, revenue share, tax. Each of those needs one owner in the code and an explicit rule for the leftover. Rounding scattered across a codebase is a leak with no alarm on it.
Your system already decides who gets the leftover cent, probably without anyone having written that rule down.