When a spreadsheet becomes a liability

Two different objects, one file extension

A spreadsheet that records something is a document. A spreadsheet that decides something is a system — one with no real owner, no meaningful permissions, no history of what changed, and no test that would tell anyone it had started producing the wrong answer.

Almost every company has both, and almost nobody distinguishes between them. That distinction is the entire question. A document that turns out to be wrong is an inconvenience. A system that turns out to be wrong has already been believed, acted on, and quoted to somebody outside the company.

So the useful question is not whether you use spreadsheets. Everyone does, and the good ones are extraordinary tools. The question is which of yours have quietly stopped being documents.

A test you can apply this afternoon

Four questions. They are deliberately about consequence rather than about the file, because the file always looks fine.

1. 01If this were wrong for a full day, would anything downstream be wrong with it — an invoice, a rota, a delivery date, a number somebody repeats to a client?
2. 02Does more than one person need to change it in the same week?
3. 03Does anyone re-key what is in it into another system, or another system's data into it?
4. 04Could a competent new joiner use it correctly on their second day, without being told the rules that are not written down?

One yes is ordinary. Three or four means the file is running a process — and from that point on the interesting questions are about the process, not about the spreadsheet.

What the failure actually looks like

Load-bearing spreadsheets rarely fail loudly. They fail as a set of recognisable shapes, each of which is usually treated as normal by the people living with it.

The reconciliation meeting

Two systems hold the same fact, they disagree, and a recurring meeting exists to decide which one to believe. The meeting is the cost. The spreadsheet is where the answer gets written down afterwards.

The month-end rebuild

Somebody spends the last days of every month reconstructing, by hand, information the systems already hold. It appears in no budget, because it is a portion of a salary rather than a line item.

The single maintainer

One person knows why the formula in column M is what it is. That knowledge is written down nowhere, leaves the building every evening, and leaves permanently when they do.

The silent edit

A cell that held a formula now holds a number somebody typed over it. Nothing announced this. The file has been slightly wrong ever since, and nobody can say for how long.

The version suffix

The filename has acquired a date, a set of initials or the word final. Several people hold a copy. At least two of those copies differ, and which one is authoritative is discovered at the worst possible moment.

The permission gap

Everyone who needs to read it can also change it, because in this tool those were never separable. The control you would actually want — see everything, change one column — does not exist.

The cases where the right answer is to keep it

This is the part usually left out, because it does not sell anything. It is also, in our experience of looking at how companies really operate, the correct answer more often than the alternative.

It is a model, not a record

Scenario work, pricing exploration, a one-off analysis. A spreadsheet is an exceptional instrument for thinking with numbers, and purpose-built software is usually worse at it. Move the records it draws on if you must; leave the thinking where it is.

One person, one purpose

A working file nobody else depends on is not a coordination point, and there is no reason to turn it into one.

The process is still changing shape

If how you do this changed twice last year and will change again, encoding it now fixes a temporary answer in place — at exactly the moment when flexibility is worth more than structure.

The volume is small and an error is cheap

Forty rows a month, and a mistake costs an apology. The spreadsheet is proportionate to the problem. A project would not be.

Nobody has decided what the process should be

Software makes a process explicit. If three people currently do this three different ways and no one has chosen between them, building will encode the disagreement and make it considerably more expensive to resolve.

Things worth trying before building anything

Between leaving it alone and replacing it there is a long middle that costs very little and is frequently sufficient.

Give it a named owner

In writing, with the authority to refuse changes. A striking number of spreadsheet failures are ownership failures wearing a technical costume.

Reduce it to one copy

One file, one location, genuine view-versus-edit permissions, and every other copy deleted rather than archived. This alone resolves the version problem, which is the failure that causes the most public embarrassment.

Remove the re-keying, not the file

If the cost is typing the same fact into two places, connecting those two systems removes that cost without replacing either of them and without touching the spreadsheet at all.

Separate the record from the analysis

Let the system that already owns the data own it, and let the spreadsheet read from it. Most files that feel load-bearing are doing two jobs, and only one of them is dangerous.

Simplify before you encode

Count the exceptions. If a third of the rows are special cases, the process is the problem, and building software around it produces expensive software with the same problem.

Every one of those is reversible, which is the point. None of them requires a project, a budget or a vendor — and deciding between them is the same question as build, buy, or connect, asked about one file instead of a whole operation.

When a platform becomes the honest answer

Sometimes it genuinely is. The signals are specific rather than atmospheric:

• The spreadsheet has become the integration layer between systems that ought to be talking to each other directly.
• Several teams depend on it simultaneously, and their needs have begun to conflict inside a single grid.
• You need to know who changed what, and when, and the tool cannot tell you.
• The rules are stable enough to be worth writing down, and specific enough that nothing on the market implements them.
• The cost of it being wrong has become material — money, a regulatory obligation, or a client relationship.

Even then, the order matters more than the decision. Understand how the work actually moves, decide what should change, and build third — which is the whole of how we work, and exists because the alternative is building today's process faster.

The cost that is not in the estimate

Replacing a load-bearing spreadsheet is a change project with a software component, and the software is routinely the cheaper half.

The definitions

A spreadsheet lets two departments hold incompatible definitions of the same word indefinitely. Software does not. Somebody now has to decide what an active client is, and that conversation is longer than it sounds.

The history

A platform that starts empty gets abandoned. The old data has to move, which means it has to be cleaned, which means discovering exactly how inconsistent it has been.

The flexibility people will miss

The spreadsheet let people improvise. The replacement mostly will not — and the people who improvised most are usually the ones whose support the project needs.

Adoption

If people quietly go back to the file, nothing was achieved, however good the software is. Training in real workflows rather than a generic session is part of building it, not a phase afterwards.