How to Split Bills Across Currencies Fairly

Splitting a bill across currencies is fair when the exchange rate is fixed at the moment the bill happened, not the moment someone gets around to paying back. If a friend fronts €120 for dinner in Belgrade and you owe your share in dollars, the fair amount is your share converted at the rate on the bill date, because that's the rate the payer was actually exposed to. Convert at "today's rate" instead and you hand a random currency movement to whoever settles last. This guide walks through why the bill-date rule is the fair one, the exact numbers on a mixed-currency dinner, how mid-market rates differ from what your bank charges, and how to settle each person in their own currency without a spreadsheet.

The core rule: lock the FX rate at the bill date

When a bill spans currencies, exactly one date matters: the day the money was actually spent. That's the day the payer's bank charged them a real amount in a real currency. Everyone else's share should be converted at that day's rate and then frozen.

Why the payer's exposure is the anchor. Say a friend in the US fronts €120 for a group dinner. On the bill date, EUR/USD is 1.08, so their card was charged roughly $130. That $130 is a fixed fact: it doesn't change no matter when you pay them back. So your share of the bill, expressed in dollars, should also be pinned to the 1.08 rate. Anything else means you're settling a different number than the one the payer was actually out of pocket.

The tempting-but-wrong alternative is "convert at today's rate." It feels neutral, use the current rate, whatever it is. But it silently gambles the group's money on the FX market. If EUR/USD drifts to 1.12 before you settle three weeks later, "today's rate" quietly moves your share up ~3.7% for no reason connected to the dinner. Someone eats that swing, and which side eats it is pure luck of when they paid.

Lock-at-bill-date removes the gamble. The rate is part of the bill record, same as the amount and the date. This is exactly how forward-looking foreign-exchange settlement works in finance: the rate is set when the obligation is created, not when it's discharged.

A worked example: €120 dinner, three currencies

Three friends split a €120 dinner in Berlin, equal shares. Ana lives in the eurozone (EUR), Ben is in the US (USD), and Chloe is in the UK (GBP). Ana paid the whole €120 on her card.

Equal split is €40 each. That's the source-of-truth number, stored in the bill's currency (EUR). Now convert each person's €40 share at the rates on the bill date:

- Ana (EUR): €40. No conversion, she paid, this is her own currency. - Ben (USD): at EUR/USD 1.08 on the bill date, €40 = $43.20. - Chloe (GBP): at EUR/GBP 0.85 on the bill date, €40 = £34.00.

Ben owes Ana $43.20; Chloe owes Ana £34.00. Those numbers are now frozen to the bill. If Ben pays back today and Chloe pays back next month, the rate drift between now and next month is irrelevant: both are settling the euro share Ana actually fronted, each in their own currency.

Compare the "today's rate" version. Suppose Chloe waits five weeks and EUR/GBP has moved from 0.85 to 0.88. A today's-rate app would bill her £35.20 instead of £34.00, an extra £1.20 on a £34 share, purely because of when she opened the app. Over a whole trip with a dozen cross-currency bills, those drifts stack into real, unexplainable money. Locking the rate makes every share reproducible: reopen the bill six months later and Ben's share still reads $43.20.

Which exchange rate? Mid-market, not your bank's

There isn't one single "the" exchange rate on any given day: there's a mid-market rate (the midpoint between buy and sell on the interbank market) and then everyone's markup on top of it.

Use the mid-market rate for the split. It's the neutral, public reference number with no spread baked in. Nobody in the group profits from being the payer, and nobody eats a hidden margin. Split The Bill converts at the mid-market rate snapshotted on the bill date.

Your bank or card is a separate story. When Ana's euro card actually paid a non-euro terminal, or when Ben later sends dollars that get converted to euros, a bank or transfer service adds its own spread, often 0.5% to 3%, sometimes more for cards abroad. That cost is real, but it belongs to the person moving the money, not to the fair split. Trying to bake each person's bank spread into the shares is a rabbit hole: you'd need everyone's exact card fees, and they'd differ per transaction.

The practical convention: split at mid-market, and let each person pick a cheap settlement rail (see below) to minimize their own spread. A Wise or Revolut transfer at near-mid-market keeps the settlement close to the fair number; paying via a card that charges 3% for FX means that person absorbs the 3%, which is fair, because it was their choice of rail.

Settle each person in their own currency

Once shares are locked, settlement is per-person and per-currency. Nobody has to convert anything in their head or agree on a "group currency."

Everyone sees their own number. Ben opens the bill and sees "$43.20." Chloe sees "£34.00." Ana sees the €120 she's owed back, netted across everyone. Each person's display currency is a profile setting, so the running balance on the dashboard always reads in the currency they think in.

Pay via the right rail for the currency. Instead of "I'll figure out the dollars later," each share gets a settle-up action wired to a payment method that fits:

- USD: Venmo or PayPal deep link, amount prefilled. - EUR: SEPA transfer or a scannable QR most European banking apps read from the camera. - GBP: Revolut or PayPal. - Cross-currency (e.g. Ben's USD to Ana's EUR): a Wise deep link with the amount and recipient prefilled, converting near mid-market so the settlement lands close to the locked share.

Which rails show up is driven by the payment methods each person saves in their profile. The point is to collapse the "how do I even send you £34" friction, the thing that leaves cross-currency debts unsettled for months, into one tap.

Edge cases: rounding, tax, tip, and long delays

Rounding. Converting €40 to £34.00 or $43.20 can land on fractions of a cent. Split The Bill rounds each share to the currency's normal precision (2 decimals for USD/EUR/GBP, 0 for zero-decimal currencies like RSD or JPY) and keeps the euro source total exact, so the converted shares always sum back to the real bill without a phantom cent going missing.

Tax and tip. Handle these in the bill's own currency before conversion. If the €120 dinner included €18 tax and a €12 tip, those are already part of the €120 total that gets split: you don't convert first and add tip after, or the tip gets a different rate than the food. Split in the paid currency, then convert the final per-person shares once.

Zero-decimal and high-value currencies. Serbian dinar (RSD), Japanese yen (JPY), and similar don't use minor units the way the dollar does. A €40 share might convert to ~4,690 RSD, displayed as a whole number, no decimals. The math anchors on the euro total regardless, so precision is preserved even when the displayed currency has none.

Long delays. The bill-date rule is fairest when people settle reasonably promptly. If a cross-currency debt ages six months across a volatile pair, the payer may have been exposed to a rate that now feels very different, but that's an argument for settling sooner, not for switching to today's rate (which just moves the unfairness to a different person). If bills routinely age half a year in your group, that's the signal: settle monthly, not "eventually."

Why spreadsheets break on multi-currency

Almost every group bill-split eventually gets attempted in a spreadsheet, and multi-currency is the feature that finally breaks it.

The rate goes stale silently. You paste in a rate the day you build the sheet. Three weeks later half the group settles, using the same cell, but that rate no longer matches either the bill date or today. Nobody notices until the numbers don't reconcile.

"Whose currency is primary" becomes a fight. A sheet forces one column currency. The person whose currency isn't primary is always reading a converted number and always slightly suspicious of it, because they can't see the source rate or when it was captured.

Reproducibility is gone. Open the sheet six months later and the live-rate formulas (if you used them) show completely different numbers than what people actually paid. There's no record of the rate at the time, so you can't audit an old bill.

Locking the rate into the bill record fixes all three: the rate is captured once at the bill date, stored with the bill, shown to everyone in their own currency, and never silently re-fetched. Reopen a bill from last year and it reads exactly what people settled. That auditability, not fancier math, is the real reason a purpose-built tool beats a sheet here.