The Riskiest System in Your Business Might Be a Spreadsheet Only One Person Understands

The spreadsheet nobody budgeted for

Every SMB has one: a spreadsheet that started as someone's personal tracker and quietly became the system a department actually runs on. It calculates commission payouts, tracks inventory reorder points, reconciles vendor invoices, or builds the weekly numbers that go to leadership. Nobody procured it. Nobody signed off on it as critical infrastructure. It just accreted, formula by formula, until the day it broke and someone realized how much depended on it.

This isn't a story about Excel being bad software. Excel is excellent software, and for a huge share of business logic it's the right tool — fast to build, easy to edit, and something most of your staff already knows how to use. The problem isn't the tool. It's that a spreadsheet can become mission-critical without ever being treated as mission-critical, and nobody notices the gap until the person who built it is unavailable or the formula turns out to have been wrong the whole time.

Two famous failures, and why they generalize

In 2012, JPMorgan's "London Whale" trading losses — which ran into the billions — were compounded by a risk model built on a chain of Excel spreadsheets that staff had to fill in by copying and pasting data between sheets by hand. An internal review found that one formula divided by the sum of a set of rate changes instead of their average, which understated the risk measure (VaR) by roughly half. Lower reported risk meant the desk was allowed to keep growing a position that was already going wrong.

A year later, a graduate student trying to replicate an influential academic paper — "Growth in a Time of Debt," by economists Carmen Reinhart and Kenneth Rogoff, widely cited in debates over austerity policy — discovered that the underlying spreadsheet's averaging formula covered the wrong row range, silently dropping five countries from the calculation. Once corrected, a key result the paper was known for reversed direction.

Neither failure was a software bug. Both were a wrong formula that nobody caught, sitting inside a tool with no audit trail, no review process, and no way for anyone besides the author to verify it was doing what they thought. Scale that down from a bank's trading desk or a widely cited paper to a 20-person business, and the mechanism is identical — only the size of the headline changes.

Why spreadsheets fail silently, not loudly

A piece of software with a bug usually throws an error or produces an obviously wrong result. A spreadsheet with a wrong formula usually produces a plausible-looking number that's simply incorrect, and plausible-looking numbers don't get double-checked. There's no test suite verifying a cell reference still points where it should after someone inserted a row above it. There's no code review before a formula gets changed. There's no version history worth trusting once three people have each made "quick fixes" over two years.

The actual risk isn't that your team is bad at spreadsheets. It's that spreadsheets, by design, have none of the guardrails that catch this class of error before it reaches a decision.

The signals it's gone from tool to infrastructure

A few concrete tells that a spreadsheet has crossed the line from personal productivity tool to unmanaged business system:

One person is the only one who fully understands it. If that person is out sick, changes roles, or leaves, nobody else can confidently modify — or even fully trust — the file. That's a bus-factor-of-one risk sitting on a process the business depends on every week.

It drives a number leadership acts on. Payroll, pricing, inventory reorder decisions, financial reporting — if a wrong number in this file changes a real decision, it has graduated from a tracking tool to a system of record, whether anyone formally decided that or not.

Nobody can tell you when it was last verified. Not "when was it last updated" — when was a formula actually checked against the real-world number it's supposed to represent. If the honest answer is "we don't know," you have no way of knowing whether it's been quietly wrong for months.

It's grown past what one person can review in an afternoon. Nested formulas referencing other formulas referencing other tabs, built up over years, are exactly the shape of file where a single bad cell reference hides indefinitely.

What to actually do about it

The fix isn't "stop using spreadsheets" — most of them are fine exactly as they are. The fix is noticing which ones have quietly become load-bearing and treating those differently:

• Have someone who didn't build it try to verify a result from scratch. If they can't, independently, confirm the output is right, neither can you.
• Separate the inputs from the logic. A lot of spreadsheet risk comes from hand-editing a cell that's also referenced by six other formulas. Locking down which cells are meant to be touched, and by whom, removes most of the accidental-breakage cases.
• Put a second set of eyes on any formula change before it goes live, the same way you'd want a second person checking a change to a production system — because for the business, it is one.
• When a spreadsheet becomes the actual system a department runs on — not just where they track things, but what they'd be stuck without — treat migrating its logic into a real, tested, auditable internal tool as a scoped project, not an emergency to handle only after it's already broken.

The takeaway

The riskiest software in a lot of SMBs isn't a SaaS vendor's app — it's the spreadsheet nobody classified as a system in the first place. If a specific file is quietly deciding payroll, pricing, or inventory, and only one person could tell you with confidence whether its formulas are still correct, that's worth fixing before it fails the way JPMorgan's and Reinhart-Rogoff's did: silently, convincingly, and in a place nobody was looking.