Spreadsheet vs school management software: where the spreadsheet actually breaks
A student-records spreadsheet fails in three places: pack balances, payment reconciliation and shared editing. Here is exactly where, and who it still suits.
A spreadsheet for student records does not break because of row count — it breaks in three specific places: class-pack balances drift from reality, matching "who paid" to attendance turns into manual column-hunting, and editing by more than one staff member starts corrupting formulas. Below is where each of these actually happens, and who can keep using a spreadsheet for years without a problem.
Where it breaks #1: the class-pack balance formula
A pack is simple in principle: a student pays for N lessons, each lesson held subtracts one. In a spreadsheet that is usually a formula like "purchased minus held", and it works exactly until the first exception.
Exceptions happen constantly — a lesson moved to another date, a cancellation for a sick teacher, one student in a pair swapped for another. Each one has to be entered by hand, and whoever enters a correction at the end of a long day will eventually put a number in the wrong row.
The usual outcome: a student arrives certain they have three lessons left, and the real number is zero. Working out whose entry was wrong is not a good thing to be doing in front of a parent.
Worked example. Say a student buys a pack of 8 lessons. After the fifth
lesson, an administrator inserts a row above the tally by mistake, and a
formula like =8-COUNTIF(...) starts counting from the wrong starting cell.
Nothing looks different — the balance column still shows an ordinary-looking
integer. The error surfaces only once the balance disagrees with what the
student or parent remembers, and that can happen at the very next lesson or
six weeks later.
Where it breaks #2: matching payments to attendance
The second failure is not in the spreadsheet itself but in the fact that payment and attendance live in different places. Money arrives by card or bank transfer and shows up in a bank statement; attendance is marked separately in the schedule.
Reconciling the two by hand once a month is manageable with fifteen students. With fifty, reconciliation eats an evening, and there is almost always one or two cases of "paid but not marked" or "marked but no payment visible" — and nobody can tell who is right without digging through old messages.
Frequent consequences of manual reconciliation:
- a missed payment goes unnoticed for weeks;
- a parent gets reminded twice about a payment that already went through;
- teacher payroll gets calculated from the wrong attendance numbers.
Worked example. Say a school of 40 students accepts payment three ways — card transfer, cash at the front desk, and a payment link. Each method gets logged differently: transfers get copied from a bank notification, cash gets written down from memory at the end of the day, the link gets checked against an email from the payment provider. Three separate sources will almost certainly disagree on at least a couple of rows every month.
Where it breaks #3: more than one person editing
While one person maintains the spreadsheet, the risk is limited to their own typos. As soon as two people get access — a front-desk administrator and a teacher, say — editing conflicts start.
In Excel that is a literal file lock: one person has it open for editing, the other sees a read-only copy and edits a version nobody later merges back. In Google Sheets there is no lock, but the same problem shows up differently — edits happen simultaneously, and one person unknowingly overwrites someone else's formula.
Neither case is a bug in the tool. Excel and Google Sheets both do exactly what they were built for — storing and calculating data for one person at a time, with manual reconciliation if you choose to share it.
Shared access has a quieter side too: who sees what. On a shared sheet, an administrator and a teacher usually look at the same tab in full, including the contacts and payments of every student in the school, not only their own. A separate tab per role is rarely maintained — keeping several copies in sync is too much overhead.
Who a spreadsheet is genuinely fine for
The honest answer: a tutor with three to five students manages fine with a spreadsheet, and sometimes a notebook. At that count, the schedule fits in one person's head, and the sheet exists more for history than for control.
The conversation about switching tools usually starts not at a specific student count but at one of three events:
- a second staff member needs access to the same data;
- reconciling payments by hand has grown from minutes to hours;
- the school introduces class packs, and tracking balances, reschedules and freezes makes formulas that used to work suddenly unreliable.
If none of the three applies to your school, switching tools is probably premature.
What gets lost quietly: history and the links between data
A separate problem is structural, not arithmetic. A "Students" tab, a "Payments" tab and a "Schedule" tab are connected in the head of whoever maintains them — not in the file itself. When that person goes on leave or leaves the job, the connection leaves with them.
Dedicated software works the other way around: a student record links to their pack, their payments, their attendance and their messages as one object, not a name match across separate tabs. A change in one place shows up everywhere else immediately.
The same applies to change history — who adjusted a balance, who marked a payment, who moved a lesson. In a spreadsheet that history either does not exist or lives in a separate "Log" tab nobody checks until the first dispute.
Google Sheets does keep version history, and at first glance that looks like it solves this. In practice version history shows that a cell changed, not why — and "why" is exactly the question a parent asks when they disagree with a balance.
Signs a spreadsheet has stopped keeping up
Five signs, none critical alone, but together a reliable indicator.
| Sign | What it means in practice |
|---|---|
| A pack-balance dispute happens weekly or more | The formula drifts faster than anyone corrects it |
| Payment reconciliation takes over an hour | Payment and attendance data are not linked |
| Two people edit the same file at once | Shared access creates conflict, not convenience |
| A new hire cannot follow the tab structure | The logic only ever lived in the previous owner's head |
| Change history cannot be reconstructed | A dispute has nothing to check against but memory |
Spreadsheet vs dedicated software: what literally changes
The difference is not visual polish — it is which actions happen automatically and which stay on a person.
| Action | Spreadsheet | Dedicated software |
|---|---|---|
| Recalculating a pack balance after a lesson | Manual formula edit | Happens automatically when the lesson is marked held |
| Linking a payment to a student | Name match across tabs | Payment attached to the student record |
| Role-based access (admin, teacher) | One shared tab or manual copies | Configured once |
| Balance change history | Not kept, or a separate log | Part of the student record |
| Several people working at once | File lock or edit conflicts | The normal case |
How to migrate without losing data
- Clean the sheet before exporting. Remove long-departed students and merge duplicates — otherwise the new system inherits every old mistake as current fact.
- Match the field set. Usually name, contact, status, start date and current pack balance; everything else can be added later.
- Migrate active students first. You do not need three years of archive on day one — start with whoever is actually attending now.
- Keep the sheet read-only for a month. That is insurance in case a field got missed, not a reason to run two systems in parallel.
Who this doesn't fit
None of the above is a reason to abandon a spreadsheet that is genuinely working. It stays the right tool if you teach alone, keep a handful of students, and have never had a balance dispute you couldn't resolve from memory. Switching tools before that point mostly buys implementation time you didn't need to spend.
A note on where UniMe fits
We publish this journal, so here is the position stated plainly.
UniMe keeps a student's pack, payments, activity history and messages as one linked record — a kanban pipeline, tags and an event history in one place instead of separate tabs. A pack balance and a charge preview are shown before confirmation, not recalculated by hand after the lesson.
Where it will not help: UniMe is not a bookkeeping or tax-accounting tool — a school still needs a separate ledger or accountant for that. And moving to any dedicated system does not fix a bad habit on its own; if a school logs payments "whenever someone remembers" rather than when the money arrives, the same confusion follows into the new interface.
How to actually decide
- Check how many of the five warning signs above match your school today.
- If class packs are involved, read how balances, expirations and freezes are meant to work in class packs and credits before you assume a spreadsheet formula covers it.
- If a demo is on the table, see what to actually ask in choosing school management software.
- Export first, migrate active students first, and keep the old sheet read-only for a month rather than running two systems side by side.
Reviewed September 2026.