Splitting the Cost of a Trip Between Friends

The balance sheet, which the tool gets right

You give it two lists: travellers, one name per line, and expenses in the form name, amount, description. Anyone who pays an expense is added to the group automatically, which is convenient and occasionally surprising. It totals what each person paid, works out each person's share, and shows the difference — positive means they are owed, negative means they owe. Nothing about who bought what survives into the answer; only the totals matter.

The shares are allocated to the cent by the largest-remainder method, which is the detail most splitters get wrong. Divide 100 three ways and the honest floor is 33.33 each, which sums to 99.99 under a heading that says 100. This tool gives the leftover cent to the row with the largest discarded fraction, so the display reads 33.34, 33.33, 33.33 and the column adds up. One inconsistency survives it: the big "Fair share" figure at the top is the plain average, unrounded, while the per-person rows carry the allocated amounts. On three people and 100 the headline says 33.33 and the first row says 33.34. Both are right; they are answering slightly different questions.

Settlement is a different computation from addition

A balance sheet tells five people that three are owed money and two owe it. It does not tell anyone what to do, and the gap between the two is where a group trip actually goes wrong: nobody wants to send four payments, and nobody wants to be the person tracking whether the fourth arrived. Fewer transfers is not a cosmetic preference. It is the difference between settling on the drive home and a group chat that is still open in November.

The tool's method is the obvious one: settle the largest debtor against the largest creditor, repeat until everyone is at zero. It is fast, it always terminates, and it never needs more than one transfer fewer than the number of people. What it is not is minimal. On the five balances above it produces four transfers where three would do, and the reason is structural rather than a bug: the fewest transfers come from splitting the group into as many zero-sum subsets as possible — here, Cleo's −250 exactly matches Ana's +150 plus Ben's +100, and Eli's −200 exactly matches Dan's +200 — and greedily taking the largest pair first destroys those matches before it can see them.

Deciding whether a set of numbers can be split into parts that each sum to zero is a version of the subset-sum problem, which is NP-complete, so no fast method finds the true minimum in general. The file that computes the settlement says exactly this in its own comment — greedy, not guaranteed minimal, bounded by n − 1 — and is right to. What is wrong is the sentence the visitor reads under the result, which promises "the smallest set of transfers that clears everyone". Nobody notices, because the tool's three built-in examples are all three-person trips with one creditor, where greedy and optimal happen to agree. It takes five people and a coincidence in the numbers before the gap opens.

Uneven shares: the couple, the excursion, the driver

An equal split is only fair when the trip was equal, and it usually was not. Switch the tool to weighted mode and you can give each person a number: two for a couple sharing a room, one for everyone else, three for the family of three, zero for the friend who came for a day and paid their own way. Weights are entered as name and weight, one per line, and anyone you do not list gets a one. The shares come out proportional and still add exactly to the total.

One structural limit is worth knowing before you rely on it: a weight applies to the whole trip, not to a single expense. That covers the couple perfectly, because a couple is heavier on everything. It does not cover the person who skipped one excursion, because their weight would have to be one on the accommodation and zero on that one line. There are two honest ways round it. Run the excursion as its own separate split with only the people who went, and settle the two results together. Or, if the excursion is a small part of the total, pick a fractional weight that reproduces the right share and say out loud that it is an approximation, because a weight of 0.9 looks precise and is not.

The awkwardness comes from ambiguity, not from money

Nobody falls out over $40. They fall out over not knowing whether the $40 was expected of them, and over the fortnight it took to find out. An unsettled group trip generates a low, continuous social cost: three people privately keeping score, one person deciding it is not worth mentioning, and a shared understanding that the subject is now slightly delicate. None of that is about the amount. It is about the absence of a rule everyone agreed to in advance.

So decide the rule before you leave, not after you return, and make it a rule about categories rather than about people. Accommodation split by bed, transport split by seat, food split evenly, anything optional paid by whoever goes. Write it in the group chat once. Whatever you pick will be imperfect; being agreed in advance is worth more than being exactly right, because the argument you avoid is not about the number, it is about whether the number was ever the deal. The splitter's job starts at the end of that process, not in place of it: it turns an agreement you already have into a list of payments.

The four ways a line silently disappears

The expense box is plain text, and plain text has no validation. An expense written without the vertical bars between the name, the amount and the description is skipped entirely: no error, no highlight, just a total that is quietly too low. A name typed with different capitalisation becomes a second person, so "Ana" and "ana" split the group into six travellers instead of five, each with half the share. And a thousands separator wrecks a large line, because the amount is read by taking the first number it finds with a comma treated as a decimal point — a hotel bill typed as 1.200 or 1,200 is read as 1.2, and typed with a space, as 1.

The check that catches all four takes five seconds: the total on screen should match the sum you already have in your head, and the number of rows in the table should equal the number of people who went. If either is off, one of the four is the reason. Type amounts bare, with a dot or a comma for the decimal and nothing else, and copy names rather than retyping them.

Frequently asked questions

Does the tool really find the smallest number of transfers?

No, although the note under the result says so. The method is greedy: settle the largest debtor against the largest creditor and repeat. On balances of +$150, +$100, −$250, +$200 and −$200 it returns four transfers where three are enough. The claim is contradicted by the tool's own source, which describes the method as greedy and the true minimum as NP-hard. What is true is the note's second sentence: the result never needs more than one transfer fewer than the number of people. If four transfers is one too many for your group, look for a debtor whose balance exactly matches one or two creditors and pair them by hand.

Do the individual shares add up exactly to the total?

Yes, and that is the part of the tool worth praising. Shares are allocated to the cent by the largest-remainder method, so three people splitting $100 see $33.34, $33.33 and $33.33, and the column adds up to exactly $100 instead of $99.99. One display inconsistency remains: the large "Fair share" figure at the top is the plain unrounded average and is only shown in equal mode, so on that example it reads $33.33 while the first row reads $33.34.

How do I handle a couple sharing a room, or someone who skipped an excursion?

The couple is easy: switch to weighted mode and give them a weight of two while everyone else stays at one. The excursion is not, because a weight applies to the whole trip rather than to a single expense. Either run that excursion as a separate split containing only the people who went and settle both results together, or pick a fractional weight that reproduces the right share and say plainly that it is an approximation. A weight of zero is also allowed, and gives that person a share of zero on everything — right for someone who never came, wrong for someone who missed one afternoon.

An expense I typed is missing from the total. What happened?

Almost certainly the vertical bars. An expense line needs at least a name and an amount separated by one, and a line without it is skipped with no error at all. Two other traps produce a wrong total rather than a missing one: a name typed with different capitalisation becomes a separate traveller, and a thousands separator is read as a decimal point, so 1.200 and 1,200 both become 1.2 and a figure typed with a space becomes 1. Check that the total matches the sum you expect and that the table has one row per person.

Does it matter who paid for what during the trip?

Not to the balances, and that is worth saying out loud to the group. Only the total each person paid enters the calculation; the descriptions are for you, not for the arithmetic. Whether Ana paid for the apartment and Dan for the car, or the other way round, the balances are identical. What does change is the settlement: the same total spent, distributed differently between payers, can need three transfers or four. So the most useful thing one person can do during a trip is not to pay for everything, but to pay in a way that leaves round, matching balances behind.