Why Mid-Market Still Runs on Spreadsheets
Mid-market companies occupy an awkward position in the software market. Too large for the simple SaaS tools designed for small businesses. Too small — or too specific — for the enterprise platforms that serve global organisations. The gap between those two extremes is filled, in most mid-market businesses, with spreadsheets, shared documents, email threads, and manual processes. This is not a technology failure. It is a market failure — and it is costing mid-market businesses more than most of their leaders have ever calculated.
Walk through the operations of almost any mid-market company — a £15M professional services firm, a $40M specialist manufacturer, a regional financial services business — and you will find, somewhere in the core of the operation, a spreadsheet doing critical work.
Not a simple reference spreadsheet. A load-bearing one. Staffed and maintained by someone who built it years ago and is the only person who fully understands it. Linked to other spreadsheets by formulas that break when the file is moved. Updated manually by people who copy-paste from emails, PDFs, and system exports. Critical to billing, resourcing, compliance, or operations — and not backed up in any meaningful sense.
The person who built it is either still there, indispensable because of their spreadsheet knowledge, or has left — and the business is now maintaining something nobody fully understands.
This is the spreadsheet problem. It exists in almost every mid-market business at scale, it is almost never on anyone's formal risk register, and it is costing significantly more than most leaders have calculated.
Why It Happens: The Mid-Market Software Gap
The spreadsheet problem is not a technology failure. It is a market failure — specifically, a failure of the software market to serve the mid-market adequately.
Mid-market businesses occupy an awkward position. They are too large for the simple, intuitive SaaS tools designed for small businesses and startups. Those tools lack the complexity management, user permission structures, reporting depth, and integration capabilities that a business of fifty to five hundred people actually needs.
But mid-market businesses are also, typically, too small — or too specific — for the enterprise platforms designed to serve global organisations. SAP, Salesforce at full deployment depth, ServiceNow: these products are architecturally designed for organisations with dedicated implementation teams, multi-year rollout programmes, and IT budgets that dwarf most mid-market companies' total technology spend. When a mid-market business is sold an enterprise platform, it typically deploys a fraction of the functionality, at significant cost, over a painful implementation timeline, and ends up with a product configured to approximate what it actually needs rather than serve it directly.
The gap between "too complex for simple SaaS" and "too small for enterprise" is the space where spreadsheets live. They are not the right answer — they are the practical answer to a question the software market has not solved for this segment.
What the Spreadsheet Is Actually Doing
Understanding the cost requires first understanding the role the spreadsheet plays. In most mid-market businesses, the critical spreadsheets fall into one of three categories.
Process orchestration. The spreadsheet is managing a workflow — tracking a pipeline, coordinating a production process, managing a project across multiple teams. It is doing what a dedicated system should be doing, but the dedicated system either does not exist for this specific workflow or would cost more to implement than the business has justified spending.
Data aggregation. The spreadsheet is pulling together data from multiple systems that do not talk to each other — combining a CRM export, a finance system report, and a manual input from a team leader into a single view that management uses to make decisions. It is doing the integration work that the underlying systems should be doing automatically.
Compliance or reporting. The spreadsheet is the mechanism through which the business meets a regulatory requirement or produces a management report. It is populated manually from source systems, reviewed for errors, approved, and submitted — a process that is repeated monthly, quarterly, or annually and absorbs significant staff time each cycle.
In each case, the spreadsheet is a workaround for an unmet software need. The question is what that workaround actually costs.
The Real Cost: Four Categories of Loss
The cost of the spreadsheet problem rarely appears as a line item on any budget. It is distributed across four categories that each appear innocuous individually but are significant in aggregate.
Staff time. The most visible cost is the time spent maintaining, updating, and correcting the spreadsheet — and the time spent by people downstream who are waiting for the update, chasing the person who has access, or reconciling discrepancies between two versions. In a mid-sized business, a single critical spreadsheet process typically consumes eight to fifteen hours of staff time per week across all the people involved in maintaining and consuming it. At loaded staff cost, that is £20,000–£40,000 per year — for a single process.
Errors and their consequences. Spreadsheets are error-prone by design. Data is entered manually, formulas are fragile, version control is informal. The European Spreadsheet Risks Interest Group estimates that 88% of spreadsheets in use contain errors. For operational spreadsheets — the ones driving billing, resourcing, compliance, or reporting — a single significant error can cost more than the total annual staff time invested in maintaining it. A billing error that results in a client dispute, a resourcing miscalculation that leads to a project overrun, a compliance report submitted with incorrect figures: the downstream cost of these events is routinely absorbed as a cost of doing business rather than attributed to the spreadsheet architecture that made them likely.
Capacity constraint. The staff whose time is consumed by manual process maintenance is not available for higher-value work. A senior operations manager spending twelve hours a week on spreadsheet maintenance is not spending those twelve hours on the work they were hired to do. This cost is invisible in the headcount budget but very real in what the business is not getting from the people it has.
Scalability limit. Manual processes do not scale with the business. Every percentage point of revenue growth adds a corresponding load to the processes that support it. A business that grows 20% in a year requires 20% more manual effort in every process that has not been automated — more copy-pasting, more reconciliation, more time maintaining a spreadsheet that was already fragile at the previous scale. The spreadsheet problem does not stay the same cost as the business grows. It compounds.
Why It Persists Despite the Cost
If the cost is real and significant, why do these processes persist?
The answer is rarely inertia or lack of awareness. It is the calculation — explicit or implicit — that the cost of fixing it is higher than the cost of living with it. And until recently, that calculation was often correct.
Custom software to replace a critical process used to mean a six-figure project, a six-month timeline, and significant delivery risk. The choice between "keep the spreadsheet" and "spend £150,000 on a custom build that takes eight months and might not work" was not a difficult one for most mid-market leaders.
That calculation has changed. AI-native software development has compressed custom build timelines from months to weeks and reduced the cost accordingly. A workflow that required a £120,000 custom development project in 2020 can be specified, built, tested, and deployed in three to five weeks in 2026.
The spreadsheet is still there because the alternative used to be impractical. It is still there in most businesses because the leaders running them have not updated the cost comparison with current development economics. The gap between "the spreadsheet" and "the right software" is smaller than it has ever been — and the cost of continuing to live with the spreadsheet is not getting any smaller.
What to Do First
The starting point is an honest inventory of which manual processes are load-bearing — which spreadsheets, shared documents, and email workflows are doing critical operational work that should be done by software.
Most mid-market businesses find three to five such processes when they look honestly. Prioritising them by the cost of the current state — staff time, error rate, scalability constraint — produces a ranked list that is also, roughly, the ROI ranking for the software investments that would replace them.
The business case for the first replacement is almost always self-funding. The staff time recovered from a single critical manual process typically covers the development cost within the first year. The errors prevented, the scalability restored, and the staff capacity redirected to higher-value work make the subsequent years almost entirely margin improvement.
The spreadsheet is not the problem. It is the symptom. The problem is the market gap that made the spreadsheet the only practical answer. In 2026, that gap is closable — at a cost and timeline that most mid-market leaders have not yet recalculated.
Related reading: Build vs Buy: When Off-the-Shelf AI Tools Stop Fitting Your Business → The Hidden Cost of Software That Doesn't Fit → How Long Does It Actually Take to Build an AI-Powered App →