Multi-currency trips without the rounding mess

Three of you land in Bali having already paid for flights in rupees, eat at Changi in Singapore dollars, and pay for the villa in rupiah, a number with six digits in it. Somebody suggests "we'll work it out at the end". Nobody works it out at the end.

A group in SplitPocket has one currency, on purpose. Here's how to run a three-currency trip inside it honestly.

Pick the currency you'll settle in

Not the currency you're spending in. The one the final transfers will happen in. For a group of friends who all bank in India, that's rupees, even for a trip where you never touch a rupee. Set it when you create the group, before the first expense, because it's the one decision that's annoying to change later.

Convert at entry, using the rate you were actually charged

There are three rates on any given day: the mid-market rate you see when you search, the rate your card gave you, and the rate the airport counter gave you. Only one of them describes money that actually left your account. Use the rate from your statement, since it already includes the forex markup, which is a real cost somebody has to bear.

Split three ways, that's ₹8,205.73, ₹8,205.73 and ₹8,205.72. The odd two paise go to the first two shares so the column still totals ₹24,617.18 exactly. This is the entire reason money should be handled in whole minor units rather than floating-point rupees.

Put the original amount in the description

Villa 4 nights, IDR 1,850,000 @ 195. It costs you four seconds and it settles every future argument, because the person querying the number can check your arithmetic instead of your memory. It also means the expense still makes sense in eight months when someone is doing their taxes.

Minor units are not always two decimals

A rupee is 100 paise and a dollar is 100 cents, so people assume every currency has two decimal places. The yen has none: ¥1,500 is 1,500 minor units, and "¥1,500.00" is a formatting bug. Dinars have three. An app that stores everything as "amount × 100" gets Japan wrong, and gets it wrong silently.

SplitPocket handles ten currencies using the real ISO 4217 rules for each: how many decimal places, how the symbol is placed, how digits are grouped. ₹1,00,000 groups differently from $100,000, and both are printed the way the people reading them expect.

The cash pool problem

Someone changes ₹15,000 into rupiah at the airport and becomes the group's wallet for the week. Don't log the exchange as an expense: no money has been spent, it's just changed shape. Instead:

• The pool holder logs each thing the cash pays for as a normal expense, paid by them, converted at the rate they got at the counter.
• Anyone who contributed to the pool records it as a settlement tothe pool holder, because that's money that genuinely moved between two people.
• Leftover cash at the end goes back proportionally, or gets recorded as a settlement in the other direction. Either way it's a real transfer, not an expense.

Settling across borders

Settle in the group's currency, using whatever rail is cheapest between the two people involved: UPI at home, a transfer app across borders. Record the settlement for the amount the ledger says, and if the transfer fee came out of the receiver's end, log that fee as its own small expense rather than fudging the settlement amount.

The principle underneath all of this: the ledger records what happened, not what should have happened. Fees happened. Bad airport rates happened. Write them down and the numbers stay trustworthy.