Why your split doesn't add up, and how rounding should work

The intuitive fix is to round each person's share to the nearest penny. £33.333… becomes £33.33, and everyone pays that. Except three lots of £33.33 is £99.99, and a penny has vanished. The person who paid the bill is a penny short.

Rounding up instead produces £100.02 and invents two pennies that nobody owes. Rounding to nearest, which is what most naive implementations do, produces whichever of these happens to fall out of the arithmetic — so the error is not even consistent.

A penny sounds trivial. It is not trivial when the same flat splits rent, council tax, broadband and energy every month for two years, and every one of those splits leaks a unit in the same direction.

The fix is to stop rounding each share independently and instead allocate whole units. Work in the smallest unit of the currency — pennies, paise, cents — and give each person the whole number of units they are unambiguously owed. Then distribute whatever is left over, one unit at a time, to whoever was closest to earning another one.

For £100 across three people: 10,000 pennies divided by three is 3,333 pennies each with one penny remaining. Everyone gets £33.33, and the single remaining penny goes to one person, who pays £33.34. The shares now sum to exactly £100.00.

This is called the largest-remainder method, and it has the property that matters most: the total is always preserved exactly, for any amount and any number of people.

There is a second, larger bug hiding underneath the rounding question, and it affects software that appears to be working fine.

Computers store decimal numbers in binary. Some decimals have no exact binary representation, in the same way that one third has no exact decimal representation. 0.1 is one of them. In almost every programming language, 0.1 + 0.2 does not equal 0.3 — it equals 0.30000000000000004.

Store money as decimal numbers and these tiny errors accumulate silently through every addition, every split and every balance calculation. They are invisible in a single transaction and clearly visible in a balance built from six hundred of them.

The fix is to never store money as a decimal at all. Store it as a whole number of minor units — £33.34 is the integer 3334 — and do all arithmetic in integers. Integers are exact. There is no drift because there is no approximation.

A related assumption catches out a lot of otherwise careful software: that a currency's minor unit is always one hundredth of the major unit.

The Japanese yen has no minor unit at all. ¥100 is one hundred yen, not 1.00 of something. The Kuwaiti dinar, Bahraini dinar and Omani rial have three decimal places, so their minor unit is one thousandth. The Chilean peso has none; the Tunisian dinar has three.

Software that hardcodes 'multiply by 100' will produce amounts that are wrong by a factor of 100 or 1,000 in those currencies. On a multi-currency trip, that is not a rounding error — it is a completely wrong number.

You can test any expense-splitting tool in about thirty seconds, and it is worth doing before you trust one with two years of household bills.

Enter a bill of 100 in your currency and split it between three people. Then add up the three shares it gives you. If they do not come to exactly 100, the tool is losing money on every uneven split you will ever make with it.

If it does add up, check the second thing: does it tell you who is carrying the extra unit? A tool that gets the arithmetic right but hides the asymmetry is fine. One that shows it is telling you it was built by someone who thought about this properly.