Excel Is Not a System — When a Spreadsheet Stops Being Enough

The difference between a spreadsheet and a system isn’t the number of features. It’s that a system understands the concept of an invalid state. It rejects values outside an approved list, prevents the deletion of a record linked to another, and records who made each change and when. A spreadsheet has no such concept. Every value is equally valid, every overwrite equally permissible, and every deletion equally silent.

This is not a flaw in Excel, but a fundamental part of how it is designed — and the source of its advantage at an early stage. The consequence appears later: a spreadsheet doesn’t tell you when something has gone wrong. The error doesn’t show up as an alert, but as a decision made based on inaccurate data. In the case of Public Health England, this went on for eight days.

The regulator described this problem explicitly as early as 2008, when the UK FSA fined Credit Suisse’s UK entities £5.6 million. The issue was not a faulty formula. The regulator found that the way transactions were recorded in the CDO business was complex and overly reliant on large spreadsheets containing numerous entries. The result was a lack of transparency that hindered effective oversight, risk management, and control. An incorrect valuation of certain positions went undetected for around five months. The problem was not the error itself. It was the lack of a way to detect it.

The most well-documented body of research in this area was developed by Raymond Panko of the University of Hawaii. Repeated audits of spreadsheets used in operational settings have led to the same conclusion: the vast majority of files contain errors. The specific percentages are sometimes disputed because the samples were small and the methodologies varied. The overall direction of the findings, however, is consistent. Panko summarized it most simply: the question is not whether a spreadsheet contains an error, but how many errors it contains and how serious they are.

This is only surprising at first glance. The baseline human error rate for simple but non-trivial cognitive tasks ranges from 1 to 5 percent. This applies to writing, calculations, and writing lines of code, both in laboratory studies and in organizations. A few percent per cell may sound harmless, but those fractions add up: with a thousand formulas, the probability that every one of them is correct approaches zero. A spreadsheet containing several thousand formulas is essentially a program with several thousand lines of code — only without tests, reviews, or change history.

Experience doesn’t change this. Panko and Sprague compared errors made by students, MBA students with no practical experience, and MBA students with more than 250 hours of experience building spreadsheets. The differences were not statistically significant. But another finding is even more uncomfortable. In an experiment conducted by Panko and Halverson, participants estimated the probability that the spreadsheets they had built contained an error at an average of 18%. In reality, 86% of those spreadsheets contained errors. Spreadsheet authors don’t just make mistakes — they systematically underestimate the likelihood that they have made one. The study involved students in a laboratory setting, but overconfidence is one of the best-established phenomena in behavioural science, and experts are not immune to it.

The cost of that confidence was paid by TransAlta. In 2003, the Canadian power producer overbid on transmission contracts because rows shifted while data was being copied in the bid spreadsheet. The resulting write-off amounted to $24 million. The company’s CEO acknowledged that the error had not been caught during the final sorting and review of the bids — in other words, during the very control process that was supposed to catch it. “Check more carefully” is not a control mechanism. It is an assumption that research on human error does not support.

The common belief is that a spreadsheet stops being sufficient once it gets too large. That’s misleading. A file with 200 rows may already be well past the point where it should be used, while one with 200,000 rows may still be perfectly safe. The boundary is defined by the role the spreadsheet plays, not its size. Public Health England crossed that boundary not when the template became full, but when the file became the register for an entire country. The row limit didn’t cause the problem — it revealed something that had been true for months. A spreadsheet remains an analysis tool as long as it helps answer a question. It crosses the line when it starts storing the state of a process that others depend on: inventory levels, order statuses, commission calculations, deadlines, or permissions.

Three questions reveal what you give up when a spreadsheet takes on that role. Can the file do its job when no one has opened it? Can you determine who changed a specific value, when and on what basis, without asking anyone? Does the tool flag an error, or does a person have to notice it?

A spreadsheet fails all three — by design, not through negligence. The deciding factor, then, is not the outcome, but the cost of relying on it. For a file used simply to model tomorrow’s scenario, that cost is effectively zero. But when other people depend on it, the company is no longer just using a spreadsheet. It is maintaining a system — undocumented, without an owner, without tests, and without guarantees.

Contrary to predictions from a decade ago, spreadsheets are not going away. A 2025 AFP survey of 362 finance professionals from around the world found that 96% use spreadsheets for planning and 93% for reporting — either daily or weekly. An AutoRek survey from the same year found that spreadsheets remain an integral part of financial operations in 90% of organisations.

In its own category, a spreadsheet has no real competition. One-off calculations, scenario modelling, or a question that needs an answer today — here, the cost of making a change is zero, and there is no waiting time. No system can replace that, nor should it.

The decision, then, isn’t “keep it or get rid of it,” but “which layer should it operate on?” The process belongs where validation, change history, and access control exist. The spreadsheet is where you ask questions of that process.

Usually, the question asked in this situation is whether the spreadsheet is still sufficient. The answer doesn’t tell us much, because a spreadsheet will always work — that’s precisely the problem. The real question is a different one: if this spreadsheet were wrong, how would we know?

If the honest answer is “the client would call,” “we’d find out at year-end,” or “someone would eventually notice,” then the decision has already been made — just not by the company, but by probability. A spreadsheet doesn’t stop being sufficient when an error appears in it. It stops being sufficient when a decision starts depending on it, and no one in the company can say whether it already contains an error.