Escape from Excel: The Frankensheet That Nearly Broke Britain

There is a spreadsheet somewhere in Britain right now that is doing something it absolutely should not be doing. It is tracking live stock levels for a warehouse in Wolverhampton, or calculating commission payments for a sales team in Edinburgh, or — and this is a real thing that has happened more than once — managing patient referrals across an NHS trust in the East Midlands. It has 47 tabs. It was last audited in 2019. The person who built it left in 2021. Nobody knows what the orange cells mean.

Welcome to the Frankensheet. Britain's most beloved and most catastrophic piece of infrastructure.

How the Monster Gets Made

It never starts as a monster. It starts as a Tuesday afternoon. Someone needs to track something — orders, invoices, staff rotas, bed availability — and Excel is right there, warm and familiar, asking no difficult questions. You build a quick table. You add a formula. You share it on the network drive with a filename like FINAL_v2_USE_THIS_ONE.xlsx.

Then the business grows. Or doesn't grow, but gets more complicated. A new column appears. Then a new tab. Then a macro that Darren wrote in 2017 and which nobody has touched since because the last person who tried broke something in the 'Summary' tab and had to buy the whole office biscuits as penance.

Before long, you have what academics — yes, actual academics study this — call an end-user computing disaster waiting to happen. The European Spreadsheet Risks Interest Group (yes, that is a real organisation, and yes, they have a newsletter) estimates that 88% of spreadsheets contain errors. Not minor ones. Errors that affect decisions. Errors that affect money.

When the NHS Caught the Bug

In 2020, Public Health England famously lost nearly 16,000 Covid test results because data was being processed through an Excel file that hit the format's row limit. The XLS format caps out at 65,536 rows. Nobody had thought to check. Nearly 50,000 contacts went untraced as a result.

This was not a rogue operation run by someone who didn't know better. This was a national health infrastructure, built on a spreadsheet, because at some point someone needed a quick solution and Excel was available.

It is almost too on-the-nose to be useful as a cautionary tale. And yet here we are.

The Rewrite Dilemma: Limp On or Burn It Down?

Here is the genuinely difficult bit. Once your Frankensheet has embedded itself into daily operations, removing it is not a technical problem. It is an organisational, psychological, and sometimes political problem dressed up as a technical one.

The rewrite option sounds clean. Build something proper. A real system, with a database, with access controls, with an audit trail that doesn't rely on someone remembering to save a backup to a folder called OLD VERSIONS DO NOT USE. Spend six months and £80,000 and emerge blinking into the light with something maintainable.

Except. The rewrite will inevitably miss something the spreadsheet was quietly handling. Some edge case that Darren baked in during a Tuesday afternoon in 2017 and never documented. You will discover this approximately three weeks after going live, when Karen in Finance rings to explain that the new system has miscalculated the Easter bank holiday overtime uplift for part-time staff on variable contracts, which the spreadsheet handled perfectly, thank you very much.

The 'limp on' option is equally grim. You know it's fragile. You know it's a single corrupted file away from disaster. You know that nobody fully understands it anymore. But it works, mostly, today, and the business has seventeen other problems that feel more urgent.

Most British businesses choose to limp. Some of them get away with it indefinitely. Some of them do not.

The Beermat Test for Your Spreadsheet

At Beermat Software, we have a simple heuristic. If you cannot explain what your spreadsheet does on a beermat — not the formulas, just the purpose — it has already grown beyond what a spreadsheet should be doing.

A spreadsheet is a tool for exploring data. For modelling scenarios. For answering questions. The moment it becomes the system of record for anything that matters — money, people, health, inventory — it has escaped its natural habitat.

The questions worth asking are:

• Can it be corrupted by a single user making a single mistake? If yes, it is not a system. It is a liability.
• Would the business notice immediately if it disappeared? If the answer involves words like 'catastrophically', you have a single point of failure masquerading as a tool.
• Does anyone fully understand it? If the answer is 'sort of' or 'Darren did but he's gone', you are operating on institutional memory that is one resignation away from evaporating.

What the Sensible Ones Do

The British tech companies that handle this well share a trait: they treat the Frankensheet as a specification, not a legacy problem. Rather than trying to replicate it feature-for-feature in new software, they use it as a record of what the business actually needed — all the edge cases, the workarounds, the orange cells — and rebuild from first principles.

They also, crucially, do not wait until the spreadsheet breaks. They migrate while it still works, running both systems in parallel until confidence is established. It is slower. It is more expensive in the short term. It is significantly less terrifying than explaining to the board why payroll didn't run this month because someone accidentally sorted column D without selecting the whole sheet.

The Frankensheet is not a uniquely British problem, of course. But there is something very particularly British about the combination of pragmatism, optimism, and mild denial that allows one to grow to the size it does before anyone intervenes. We are a nation that invented the stiff upper lip and the Heath Robinson contraption in equal measure, and our spreadsheets reflect this perfectly.

Somewhere in Wolverhampton, a warehouse manager is opening FINAL_v2_USE_THIS_ONE.xlsx and hoping for the best.

We wish them well.