A consultant is supposed to tell you that you have outgrown your spreadsheet. It is a convenient thing to believe, because the alternative is usually a project. Often it is not true. Spreadsheet reporting is the correct answer far more often than the analytics industry likes to admit, and moving off one too early makes reporting worse rather than better. Here is where the line actually sits.
What spreadsheet reporting is genuinely good at
Start with the honest list, because it is longer than you would expect.
They are immediate. There is no licence to buy, no model to design, no training to book, and everyone in the business already knows roughly how one works. That matters more than it sounds. A mediocre report someone actually opens beats an elegant one nobody has been shown how to use.
They are also the right tool when you do not yet know the question. A proper data model encodes decisions: what counts as a customer, how you treat a refund, which date matters. A spreadsheet lets you avoid committing while you work out what you are even asking. Building the model first, before anyone knows the question, is how reporting projects end up answering the wrong one precisely.
And they handle judgement well. A budget is full of assumptions a person has to make and revisit. Anything where the reasoning lives in someone’s head, and changes as they think, belongs in a sheet.
The failures that actually matter
Spreadsheets do fail. They just rarely fail for the reason people expect.
Size is almost never it. Excel holds a bit over a million rows per sheet, which is far more than most small businesses will put in one. If your sheet is slow it is usually the formulas, not the row count. The real failures are about people and process:
- More than one person needs to change it at once. This is the classic. You end up with budget_final_v3_JM.xlsx in somebody’s inbox, and two people confidently working from different numbers. Cloud spreadsheets fix the concurrency part. They do not fix the rest.
- Nobody can explain a number. A formula points at another sheet, which points at a hard-coded cell, which was typed by someone who left in 2023. The figure might be right. Nobody can demonstrate that it is.
- It gets rebuilt from scratch every period. If a person spends a day a month reassembling the same report, that is twelve days a year of reassembly. That cost is invisible because it never appears on an invoice.
- Every update means joining exports by hand. Pulling two systems together once is fine. Doing it manually every week is a job nobody chose.
Three of those four are about process, not data. A business with 400 rows can have all of them. A business with 300,000 rows might have none.
The test I would apply
Forget how much data you have. Ask three questions instead.
How many people need to change the thing? How often is it rebuilt by hand? And could a competent colleague reproduce the number from the sheet alone, without ringing the person who made it?
If the answers are one person, rarely, and yes, your spreadsheet is fine. Moving to a BI tool would be a downgrade dressed up as an upgrade. If two or three of those answers point the other way, that is when something else starts to earn its cost.
What moving actually costs
This is the part that gets skipped in the sales conversation. The licence is the small number.
The real cost is ongoing. Someone has to own the model. Someone has to keep it working when the source system changes a field name. Someone has to answer questions about why a figure moved. A BI report with no owner decays faster than a spreadsheet does, because fewer people can see inside it to tell that it has gone wrong.
There is also a quieter problem. A tool will not settle an argument about definitions. If the business has not agreed what a customer is, the new dashboard will simply present one person’s answer in a format that looks authoritative. The disagreement survives, with better formatting and less scrutiny.
If you are staying on spreadsheets, do these
Most of the risk comes off with a handful of habits:
- One owner, and one location. Not an attachment doing the rounds by email.
- No numbers typed inside formulas. Put inputs in their own labelled cells so they can be found and questioned.
- A tab that records where each input came from and when it was last refreshed. This one habit answers most of the “where did that come from” questions that make people distrust a sheet.
- Version by date, not by adjective. 2026-09-14 beats final, which has never once been final.
- Agree the handful of definitions in writing, even informally. That work carries over if you do eventually move.
Done properly, a spreadsheet can serve a small business for years. The mistake is not using one. It is using one that nobody owns, nobody documents, and nobody can reproduce. If you are not sure which of those you have, that is the kind of thing a data health check answers — and the answer is often that you need better habits, not better software.