The point where spreadsheets start costing you money

Spreadsheets get an unfair reputation in conversations about business systems. They are extraordinary tools. They are free to start, everyone already knows how to use one, and they can model almost anything in an afternoon without asking permission.

That is exactly why they end up running things they were never meant to run. A spreadsheet does not fail loudly when it outgrows its job. It keeps working, slightly worse, for a long time.

What they are genuinely good at

Thinking. Modelling something you do not fully understand yet. Any calculation that one person does, reviews and acts on. Anything you will throw away in a month.

If a spreadsheet is a place where one person works something out, it is the right tool and it will stay the right tool. The trouble starts when it quietly becomes the place where the business remembers something.

The specific failure points

More than one person edits it. This is the first and largest. The moment two people can change the same file, you have a concurrency problem with no concurrency control. Shared cloud sheets help with the overwriting but not with the deeper issue: nobody knows which change is authoritative or why it was made.

It has become the record rather than the working-out. If a customer phones and someone opens a spreadsheet to find out what was agreed, that file is now your database. It has no validation, no history and no backup policy beyond hope.

Copies exist. The moment someone downloads it to work offline, or emails a version, or makes a copy to try something, the truth has forked. Every copy is now plausible and only one is right.

Structure lives in formatting. Status is a fill colour. Priority is bold. A human can read that instantly and nothing else can — not a report, not a search, not the next person.

Nobody can say what changed. A number is different from last week and there is no way to know who changed it, when, or what it was before.

The costs you do not see in the accounts

These never appear as a line item, which is why they run for years.

The time spent reconciling versions. The decisions made on a stale copy. The reports rebuilt by hand every month because the structure will not support a query. The single person who understands the formulas, and the risk that represents. The errors that are never discovered because there is nothing to compare against.

A spreadsheet that runs your operations is not free. It is paid for in attention, and it is billed monthly.

Before you move anything, tighten the sheet

Often the first step is not software at all. If the sheet is still the right tool but has started to hurt, a few hours of discipline can buy you a year.

Name one owner who is allowed to change the structure. Everyone else gets a form or a restricted range to add rows. Turn on data validation, so status is a dropdown rather than a fill colour and a date column only accepts dates. Keep one file and delete the copies. Use the version history your sheet already has, and check that you know how to read it before you need it. Export a copy somewhere else once a week, so the deleted-file test below has a better answer.

None of that is a system, and we would rather you did it than paid us to replace a sheet that only needed rules. If it holds for six months, you were right to stay. If people keep working around the rules because the sheet cannot enforce them, that is the evidence you need to move the record.

What to move first

When a business outgrows spreadsheets, the instinct is to replace everything. That usually fails, because the spreadsheet is doing twenty things and only three of them matter.

Move the record before you move the analysis. The part that needs to become a real system is the part where the business remembers things — customers, orders, jobs, their current state. That is where the concurrency, history and validation problems live.

The analysis can stay in a spreadsheet for a long time, quite happily, as long as it reads from a reliable source rather than being the source. A spreadsheet fed by a proper system is a good arrangement. A spreadsheet that is the system is not.

When a system is the worse choice

Moving off a spreadsheet has a price that is easy to underestimate. The data has to be cleaned first, and a sheet that has grown for years usually holds duplicates, free-text where a category should be, and dates typed three different ways. Someone has to decide which version of each is right. That work is the largest part of most migrations and it is not software. Plan to run the sheet and the new system side by side for a few weeks, then make the sheet read-only on a stated date. Without a cutover date, the old file stays editable and quietly becomes the real record again.

Then there is the habit. A tool the team did not ask for, replacing one they like, tends to be worked around within weeks. People keep a private sheet on the side and the record forks again, now with a system sitting beside it.

So if one or two people maintain the file, the rules above are holding, and nobody has been caught out by it, leave it. A new system is justified by a specific recurring failure you can name, not by the sheet being old or untidy. If you cannot name one, you are being sold tidiness.

A test that works

Ask what happens if the file is deleted right now, with no backup.

If the answer is "we rebuild it in an afternoon", it is a working document and you should leave it alone. If the answer involves phoning customers to ask what was agreed, it stopped being a spreadsheet a while ago and nobody noticed.

That second answer is not a reason to panic. It is a reason to move one thing — the record — and leave the rest where it is. Which one to move first is the same question as what to automate first.