The Spreadsheet Running Your $20m Business (And Why Nobody Will Touch It)

You know the spreadsheet I'm talking about

It started around three years ago — maybe five. Someone on your team needed to track job costings, or resource scheduling, or client rates. The systems at the time couldn't handle it the way the business needed, so somebody smart built a workaround. A spreadsheet. It worked well. Really well, actually. So other teams started using it. More tabs got added. Formulas started cross-referencing other tabs. Someone added a lookup table on tab 11 that everything else depends on.

Now it has 47 tabs. One person — usually Sarah, or whoever fills that role — knows how it works. When she goes on leave, requests stop getting answered. Nobody else touches it because nobody else fully understands it. And the business has quietly grown to depend on this file for job costing, margin reporting, or resource allocation in ways that would be genuinely disruptive to lose.

You know something needs to change. But every time someone suggests replacing it, the conversation gets complicated. Because it does something really specific to how your business works, and translating that logic into another system feels like a project nobody has time for.

That's the spreadsheet I'm talking about. And if this sounds familiar, it's not because your business is uniquely disorganised. It's because this is one of the most common patterns we see at businesses doing $10m to $80m in revenue. The spreadsheet isn't the problem. It's a symptom of something more structural.

How a workaround becomes infrastructure

No one sat down and decided to build critical business logic into an Excel file. It happened gradually, in entirely rational steps.

Your CRM was bought to manage the pipeline. Your accounting package — probably Xero — was bought for invoicing and reconciliation. Your project management tool handles tasks and timelines. Each purchase made sense at the time. Each one solved a real and immediate problem.

But none of them handled the specific thing your business needed at the intersection of sales, delivery, and finance. The gap between "won deal" and "what it actually cost to deliver" didn't belong neatly in any of them. So someone built a bridge. A spreadsheet that pulled together the information from multiple systems and made it useful.

The problem isn't that they built it. The problem is that the business grew — maybe 3x, maybe 5x — and the spreadsheet stayed the same. What started as a lightweight workaround is now load-bearing infrastructure. And because it was never designed to be load-bearing, it has no redundancy. No documentation. No version control. No audit trail.

This is why "just replace it" feels so hard. You're not replacing a spreadsheet. You're replacing business logic that exists nowhere else, maintained by a person who may not have written it down, running decisions that affect your margin every week.

The risks hiding in the formula bar

Let's get specific about what's actually at stake. Because "spreadsheets are risky" is too vague to act on. Here's what the risk actually looks like.

When a formula error is buried three layers into a tab that cross-references two others, nobody catches it until the number it produces doesn't match something else. And by then, decisions have been made on it. Quotes have gone out. Margins have been reported. Sometimes the error is never found at all — it just gets accepted as "the system says this."

Beyond errors, there are three other risks that are equally real:

Single point of failure. What happens when the person who built and maintains the spreadsheet goes on leave? Gets sick? Resigns? In most businesses, the answer is: things slow down, or someone tries to edit it and breaks something. The institutional knowledge isn't in a system — it's in one person's head, and it walks out the door when they do.

No version control. When someone edits a cell in a shared spreadsheet, there's no record of who changed it, when, or why. If something breaks — or if a number changes and nobody knows why — there's no reliable trail to follow. You're doing archaeology, not debugging.

Data lag. Because the spreadsheet is manually maintained, it's always somewhat behind. The actual state of a job, a project, or a client exists in the spreadsheet from the last time someone updated it — which might be last Tuesday, or last month. Your CFO is making decisions on last Tuesday's reality.

Why "just buy software" isn't the answer

Here's where most businesses make a mistake. They see the risk. They feel the frustration. And they start shopping for solutions. Which software handles job costing? Which ERP has better project tracking? Which platform is right for a business our size?

That's the wrong first question. And businesses that start there often end up worse off — either stuck in a multi-year ERP implementation that costs three times the original budget, or running a shiny new system that their team works around with... a spreadsheet.

The reason the spreadsheet exists is that nobody designed the workflow that connects your systems to each other. That gap is still there, whether you buy new software or not. If you put new software on top of an undesigned workflow, you get the same problem in a different wrapper.

Before you consider changing a platform, the right question to answer is: what is this spreadsheet actually doing? Not "what data does it store" — but what business logic does it contain, what decisions does it support, and what would break if it disappeared tomorrow?

When you answer that question clearly, you'll often find one of two things. Either your existing systems already have the capability to handle the logic — it just hasn't been configured to do so. Or there's a genuine gap that requires a specific tool or integration, and you can scope that precisely rather than buying a platform that promises to solve everything.

Either way, the path forward starts with understanding the spreadsheet, not replacing it.

What to do about The Spreadsheet

Here's a practical sequence that doesn't start with a software decision.

Audit the logic, not the data. Sit down with the person who maintains the spreadsheet and document the business rules — not the formulas, but what they represent. "This column calculates margin by subtracting actual labour cost from quoted labour cost, using rates from the lookup table on tab 11, updated quarterly." That sentence is more valuable than the formula itself. It's the knowledge that needs to be preserved, regardless of what system it eventually lives in.

Identify what it's filling in for. Every spreadsheet exists because something else couldn't do the job. Map the gap. "Our CRM tracks the quote, but doesn't calculate actual job cost as it accrues. Our accounting package sees invoices, but not the quoted rate or scope. This spreadsheet is the bridge between them." That's your requirements document — and it's more honest than anything a software vendor's discovery session would produce.

Pressure-test the dependencies. Who uses this data? For what decisions? How often is it wrong, and when someone discovers an error, what's the flow-on effect? How many people would be affected if the person who maintains it left tomorrow? This isn't meant to be frightening — it's meant to give you a proportionate sense of the risk you're actually carrying, so you can make a proportionate decision about what to fix.

Then make the platform decision. Once you know what the spreadsheet is doing, the platform question becomes much simpler. Can your existing systems handle this if configured properly? Is there a specific integration that solves 80% of the gap? Or is this genuinely a case where a new system is needed — and if so, exactly which part of the problem needs addressing?

Most businesses that do this exercise discover that the gap is narrower than they thought. Not because the spreadsheet isn't a problem, but because the problem is a specific, definable gap — not a global "we need new systems" moment. And a specific, definable gap can be fixed. Often faster and cheaper than a wholesale platform replacement.

The question that changes everything

There's one question worth asking before any of the above: does this logic belong in a system?

Not every spreadsheet should become a system. Sometimes a spreadsheet is the right tool for the job — for analysis that changes shape every quarter, for scenarios that don't need to be tracked over time, for work that genuinely doesn't fit a repeatable workflow. In those cases, a well-designed, well-documented spreadsheet is the right answer.

But when a spreadsheet is running a repeatable operational process — calculating job margins on every project, tracking resource allocation each week, managing client rates that update quarterly — that's logic that belongs in a system. Because systems have version control. They have an audit trail. Multiple people can access them. They don't depend on one person to function. And the data they produce flows to the other systems that need it.

The right approach to this isn't to rip out the spreadsheet and start over. It's to map what the spreadsheet is actually doing, understand which of your existing systems could absorb that logic with the right configuration, and close the gap — in a way that doesn't create three new spreadsheets to manage the transition.

That's the conversation worth having. Not "which software should we buy?" but "how does work actually flow through our business — and where is the spreadsheet filling a gap that should be closed?"

Once you can answer that, the path forward is usually simpler than you expected.