Splitting one repayment across many investors is not division. It is allocation, and somebody has to own the last cent.
On a P2P lending platform a borrower repays a single amount, and that amount has to become a credit for every investor in the deal, pro-rata to their share. The arithmetic almost never divides cleanly. Two decimals and a rounding mode look harmless until the parts you wrote to the ledger stop adding up to the money you received. The gap is tiny per payment and permanent per platform.
What worked for us:
Do all of it in minor units, as integers. Floats have no business in a ledger.
Floor every share, then hand out the remaining units by an explicit rule (largest fractional part first, ties broken by a stable key), so the same input always produces the same split.
Assert that the sum of the parts equals the amount received before a single row is written. That is an invariant in the code path, not a test you run nightly.
Store the rounding rule with the allocation, not just the result.
The effort pays off for a reason that has little to do with accounting tidiness. Support can answer why one investor got 3.33 and another got 3.34, and a replay produces the same answer. Rounding is a product decision, and it needs an owner who is not the developer who happened to write the loop.
If you move money between multiple parties, you probably face the same choice: spread the remainder across participants, or designate one bearer for it.