TL;DR: replacing Excel with a business tool pays off when the file is no longer a spreadsheet but a shared database: several people write to it, other tools depend on it, and one error would carry a real cost. Research by Raymond Panko (University of Hawaii) estimates that about 94% of operational spreadsheets contain at least one error. Budget-wise: a first well-defined scope fits in a sprint from €2,500 excl. VAT; a full business application ships in 4 to 6 weeks, on a written quote.
Key takeaways
- About 94% of operational spreadsheets contain at least one error, and the cell error rate hovers around 5%, according to Professor Raymond Panko's research compiled by DataHub Pro in The State of Spreadsheets 2026.
- In 2012, JPMorgan lost $6.2bn in the London Whale affair; its risk model ran on manual copy-and-paste between Excel spreadsheets with insufficient controls, as documented in Henrico Dolfing's case study.
- From September 25 to October 2, 2020, Public Health England lost 15,841 Covid cases: test results were imported into a file saved in the legacy .xls format, capped at 65,536 rows, and overflow rows vanished without any warning, The Register reported.
- The tipping point is not file size: it is the moment the spreadsheet becomes a shared database that decisions, customers and other tools depend on.
The short answer: three signals, no magic threshold
An Excel file should be replaced by a business tool when three signals stack up. One: several people write to the same file, and nobody knows who changed what. Two: the file's data is re-keyed by hand into other tools, CRM, invoicing or accounting, with a risk of drift at every copy. Three: an error in that file would carry a real cost; a wrong quote, a lost order, a bad number presented in a board meeting. Two signals out of three usually justify a scoping call; with all three, the status quo already costs more than the tool would.
A fourth, more prosaic clue confirms the diagnosis: time. If someone spends several hours a week consolidating, checking and repairing the file, that time has a price. At a loaded cost of €30 an hour, 4 hours a week add up to more than €6,000 a year; a significant share of the price of a tool that would remove the chore entirely.
Why does Excel eventually break in production?
Because it was never designed for it. Excel is a personal analysis tool: it shines at exploring numbers, simulating a scenario, preparing a chart. It has no per-user access rights, no input validation, no change history, and no alert when data overflows. Professor Raymond Panko (University of Hawaii), who has been compiling spreadsheet audits since the 1990s, sums up fifteen years of research in one line:
“Spreadsheet errors are both common and non-trivial.” Raymond Panko, Spreadsheet Errors: What We Know (arXiv)
The compiled numbers give the measure: about 94% of audited operational spreadsheets contain at least one error, and around 5% of the cells in a complex spreadsheet are wrong, a rate consistent with ordinary human error on complex cognitive tasks, as the 2026 summary by DataHub Pro recalls. The most worrying part is not the rate: it is overconfidence. Audits show a massive gap between the reliability spreadsheet authors assume and what inspection actually finds.
Two famous incidents show the scale of the damage. In 2012, JPMorgan lost $6.2bn in what became known as the London Whale affair: the risk model was built in Excel, fed by manual copy-and-paste, with insufficient controls and formulas changed on the fly. In October 2020, Public Health England lost 15,841 Covid cases in a single week: test results were imported into a file saved in the old .xls format, capped at 65,536 rows; once the ceiling was hit, additional cases silently disappeared. Your company is not playing with billions, but the mechanics are identical: a silently wrong file, and decisions made on top of it.
What a business tool actually changes
A business tool is not a prettier Excel: it is a database with rules. Every user has defined rights, so an intern cannot overwrite the customer file. Input is validated at entry: an email has an email format, a date is a date, an amount cannot be negative. Every change is logged, so it is traceable and reversible. Above all, other tools connect to it: the approved quote flows to invoicing without re-keying, the new customer lands in the CRM, the dashboard updates itself. Re-keying disappears, and with it the main source of drift between your tools.
It is the pattern I keep meeting in my own work. At Profile Club, KPI dashboards built on Google Apps Script replaced the manual consolidation of data that used to live in spreadsheets; I covered that approach in a dedicated article. The target is the same every time: the spreadsheet remains an excellent analysis screen, but it stops being the place where the data lives.
How much does it cost, and when does it pay off?
The answer has three tiers. First tier: if your process is standard, an off-the-shelf SaaS or a no-code database costs tens of euros a month and is up in days; it is often the right answer, and it should be considered before anything custom. Second tier: when the process has rules of its own, a well-defined scope (a validated input form, document generation, a connection between two tools) fits in a sprint, from €2,500 excl. VAT in my public price points. Third tier: a full custom business application, with accounts, roles and a back office, ships to production in 4 to 6 weeks, on a quote written before work starts.
The table below sums up the four typical situations and the matching verdict.
| Situation | Verdict | Why |
|---|---|---|
| One user, occasional analysis | Keep Excel | Its home turf: exploration, simulation, charts |
| Standard process (accounting, payroll, simple CRM) | Off-the-shelf SaaS | Battle-tested, tens of euros a month |
| Shared file, re-keying into 2 or 3 tools | No-code database or light business tool | Access rights, input validation, history |
| Differentiating process, own rules, costly errors | Custom application | The tool fits the process and connects to the rest |
Profitability needs no elaborate formula: add up the annual cost of the time spent maintaining the file and the cost of one plausible error (a wrong quote, a missed follow-up, a miscounted stock), then compare with the price of the tool. When the first sum exceeds the second, the question is no longer whether to replace Excel, but which scope to start with.
When should you keep Excel?
In at least four cases, and naming them is the best honesty test for any vendor. One: you are alone on the file and it is used for analysis, not operations; Excel is then the best tool in the world, and replacing it would be a comfort purchase. Two: the process changes every month; freezing an unstable process into software means paying twice. Three: volume is low; a few rows a week do not justify a dedicated tool. Four: the process is standard; accounting, payroll or a generalist CRM exist as proven SaaS, and custom software would add nothing there. Custom is reserved for the process that makes your difference and that no market tool fits properly.
Frequently asked questions
What are the signs it is time to replace Excel with a business tool?
Three signals: several people write to the same file, data is re-keyed into other tools, and an error would carry a real cost. Add maintenance time: several hours a week spent consolidating or repairing a file quickly add up to thousands of euros a year.
How much does replacing an Excel file with a business application cost?
An off-the-shelf SaaS or a no-code database costs tens of euros a month when the process is standard. For custom work, a well-defined scope fits in a sprint from €2,500 excl. VAT; a full business application, delivered in 4 to 6 weeks, is priced on a quote written before work starts.
Should you pick a no-code tool or a custom application?
Consider no-code and SaaS first: if your process fits a market tool, that is the cheapest answer. Custom becomes relevant when business rules are specific, volumes grow, or the tool must connect tightly to your CRM, invoicing or telephony.
Can you keep Excel for analysis after migrating?
Yes, and it is even recommended. Excel remains an excellent exploration and simulation tool. A sound architecture keeps the data in a structured database, with rights and history, and exports to Excel for one-off analysis. It is the reverse direction, data living in Excel, that causes trouble.
Excel is not the problem; hijacking it into a production database is. The day your file has several authors, tools downstream and decisions upstream, it is doing a job it was never designed for, with roughly a 94% chance of holding at least one error. So the real question is not whether your spreadsheet contains an error, but how much it will cost the day it surfaces.