When a spreadsheet stops being enough
Not when it gets big. A spreadsheet stops being enough at one of five operational breakpoints: two people need to change it at once, it exists once per branch, you need to know who changed a number, the same customer is spelled four ways, or something downstream depends on it being current. Hit none of those and the sheet is fine. Hit one and fix that one thing.
Is the spreadsheet actually the problem?
Usually not. In most businesses that think they have outgrown Excel, the spreadsheet is doing exactly what it was asked to do, and the thing that has broken is the process feeding it. Replacing the sheet without fixing the process gives you the same mess in a more expensive container, and now nobody knows how to change it.
I think most software evaluations in this size band start about two years before they should and get pointed at the wrong problem. The question worth asking first is not which system to buy. It is which specific thing the sheet can no longer do.
Why doesn't the row limit matter?
Because you will never reach it. A spreadsheet in a distribution or retail operation fails for operational reasons long before it fails for technical ones, and the failure does not look like an error message. It looks like two versions of the same file, or a number nobody can explain.
That is why "we have too much data for Excel" is almost never the real reason a business moves. Something else broke first, and it is usually one of the five below.
Breakpoint one: two people need to change it at the same time
This is the most common one and the earliest. The moment a second person needs to edit the same sheet during the same working hours, you have a coordination problem that no amount of spreadsheet skill fixes.
Shared cloud sheets solve the technical half. They do not solve the business half: who wins when two people change the same cell, what happens to the change nobody noticed, and how anyone finds out. If your team has a rule like "do not touch the sheet after four o'clock," that rule is the workaround, and it is costing you the hours the rule exists to protect.
Breakpoint two: the sheet exists once per branch
When each location keeps its own copy, you no longer have a record. You have several accounts of what happened, and a monthly argument about which is right. Head office consolidates them, finds they disagree, and spends two days reconciling before anyone can act on the number.
This one compounds faster than the others, because every new branch multiplies the reconciliation rather than adding to it. It is also the breakpoint most likely to be misdiagnosed as an inventory problem when it is a record-keeping problem.
Breakpoint three: you need to know who changed a number
The moment money or stock is involved, the question stops being what the number is and becomes who set it and when. A spreadsheet cannot answer that in any way you would want to rely on. Version history helps a developer and does not help a finance officer at month-end.
You have crossed this breakpoint the first time a discrepancy takes longer to investigate than it does to correct. That is the tell: the correction is five minutes, the investigation is a day and a half.
Breakpoint four: the same customer is spelled four ways
Free text is the quiet killer. When nothing enforces that a customer, an item or a unit is written the same way twice, every report becomes an act of interpretation, and two competent people produce two different totals from the same file.
Test it in ten minutes: sort your customer column and look for the same business appearing more than once. Then do it for item names, and for units of measure. If a case and a carton and a box are all in there meaning the same thing, your stock numbers have never been right and nobody has noticed because everyone corrects it in their head.
Breakpoint five: something downstream depends on it being current
A spreadsheet is a snapshot somebody maintains. That is fine until another process needs it to be true right now: a delivery decision, a credit hold, a price a salesperson quotes over the phone. At that point the gap between when the sheet was last updated and when it is being relied on becomes a real cost.
This is the breakpoint that turns a reporting inconvenience into a customer-facing failure, which is why it is the one worth acting on fastest even when the hours look smaller than the others.
Which breakpoint have you hit?
Most businesses hit one or two, not all five, and knowing which changes what you should do. Fixing the specific failure is nearly always cheaper and less disruptive than replacing everything, and it leaves you with something you understand.
- ·Two people editing at once: fix the process before the tool. Decide who owns the sheet and when it is written to.
- ·One sheet per branch: this needs a single record. It is the breakpoint most likely to justify real software.
- ·No audit trail: needed only where money or stock moves. Scope it there, not across the whole business.
- ·Inconsistent naming: fix the sheet, not the stack. Controlled lists solve most of it in an afternoon.
- ·Something depends on it being live: usually a small, specific system, not a platform.
What should you do before replacing anything?
Count first. Follow one transaction end to end and count how many times the same information gets typed, how many hours a month go into making two numbers agree, and how much of the process exists only in someone's head. Those counts tell you what the current arrangement actually costs, which is the only way to know whether a replacement is worth the disruption.
Then fix and document the process before automating any part of it. This order matters more than the tool choice. Automating a process nobody has written down does not remove the problem, it makes the same problem run faster and moves it somewhere you cannot see it.
A system that has been through that sequence can and usually should end up automated. One that has not will encode every workaround your team invented, permanently.
When is replacing it actually right?
When the failure is structural rather than procedural. One record that several locations must share, an audit trail you are legally or commercially required to produce, or a process that genuinely cannot wait for a person to update a file. Those are not spreadsheet problems and no amount of restructuring fixes them.
Everything else is worth trying to fix in place first. The businesses that regret buying software are almost never the ones that waited a few months too long. They are the ones that bought before they could say, in one sentence, what specifically the old way could not do.
Common questions
How many rows is too many for a spreadsheet?
The row count is almost never the reason a business moves. Operational limits arrive far earlier: shared editing, one copy per branch, no audit trail, inconsistent naming, and other processes depending on the file being current. If none of those apply, size alone is not a reason to change anything.
Is Google Sheets enough for multiple branches?
It solves simultaneous editing, which is the technical half of the problem. It does not decide who owns a number, enforce that an item is named the same way twice, or give you a usable audit trail. Those are the parts that actually break in a multi-branch operation.
Should we buy an ERP instead?
Only if the failure is structural: one record several locations must share, or an audit trail you are required to produce. Most businesses in this size band hit one or two specific breakpoints, and fixing those is cheaper, faster and less disruptive than replacing everything.
What if we already tried and the project failed?
That is common and it is usually a sign the process was never documented before the software arrived. The work worth doing first is the same either way: count what the current arrangement costs, then write down how it actually runs, including the exceptions.
Sources
- Parseur and QuestionPro, Manual Data Entry Report. Survey of 500 US professionals across operations, finance, admin, IT and customer support. Fielded July 2025, published 19 August 2026. Respondents reported over nine hours a week moving data between places.
If this is the problem you're sitting with, show us the task and we'll audit one workflow for free.
Show us the task