Splitting a bill so it actually reconciles

Why I built it

I was the one with the calculator.

Every trip ended the same way. Somebody covered the hotel, somebody else paid for dinner, one person left a day early, another was not there for the cab at all, and three days later the group chat turned into an investigation: screenshots, half-remembered amounts, and forty messages to answer one question, which is how much do I owe and to whom. I ended up being the person who sat down with a spreadsheet and worked it out, and I got it wrong often enough to know the problem was not arithmetic. It was that nobody could see how the number was reached, so nobody could check it.

I tried the apps that exist for this. They split evenly by default, which is almost never what happened at the table, and they hand you a list of who owes whom that is longer than the group is willing to actually pay. So I built the one I wanted: log the expense while it happens, include only the people who were part of it, and settle the whole trip in as few transfers as possible.

That is the product. What follows is the part that decides whether anyone can trust it.

The problem behind the problem

Expense splitters are easy to build badly. Two things go wrong, and both are the kind of wrong that only shows up after people have trusted the number.

Floating point money. Store rupees as a float, split three ways, and you get 0.3333 repeating. Sum the shares back up and they no longer equal the bill. The error is one paisa, which sounds like nothing until the group settles and the totals visibly disagree with what everyone paid.

Naive settlement. If four people owe four other people, the obvious implementation produces a payment for every debt. That is up to twelve transfers to settle one dinner, and nobody does twelve transfers.

Approach

Money is an integer. Every amount is stored in whole paise. Nothing in the system holds a fractional currency value at any point, so there is no rounding to accumulate.

Remainders are distributed, not dropped. When a split does not divide evenly, the leftover paise are handed out one at a time rather than rounded away. Three people splitting 100 paise get 34, 33 and 33. The shares sum to the bill exactly, every time, by construction rather than by luck.

Settlement is minimised. Rather than settling every individual debt, the app computes each person's net position and then finds a small set of payments that clears the whole group. The output is the short list of transfers people will actually make.

Offline first. Writes land in the browser immediately and sync to Postgres afterwards. The moment a bill gets split is usually a restaurant with bad signal, so waiting on a round trip before showing the result is the wrong trade.

The database enforces the rules. Row-level security and database-side constraints do the access control, rather than trusting the client to only ask for what it should. A bug in the front end cannot expose another group's ledger.