← Ilumax Systems blog

Operations

The Specific Ways a Spreadsheet Stops Being the Right Tool

25 September 2026 · 5 min read

Four failure modes. The two highlighted are the ones that come from a spreadsheet treating structure and data as the same thing.

A spreadsheet is an excellent piece of software and most businesses should use more of them, not fewer. The problem is that a spreadsheet never announces the moment it stopped being the right tool. It just gets slightly worse, in ways that are easy to absorb, until something goes wrong that is expensive.

There are four recognisable failure modes. They are worth telling apart, because only two of them mean you need different software.

Four spreadsheet failure modes, and what each one calls for Version conflict is fixed by a habit. Formula drift and a missing audit trail justify purpose-built software. Handover risk can go either way. TRY THE CHEAPER FIX FIRST JUSTIFIES DIFFERENT SOFTWARE Version conflict A shared file and one rule usually settles it Formula drift Every edit can quietly damage the logic No audit trail It records a cell edit, not a decision Handover risk — either answer Document the file properly, or build the application it has quietly become
The two on the right come from the thing a spreadsheet does by design: it lets anyone change anything, including the logic.

Version conflict

Two people need the file at once. One of them wins. The other works in a copy, and that copy acquires a name like quotes_final_v3_JUNE_use-this-one.

Shared cloud spreadsheets solve most of this, and if the business is still emailing files around, the cheapest fix is not custom software — it is moving to a shared sheet and agreeing that the shared one is the only one. Do that first. If conflicts persist afterwards, it is usually because two people need to edit the same rows for different reasons, which is a process question rather than a tools question.

Formula drift

Someone pastes a row and the formula does not come with it. Someone widens a range and one cell is left out. Six months later the totals are subtly wrong, and nobody can say since when.

This is the first genuine warning sign. A spreadsheet treats structure and data as the same thing, so every edit is an opportunity to damage the logic. The more people who touch the file, and the less often they touch it, the faster drift accumulates. When a calculation matters commercially — pricing, margin, payroll — and more than a couple of people edit the file, the spreadsheet is carrying a risk it was not designed to carry.

No audit trail

A customer asks why the price changed between the quote they received in March and the one in May. The honest answer available to most businesses is that somebody probably updated a rate.

Version history in a cloud spreadsheet technically records the change, but it records it as a cell edit, not as a business event. Nobody is going to scrub a revision timeline to reconstruct a decision. If your process needs to answer who changed this, when, and against what — because of a dispute, an audit, or simply because the work is complicated enough that people forget — a spreadsheet will not answer it.

Handover risk

One person understands the file. They built it, the clever parts are theirs, and the business has never had to explain it to anyone else.

This is the failure mode with the worst consequences and the least urgency attached to it, because nothing goes wrong until that person is unavailable. It is also the one most often mistaken for a staffing problem. It is not. It is a documentation problem that became a single point of failure.

What each one actually calls for

Version conflict is usually a tooling habit — fix it with a shared file and a rule before spending anything.

Formula drift and missing audit trail are the two that justify purpose-built software, because both come from the thing a spreadsheet does by design: it lets anyone change anything, including the logic. Software that separates the calculation from the data removes the whole category.

Handover risk can be solved either way. Sometimes the answer is to document the spreadsheet properly. Sometimes the spreadsheet has grown into an application that nobody decided to build, and the honest move is to build it deliberately instead.

The question worth asking is not whether you have outgrown spreadsheets in general. It is which of these four is happening, how much a bad outcome would cost, and whether the cheaper fix has actually been tried.

If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.


More from the blog

Buying Software

What Actually Moves the Price of a Custom Build

Five things decide what a custom system costs, and a feature list is not one of them. What scope, integrations, data migration, approvals and support each do to a quote — and what you can do to lower it honestly.

Buying Software

Custom Software vs Off-the-Shelf: When Not to Build

We build custom software, and most businesses that ask us about it should buy something existing instead. Here is the line between the two, and the costs on both sides that get left out of the comparison.