Every other split app starts you at an empty form: merchant, amount, date, who, how. Lumino Split starts at the charge already sitting on your card — so splitting dinner is picking who was there. And what comes back counts as money you have, not a number stranded in a second app.
Five fields you type from memory or a photo of the receipt, every single time. Mistype the amount and the balance is wrong forever.
All five arrive from the account you already connected. Nothing to type, nothing to mistype. What is left is picking who was there.
This receipt is not a picture of the product. It runs the same allocator the app, the website and the server run — ported line for line, pinned to all three by a shared file of golden test vectors. Change the method, add a person, and the figures you get here are the figures you would get in Lumino, down to which person catches the odd cent.
The leftover cents go to you and Maya.
A standalone split app can tell you that four people owe you $61.58. It cannot tell you what that does to anything else, because it does not know anything else. Lumino does. The balance sits in your net worth beside your accounts and investments, and when someone pays you back — cash, Venmo, Zelle, UPI, bank transfer — the balance closes.
You put a $300 group dinner on your card. Untouched, that is a $300 hole in your dining budget for a meal that cost you $100. Split it three ways and the budget counts what it actually cost you.
Changing a number a user already reads is the riskiest thing this feature does, so it is the last thing that ships and the easiest thing to undo. It is a read-side lookup: the stored transaction is never rewritten.
If the lookup fails, returns nothing, or the user prefers whole amounts, the number falls back to exactly today's behaviour. Net worth and cash flow are deliberately left alone — a split changes what an expense cost you, not what you own.
Every amount in Split is an integer count of cents. Floats exist only at the edge where the bank feed hands us a number. And nothing is ever updated in place: the ledger has no update method, on purpose. Editing an expense writes a reversal and reposts. Deleting one writes a reversal. Balances are derived live from the rows, never cached.
That sounds pedantic until the third time someone edits a dinner from four people to five a week later. With mutable balances, one missed recalculation and the group quietly disagrees about money forever. With reversal rows, the history stays readable and the arithmetic stays checkable — you can always add the column up.
Swipe the table for the amounts →| Entry | What happened | Party | Cents |
|---|---|---|---|
| #1841 | Dinner posted — split 3 ways | Maya | +6158 |
| #1842 | Dinner posted — split 3 ways | Devin | +6157 |
| #1903 | Edited to 4 people — reversal | Maya | −6158 |
| #1904 | Edited to 4 people — reversal | Devin | −6157 |
| #1905 | Edited to 4 people — repost | Maya | +4619 |
| #1906 | Edited to 4 people — repost | Devin | +4618 |
| #2077 | Maya settled up — Venmo | Maya | −4619 |
A settlement is written creditor to debtor, so only one place in the codebase has to think about signs. Everywhere else, callers just say who paid whom.
After a weekend away, a group of four owes in six directions at once. Simplify debts nets it all down to the fewest transfers that clear the board. Nobody's net position changes by a cent — there is just far less money moving. Flip the switch.
Split shipped as a full section, not a button buried in a transaction detail screen. Web and mobile were built in parallel against the same API, so neither platform is the one that gets the feature six months later.
Being connected to real accounts means Split can see when something changes. It also means a wrong guess arrives as a push notification about someone's money, so the three signals are held to very different standards.
You split the tab while it was still pending at $180. It posts at $184.73 with the tip. Split compares the stored snapshot to the new value and tells everyone before anybody pays the wrong number. This is a correctness feature wearing an intelligence feature's clothes, so it notifies immediately.
A recurring split you set up yourself fires when the charge lands, carries a visible "auto-created" badge and a 24-hour undo. If the amount comes in more than 25% outside its usual range, it downgrades itself to a suggestion instead of acting.
A $61.58 transfer lands two days after a $61.58 balance. Probably Maya. Probably is why this one shipped dark: it scored real deposits into a log and sent nothing at all until at least 4 in 5 of its guesses were right on review. Even now it only ever suggests — settling is always your tap.
Suggest, never auto-confirm. A dismissed suggestion penalises that pairing on every future score, and nothing lingers past fourteen days — so the inbox never becomes a graveyard.
Split is measured against Splitwise, which has had fifteen years to grow. Rather than ship thin versions of everything it does, v1 went deep on the part that only an app with a bank connection can do at all, and left the rest visible on the list instead of half-built.
Settlement is one-sided by design, not by omission: people added by email have no account, so there is nobody on the other end to confirm anything. Two settlement models for one action is exactly how balances start to drift, so there is one — the person recording it writes the row, and where both people are Lumino users the other one is told and can argue in the comments.
Lumino Split is our own work — bank-feed ingestion, a cent-exact ledger, three clients kept in agreement by shared test vectors, and an intelligence layer that had to earn the right to send a notification. If you are building something with the same standards, we should talk.
Start a conversation