Who's paid, who's in, who's owed: why the spreadsheet stops working

Almost every syndicate starts in a spreadsheet, and for a while a spreadsheet is exactly right. A dozen names, a dozen balances, one column per week. You can see the whole thing at once.

The trouble is not that spreadsheets are bad. It is that a syndicate slowly turns into a different kind of problem than the one a spreadsheet solves.

A balance is not a history

A spreadsheet cell holds a number. When something happens, you change the number.

That is the whole issue. The cell tells you Jan’s balance is $18. It does not tell you that it was $22 last month, that $6 came off for two draws, that $2 was refunded because she was away, and that you corrected a typo in August. When you overwrite the cell, that history is not archived anywhere. It simply stops existing.

Which is fine until somebody asks a question about the past — and every question in a syndicate is about the past. Was I in the draw on the 14th? Did my twenty go in before or after that week? Why is my total different from what you told me in June?

An append-only ledger answers those by construction. Nothing is edited; every movement is a new line with a date, an amount, a reason and the name of whoever entered it. A correction is another line, not a quiet overwrite. The balance is simply the sum of the lines, so the number and the explanation for the number can never disagree.

This is not bookkeeping pedantry. It is the entire difference between “trust me, it’s $18” and “here is how it became $18”.

Membership changes, and draws don’t know

The second thing a spreadsheet cannot easily do is remember who was in.

Members join. Members drift off. Someone pauses for six weeks over winter. And every ticket belongs to the people who were in it on the day it was played — not the people on today’s list.

So when a ticket bought in July wins in July but is reconciled in September, the correct division is by the July membership. In a spreadsheet, the July membership is gone: the sheet only has today’s names, and reconstructing who was in requires reading back through the columns and hoping nobody was added without a note.

The fix is to snapshot the membership onto the draw itself, at the moment the draw is created. Then the question “who was in?” is not a reconstruction. It is a stored fact.

Nobody else can see it

The third limitation is the one people notice last and regret most.

The spreadsheet lives on the organiser’s laptop. The members have never seen it. Their entire knowledge of the syndicate’s finances is whatever the organiser tells them, usually in a group chat, usually in reply to a question.

That arrangement puts an unreasonable weight on one person’s word — and, as we’ve written about elsewhere, it is exactly the arrangement that goes badly wrong when something valuable happens. A record only the organiser can see is very nearly no record at all, because its credibility rests on the same thing it is supposed to be evidence for.

Sharing the spreadsheet does not really fix it, either. Now everyone can see everyone’s finances, one person can break the formulas, and you have swapped an accountability problem for a privacy problem.

The middle path is that each member gets their own figures, automatically, every time something happens. Not a shared file — a statement that arrives. It shows them their own balances and how any win was divided, without handing everybody a roster of who else is in the syndicate.

The failure modes, specifically

If you want to know whether your spreadsheet is close to breaking, these are the signs:

• There are two versions of it and you are not certain which is current.
• Someone’s total is out by a few dollars and you have given up on finding out why.
• You keep a second list — chat messages, a notebook, your memory — of things the sheet doesn’t capture.
• You cannot answer “who was in the draw on the 14th?” without reading back through columns.
• You are the only person who has ever seen it.

None of these are catastrophic on their own. All of them are the same underlying fault: the sheet records state, and a syndicate is made of events.

What to use instead

Something that records the events and derives the state from them:

• A ledger, not a cell. Every movement kept, with a reason and an author. Corrections as entries.
• Draws that own their membership. Who was in, fixed at the time, not inferred later.
• Splitting done by the system. Both directions — the ticket cost out, the winnings in — calculated on the members attached to that draw.
• Statements that arrive. Each member sees their own position without having to ask, and without seeing anybody else’s.

That is what Lotto Syndicate Manager is: not a nicer spreadsheet, but a different shape of record. The balances are still there, at the top of the screen, where you have always looked for them. What changed is that underneath each one there is now an answer to “how?”.

---

Moving across from a spreadsheet? Opening balances are entered as ledger entries, so the audit trail starts from a known figure rather than appearing out of nowhere. Start free for three months.