Excel holds 1,048,576 rows and 16,384 columns per sheet, and a company of twenty people will never fill that. The limits that cost you money show up far earlier. A spreadsheet cannot settle two people editing the same row, and it keeps no record of who changed a number.
The documented ceilings, and why they rarely apply to you
Microsoft publishes the hard numbers: 1,048,576 rows by 16,384 columns per worksheet, and 32,767 characters per cell. Those are the figures most pages quote, and for a business running quotes, stock or a client list they are beside the point. You hit a different wall long before.
One ceiling is worth knowing about, and it belongs to the old file format. Legacy .xls stops at 65,536 rows. In late September 2020, Public Health England was loading Covid test results into that format, and 15,841 positive cases went unreported between 25 September and 2 October, with up to 48,000 contacts traced too late, as The Register documented at the time. Nothing on screen flagged a problem. The file simply carried on without the extra rows.
So if you inherited a file created years ago, check its extension, because .xls fails quietly where .xlsx would keep going.
One file doing two different jobs
A spreadsheet calculates, and nothing beats it at that. You type a formula, change an assumption, and everything recalculates. For a forecast or a margin model there is no better tool, and no reason to move.
Trouble starts when the same file also becomes a register: the client list, current stock, open quotes, next week's schedule. That work is no longer calculation. The file now holds data that several people read and edit, and a spreadsheet was never built to decide which of two simultaneous edits should win.
With a list of prospects there is a definition problem on top, because two people rarely mean the same thing by "client to follow up", which is what a written lead scoring settles.
Open your own file and look at the tabs. There is usually one clean tab with formulas you trust, and three tabs where the team keeps adding rows. Those entry tabs are the problem, and the rest of this article is about them.
| What you see | What is happening | What fixes it |
|---|---|---|
| Two versions of the same file are in circulation | Everyone works on their own copy and nobody arbitrates | A single source, with write access granted per person |
| A figure is wrong and nobody knows since when | The workbook keeps no history of changes | A tool that timestamps every change and its author |
| The same data is typed into two tools | The two tools do not talk, so somebody retypes | A link between the two, or a single tool |
| One person understands the formulas | The business rule lives in a file instead of being written down | Rules written outside the file, and a second person who knows them |
None of those four failures gets solved by switching to a different spreadsheet.
How to tell your file has crossed over
Count how many people have added a row to the file in the past week. If the answer is zero or one, you have a working file and you can stop reading here.
If the answer is two or more, ask yourself three things:
- Does a copy of the file travel by email, or is there a "v3 final" somewhere?
- Does anyone invoice, order or schedule based on a row somebody else typed?
- Could you say today who changed the last figure of last month?
One uncomfortable answer out of three is enough to move the register out of the spreadsheet. Where it goes is the next question.
Three ways out, and how to choose
Keep the spreadsheet and add rules. With one person entering data, the spreadsheet is still the right tool, and what has to change is the discipline: one named owner, one entry point, everyone else reading a copy. Start here, because it costs a conversation rather than a budget.
Buy something off the shelf. Where your process looks like everybody else's (invoicing, payment reminders, support tickets, standard stock), an existing product does it better and cheaper than any development. Compare its monthly subscription against the hours your team spends retyping, rather than against the spreadsheet, which is free.
Have an internal tool built. This earns its place when your process is stable, genuinely unusual, and no product takes it without forcing you to work differently. It is the case we take on at Numinam, and also the one we rule out most often after an audit: if an existing product fits the process, building means paying to rewrite what already exists.
Coddy, our own product, runs in nine countries without a shared spreadsheet acting as the booking register. Bookings, payments and instruction emails move between connected tools, and a person steps in only on the cases that fall outside the pattern.
What a new tool will not fix
Moving the data does not create the discipline. Three things stay yours whatever you choose.
Ownership. With nobody accountable for the client list, the new tool inherits the spreadsheet's duplicates in a nicer interface. Put a name against each dataset before you migrate.
Double entry. It only disappears if the new tool talks to the ones you keep. One more disconnected tool adds a place to type instead of removing one, and that is the first thing to check before automating anything.
Your starting point. Write down two numbers before you switch: the weekly time the task takes today, and how many errors you correct per month. Without them you cannot say afterwards whether the change paid off, which is the whole point of taking a baseline measurement first.
Migration forces one more decision. Columns nobody has filled in for two years do not come across, which is tedious work, and this is the right moment for it.
Key takeaways
- Keep the spreadsheet for what it calculates. Move out the part where several people enter rows every week.
- The signal is not the row count, it is how many people write in the file in the same week. From two upwards, move the register out.
- Before commissioning any development, check that no existing product covers your process. If one does, building means paying to rewrite it.
- Put a name against each dataset before migrating, or the new tool inherits the spreadsheet's duplicates.
- Record time spent and errors corrected before you switch. It is the only way to say later whether the move paid off.
Not sure which of the three applies to you? We start from how one order actually moves through your business, from first contact to invoice, rather than from a list of your software: see how we build internal tools.
