The expense engine: splitting money without losing a paisa

Ask someone what a bill-splitting app does and they'll say "it divides the bill." That's the easy 20%. The hard 80% is doing it exactly, in integers, across four different ways people want to split, through edits and deletions and retries, so that months later every member's phone agrees to the paisa on who owes whom. The data-model chapter covered where this lives (paisa-as-bigint, ULIDs, the ledger tables); this chapter is the engine that runs on top — the math that turns a bill into splits, the projection that turns splits into balances, and the concurrency that keeps both honest when the ledger changes underneath you.

The governing rule, inherited from the data model and never once relaxed: money is integer minor units (paisa), and the split of any expense sums to exactly the total. Not approximately. Every algorithm below exists to make that true by construction.

Four ways to split, one invariant

People split bills in genuinely different ways, so Fable's @hisaab/money package exposes four split functions — and each is written so its outputs sum to the input, with the rounding handled honestly rather than swept under a float:

• Equal — splitEqual(₹100, 3). The naive 100/3 loses a paisa. Instead: integer-divide to get the base share (q = amount / n), take the remainder (r = amount % n), and hand the leftover r paisa out one each to the first r participants. splitEqual(10000, 3) → [3334, 3333, 3333]. Sum: exactly 10000. No paisa created, none lost.
• Exact — splitExact(₹100, [5000, 3000, 2000]). The user typed the amounts; the function's job is to validate, not compute — it throws unless the parts sum to the total. The database's splits-sum invariant, enforced at the door.
• Percent — splitPercent(₹100, [3333, 3333, 3334]). Note those aren't percentages — they're basis points (integer ten-thousandths). You cannot pass 33.33 as a percentage; you pass 3333 bp, and the function throws unless the basis points sum to exactly 10000. This is deliberate: percentages invite the float ("33.33% + 33.33% + 33.33% = 99.99%, where's the last paisa?"), while integer basis points make "the weights sum to exactly 100%" a checkable integer fact.
• Shares — splitShares(₹100, [2, 1, 1]). Split by integer weights — the first person covers half, the others a quarter each. Good for "I had the big meal."

Percent and shares both route through one proportional split with the largest-remainder method: distribute by integer division, then award the truncation leftovers to the participants whose fractional remainder was largest (ties broken by input order). It's the same rounding banks and electoral apportionment use, and it's what guarantees the invariant holds for weighted splits too — the leftover paisa go somewhere deterministic, never vanish. The whole package is generic over a currency-branded Minor<C> type, so the compiler refuses to add two currencies, and there is no floating-point number anywhere in the path.

Balances are a projection, not a number

Here's the decision that keeps Fable's ledger trustworthy over years: a balance is never stored as truth. An expense produces expense_splits (who owes) and expense_payers (who paid); a person's net position in a group is a pure function computed over those plus confirmed settlements:

net[user] = Σ paid − Σ owed
          − Σ confirmed settlements where user is payer
          + Σ confirmed settlements where user is recipient

That's the entire truth of "who's up and who's down," and it's derived — recomputed from the append-only ledger, never mutated in place. There's a group_balance_cache for fast reads, but it is explicitly a cache: recomputable at any time, invalidated on every write, and rebuilt from scratch nightly with a zero-drift assertion. This is the difference between an app that's still correct after two years and one that has slowly drifted into balances nobody can explain — storing a derived number as state is how Splitwise-likes rot, and Fable refuses to. (It's also a textbook read-cache: the derived value is expensive-ish to compute and read constantly, so cache it, but the ledger stays the source of truth.)

Simplifying debts: the fewest transfers that settle everyone

A four-person trip generates a tangle: A owes B, B owes C, C owes A, everyone owes the person who booked the hotel. Settling every raw edge means a dozen transfers. Debt simplification collapses that to the minimum: net everyone out, then match who's down against who's up with as few transfers as possible.

Fable's greedyPairwise does it deterministically. Take the net-per-user vector, split it into creditors (positive net, sorted descending) and debtors (negative net, sorted by magnitude), then repeatedly match the largest debtor against the largest creditor, emitting a transfer for the smaller of the two remaining amounts and advancing whichever hits zero:

while creditors and debtors remain:
  amount = min(current creditor's remaining, current debtor's remaining)
  emit edge (debtor → creditor, amount)
  subtract from both; advance whichever reached zero

It's greedy and it's deterministic (ties broken by input order), which matters more than it looks: two devices computing the simplified debts must produce the identical set of transfers, or users would see different "pay this person" instructions. The result is the fewest edges that zero out every account — A→C directly instead of A→B→C→A. And critically, the greedy simplified edges and the raw pairwise edges are two valid decompositions of the same net vector — a fact that, as the settlement chapter's war story shows, you must respect when validating a payment, or you reject valid settlements offered by the other decomposition.

The hard part: editing and deleting a settled-against expense

Adding an expense is easy. Deleting one is where the engine meets the locks lesson head-on, because an expense doesn't live in isolation — its debts may already have been settled. Delete an expense whose debt someone just paid, and you have to reconcile a payment against a debt that no longer exists.

Expenses are soft-deleted (a deletedAt timestamp and a version increment, never a hard DELETE) so history and the ledger stay auditable, and the balance cache for every affected pair is invalidated. But the ordering of operations is the subtle, correctness-critical part — which is the war story.

Interview takeaway

For any "design a bill-splitter / expense tracker / ledger" prompt:

• "Splits are computed in integer minor units with a largest-remainder method, so the parts always sum to the total." Show splitEqual(100, 3) → [34, 33, 33] and name largest-remainder — it proves you know rounding loses money if you're careless.
• "Percentages are stored as integer basis points that must sum to 10,000." This one sentence signals you've seen "three 33.33%s don't add to 100%" bite.
• "Balances are a projection over an append-only ledger, cached but never stored as truth, with a drift assertion." The single most important correctness statement about a ledger.
• "Debt simplification is a deterministic greedy match of creditors against debtors." Stress deterministic — every device must compute the same transfers.
• "Cross-subsystem operations like deleting a settled-against expense serialize on a shared lock, held around the check, not just the write." This is the highest-signal point — it shows you understand check-then-act races span services, not just rows.

The theme of the whole Fable, Deconstructed series holds here: the arithmetic was never the hard part. Getting the last paisa right under weird splits, keeping balances derived rather than stored, and closing the race where a delete and a confirmation collide — that's the engine. The money actually moving between people is the settlement flow; the schema underneath is the data model.