Group Travel Expense Splitter
Introduction to shared-cost settlement on group trips
A shared holiday generates two quite different money problems, and most splitters only solve the easy one. The easy problem is allocation: given a pile of receipts, how much of the trip does each traveller actually owe? The hard problem is settlement: given that one person put the beach house on their card, another bought the groceries and a third paid nothing at all, which transfers should actually happen so that nobody is out of pocket and as little money as possible moves between accounts?
This calculator solves both. You enter the travellers, an optional weight for each one, and the list of expenses with who paid and who benefited. It computes a per-person fair share, subtracts what each person already paid, and turns the resulting net balances into a concrete payment plan: a short list of the form "Eli pays Ana 280.16". It works entirely in whole minor units of the currency you choose, so the shares always reconcile back to the exact amount spent, down to the last cent.
The settlement itself is a classic computing-science problem. Represent every traveller as a node carrying a signed balance and every payment as a directed arrow; the task is to find a transfer graph that zeroes every balance using few arrows and little money. Tom Verhoeff analysed exactly this problem in Settling Multiple Debts Efficiently and proved both the useful positive result and the discouraging negative one: the total amount transferred can be minimised by a simple greedy sweep, but minimising the number of transfers is NP-hard. This page implements the greedy sweep, reports the theoretical lower bound alongside it, and is explicit about which of the two guarantees it can actually make.
How to use the traveller, weight and expense fields
There are three inputs and one switch.
- Currency. The dropdown lists ISO 4217 currency codes together with the number of minor digits each currency has. Choosing US Dollar rounds to 2 decimals, Japanese Yen to 0 and Kuwaiti Dinar to 3. Every internal calculation is done in whole minor units of the currency you pick.
- Travellers. One person per line. A bare name gets a weight of 1. To give somebody a different share, add a pipe and the weight, for example
Cara | 2for a couple sharing one entry, orZoe | 0.5for a child counted as a half share. A comma also works as the separator. Names are matched case-insensitively and duplicate names are rejected. - Expenses. One receipt per line, in the order
payer | amount | description | who shared it. The first two fields are required. Leave the fourth field empty and the expense is split across the whole group; fill it with semicolon-separated names and the expense is split only among those people. Amounts may contain thousands separators and a currency symbol; both are ignored. - Equal shares switch. Ticking "split every expense equally, ignoring weights" recomputes the whole plan with all weights set to 1. It is the fastest way to see how much the weighting actually changes the outcome.
Press Calculate settlement, or simply edit any field, and the summary panel, the payment plan, the balance sheet, the balance chart and the method comparison all refresh together. Copy plan puts a plain-text settlement summary on the clipboard for a group chat, Download ledger (CSV) saves the full working, and Copy shareable link writes the entire scenario into the page address so a co-traveller can open exactly what you are looking at.
The settlement formula: weighted shares, integer quotas and net balances
The naive version of this calculator, and of most splitters on the web, computes a single number: the equal share for a trip total and travellers. That is correct only when everybody has an identical claim on every expense, which is almost never true on a real trip.
The general form allocates each expense separately. Let expense have amount and beneficiary set , and let traveller carry weight . The exact real-valued share is
Formula: s_i,e = A_e ⋅ w_i / (∑ j ∈ B_e w_j)
That number is almost never a whole number of cents, and this is where splitters go wrong. Money is not a real number; it is an integer count of minor units, and IEEE 754 binary64 arithmetic — what every browser uses for a plain JavaScript number — cannot represent most decimal fractions exactly. The calculator therefore converts every amount to minor units first. Writing for the amount in minor units and for the total weight of the beneficiaries, each traveller receives an integer quota
Formula: q_i = ⌊ (A ⋅ w_i) / W ⌋, r_i = A ⋅ w_i − q_i ⋅ W
and the shortfall is distributed one minor unit at a time to the travellers with the largest remainders , ties broken by list order. This is the method of largest remainders, the same rule Hamilton proposed for apportioning seats in the United States House of Representatives and which Balinski and Young analyse in Fair Representation. Because every remainder is strictly less than , the shortfall is always smaller than the number of beneficiaries, so nobody is ever charged more than one extra minor unit and the allocated shares sum to exactly.
Contrast that with rounding each share independently. Split one hundred dollars three ways and each share rounds to 33.33, so
Formula: 3 × 33.33 = 99.99 ≠ 100.00
and a cent has vanished from the ledger. The calculator prints exactly this comparison in its reconciliation line so you can see how large the drift would have been on your own numbers.
Summing the allocations gives what traveller owes, . Writing for what that person actually paid out, the net balance is
Formula: b_i = p_i − o_i, ∑ i b_i = 0
The zero-sum identity is not an approximation. Total payments and total allocations are both exactly the trip total in minor units, so their difference is exactly zero. If a splitter ever shows you balances that do not sum to zero, it has a rounding bug.
Settlement then works only on those balances. Let be the set of creditors with and the debtors. The greedy sweep repeatedly picks the largest creditor and the largest debtor and moves
Formula: t = min (max i ∈ C^+ b_i, − min j ∈ C^− b_j)
between them. Each step zeroes at least one balance, so the plan never needs more than payments for travellers. Every payment runs from a debtor to a creditor and never through an intermediary, so the total amount transferred is
Formula: Ω = ∑ b_i > 0 b_i = 1 / 2 ∑ i | b_i |
which Verhoeff proves is a lower bound on the weight of any valid transfer graph. That part of the answer is provably optimal. The number of payments is not: the only bound the greedy sweep is guaranteed to respect is
Formula: max (| C^+ |, | C^− |) ≤ k ≤ n − 1
where is the number of payments. The left-hand quantity is printed under the plan; when the plan hits it, the plan is optimal and the calculator says so.
Worked example: a five-person beach house with one double share
Five friends rent a beach house. Cara travels with her partner and takes a double share, so the weights are Ana 1, Ben 1, Cara 2, Dev 1, Eli 1, giving a total weight of 6. The receipts are these:
| Payer | Amount | Description | Shared by |
|---|---|---|---|
| Ana | 900.00 | Beach house, 3 nights | everyone |
| Ben | 120.00 | Fuel for the round trip | everyone |
| Cara | 361.00 | Groceries and shared meals | everyone |
| Dev | 180.00 | Beach equipment rental | everyone |
| Dev | 300.00 | Boat charter | Ana; Ben; Dev |
| Ana | 120.00 | Contingency float | everyone |
The trip total is 1,981.00. Five of the six receipts are whole-group costs totalling 1,681.00; the boat charter is shared by only three people. The groceries line is deliberately awkward: 361.00 over a total weight of 6 is 60.1666… per single share, so it cannot be split into whole cents evenly. Working in cents, each single share gets a quota of 6,016 and Cara gets 12,033, which leaves three cents unallocated. The largest-remainder rule hands those three cents to Ana, Ben and Dev — the first three of the four tied single shares in list order — producing 60.17, 60.17, 120.33, 60.17 and 60.16, a total of exactly 361.00. Rounding each share independently would have produced 60.17 four times plus 120.33, which is 361.01, a cent more than was ever spent.
Adding up the six allocations and comparing them with what each person actually put on their card gives the balance sheet:
| Traveller | Weight | Paid | Fair share | Net balance |
|---|---|---|---|---|
| Ana | 1 | 1,020.00 | 380.17 | +639.83 |
| Ben | 1 | 120.00 | 380.17 | −260.17 |
| Cara | 2 | 361.00 | 560.33 | −199.33 |
| Dev | 1 | 480.00 | 380.17 | +99.83 |
| Eli | 1 | 0.00 | 280.16 | −280.16 |
| Total | 6 | 1,981.00 | 1,981.00 | 0.00 |
Eli paid nothing, which is perfectly legal: Eli simply carries a balance equal to a full fair share and appears in the plan as a payer. There are two creditors and three debtors, so the lower bound on the number of payments is three. The greedy sweep produces four: Eli pays Ana 280.16, Ben pays Ana 260.17, Cara pays Dev 99.83, and Cara pays Ana 99.50. Those four payments move 739.66 in total, exactly the sum of the two positive balances, which is the provable minimum. Four payments is in fact optimal here as well — no subset of these five balances sums to zero, so the balances cannot be partitioned into two independently settling groups — but the greedy sweep cannot prove that, so the calculator reports the bound of three and leaves the claim open.
Interpreting the plan, the balance chart and the method comparison
The summary panel gives you the four numbers that matter in a group chat: what the trip cost, what a single share came to, how many payments are needed and how much money has to move. The balance sheet is the audit trail; if somebody disputes the plan, this is the table to look at, because every settlement figure is derived from the net balance column and nothing else.
The balance chart is a plain-text diverging bar chart. Debtors extend to the left of the axis, creditors to the right, and bar length is proportional to the size of the balance. It is deliberately monospaced text rather than a graphic so it can be pasted straight into a message. A single very long bar next to several short ones is the signature of the common situation where one person fronted almost everything; a symmetric chart with several bars on each side is the case where the greedy sweep is least likely to hit the theoretical minimum number of payments.
The method comparison table puts the plan next to the alternatives people actually use. "Reimburse every receipt directly" is what happens when a group settles line by line without netting; it is always correct and almost always absurd, because it generates one payment per beneficiary per receipt. "Single banker" is the scheme in which one person acts as a clearing house: everyone with a positive balance pays them, then they pay everyone with a negative balance. It is easy to explain and needs at most payments for people with non-zero balances, but it routes money through an intermediary, so the total transferred is generally larger. The table shows both costs for your own data so you can decide whether the simplicity is worth it.
Limitations and assumptions you should check before trusting the plan
- The transfer count is a heuristic, not an optimum. Minimising the number of payments is NP-hard by reduction from 3-Partition, so the calculator makes no optimality claim unless the plan happens to match the printed lower bound. Only the total amount moved is provably minimal.
- One currency at a time. Every amount is assumed to be in the selected currency. There is no exchange-rate model, so multi-currency trips must be converted to a common currency before entry, and the rate you choose — transaction date or trip average — is a decision the tool cannot make for you.
- Amounts must be positive. Zero and negative amounts are rejected. Refunds, deposit returns and cancelled bookings need a policy about who bears the loss, and encoding that as a negative expense would silently apply the wrong policy. Net the refund against the original receipt before entering it.
- Weights are a proxy, not a fairness theory. A weight of 2 says somebody consumes twice the resource, which is a reasonable model for a couple in one room. It is a poor model for income-based splitting, for a child who eats a third as much but occupies a full airline seat, or for someone who joined for two of five nights. Split those costs into separate expense lines with explicit beneficiary lists instead.
- Rounding is exact but not neutral. The largest-remainder rule guarantees the shares sum to the total; it does not guarantee that the same person is never the one who absorbs the extra cent. Over many expenses with the same tied weights, the first names in the list will absorb slightly more. On a real trip this is a few cents; if it matters, shuffle the traveller order between trips.
- Minor units follow ISO 4217, not local practice. The currency list uses the published minor-unit exponent, so Japanese Yen rounds to whole yen and Kuwaiti Dinar to three decimals. Some countries have withdrawn their smallest coins and round cash payments further at the till; the calculator models the accounting unit, not the coinage.
- Trust and enforcement are out of scope. The plan tells you the cheapest set of payments. It says nothing about who is likely to actually pay, and a plan that concentrates four incoming payments on one person may be worse in practice than a slightly more expensive plan that spreads the risk.
Questions travellers ask about splitting and settling
How does this splitter decide who pays whom?
The tool never settles expense by expense. It first works out what each traveller owes across every expense, subtracts that from what they actually paid, and keeps only the net balance for each person. Those balances sum to zero by construction, so the group is split into creditors and debtors and a greedy rule repeatedly moves money from the largest debtor to the largest creditor until every balance is zero. Because every payment runs from a debtor straight to a creditor, the total cash that changes hands equals the sum of the positive balances, which Verhoeff shows is the smallest total any settlement scheme can achieve.
Why do the individual shares always add up to the exact trip total?
Every amount is converted to whole minor units of the selected currency, cents rather than dollars, so the arithmetic never touches a binary floating point fraction. Each expense is then divided using integer quotas plus a largest remainder rule: everyone first receives the floor of their weighted quota, and the leftover minor units are handed out one at a time to the travellers with the largest fractional remainders. That guarantees the shares of an expense add back to the expense exactly. Rounding each share on its own does not: one hundred dollars split three ways gives three shares of 33.33 and loses a cent.
Is the settlement plan the smallest possible number of payments?
Not always, and the calculator says so. The greedy plan is guaranteed to need no more than n minus 1 payments for n travellers, and it is guaranteed to move the least possible amount of money. The number of payments, however, is only a heuristic result. Finding the true minimum number of payments is NP-hard, by reduction from the 3-Partition problem, so no fast method is known. The calculator prints the theoretical lower bound next to the plan, and when the plan matches that bound you know it cannot be beaten.
How do I handle a couple, a family, or an activity only some people joined?
Give each traveller a weight. A weight of 2 means that person carries a double share, which is the usual way to enter a couple or a parent paying for a child, and weights may be fractional, so 0.5 is a half share. For an activity that only part of the group joined, list the people who took part in the fourth field of the expense line, separated by semicolons. That expense is then divided only among the travellers named, still in proportion to their weights, while everything else stays a whole-group cost.
What happens if a payer is not on the traveller list, or someone paid nothing?
Both cases are handled explicitly. A payer who is not on the traveller list is rejected with a message naming the line and the unknown name, because a balance held outside the group can never be settled inside it. A traveller who paid nothing is perfectly valid: that person simply carries a negative balance equal to their fair share and appears in the settlement plan as someone who pays. Amounts of zero or less are rejected too, since a shared cost of nothing carries no information and a negative amount would need a refund rule this tool does not model.
Practical notes on running the ledger during a trip
The arithmetic is the small part of the job. What actually breaks group budgets is missing data, so agree on one collection point before you leave: a shared note, a group album of receipt photographs, or a single message thread where every purchase is posted the day it happens. Anything recorded three weeks later is a guess.
Record the payer and the beneficiaries at the moment of purchase rather than at the end. "Who was on the boat?" is easy on the pier and impossible in February. When part of the group splits off for an evening, that is a new expense line with an explicit beneficiary list, not a whole-group cost with an apology attached.
Decide in advance what happens to small items. Coffees, tips and parking meters can double the number of lines while changing the settlement by a few units of currency. A common rule is to ignore anything below a threshold everybody agrees to, on the understanding that these roughly cancel out. That is a social decision, not a mathematical one, and the calculator will faithfully split whatever you give it.
Finally, settle quickly. The balances the tool produces are exact on the day you compute them, and every week they sit unpaid they compete with rent, other trips and fading goodwill. Download the ledger, paste the plan into the group chat, and close the book.
Sources. The settlement model, the zero-sum balance identity, the proof that a debtor-to-creditor greedy sweep minimises the total amount transferred, the bound of at most N − 1 transfers and the lower bound of max(creditors, debtors) on the number of transfers all follow Tom Verhoeff, Settling Multiple Debts Efficiently: An Invitation to Computing Science, Informatics in Education 3(1):105–126, 2004, Eindhoven University of Technology (doi:10.15388/infedu.2004.08). The same paper establishes that minimising the number of transfers is NP-hard by reduction from 3-Partition, problem SP15 in M. R. Garey and D. S. Johnson, Computers and Intractability: A Guide to the Theory of NP-Completeness, W. H. Freeman, 1979. General treatment of greedy algorithms and of NP-completeness follows T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. Stein, Introduction to Algorithms, 4th edition, MIT Press, 2022. Currency minor-unit exponents are taken from the official ISO 4217 currency code list (Table A.1, List One, published 2026-01-01) maintained on behalf of ISO by SIX Group, the designated ISO 4217 Maintenance Agency (six-group.com, iso.org). The reason money must not be held in binary floating point is IEEE Std 754-2019, IEEE Standard for Floating-Point Arithmetic, IEEE (standards.ieee.org). The largest-remainder allocation rule is Hamilton's method of apportionment, analysed in M. L. Balinski and H. P. Young, Fair Representation: Meeting the Ideal of One Man, One Vote, Yale University Press, 1982 (2nd edition, Brookings Institution Press, 2001). Nothing on this page is financial or legal advice.
Arcade Mini-Game: Group Travel Expense Splitter Calibration Run
Use this quick arcade run to practise separating the ledger fields the splitter needs from the entry mistakes that break a settlement.
Start the game, then use your pointer or arrow keys to catch valid ledger fields and avoid entry mistakes.