Skip to main content
Insights

Spreadsheets Are Not a Business System, and It’s Time to Say It Kindly

By November 13, 2026No Comments

Let us begin with the kindness, because it is genuine and it should be said before anything critical.

Spreadsheets are one of the most useful tools ever handed to a small business owner. They are cheap, they are fast, they forgive you for not knowing what you want to track yet, and they let you build something working in an afternoon that would have taken a developer a month. If you have ever turned a chaotic pile of customer information into a tab that finally made sense, that was a real achievement. Nobody should talk down to you for it.

Here is the thing I would like to say anyway, gently and clearly: a spreadsheet is not a business system. It is a very good document that has been asked to do a job it was never designed for. And the moment your operation depends on it – not reports on it, but depends on it, the way a water main depends on nothing else being in the way – the moment that happens, the spreadsheet starts costing you money in ways that never show up on any tab.

This is not a pitch to delete every workbook you own. It is a pitch to demote the spreadsheet to the role it is actually excellent at, and to give the running of your business to something built for running things.

How a Business Ends Up Running on a Spreadsheet

It almost never happens on purpose. There is no day when you decide to found your company on a file called MASTER_v7_FINAL_USE_THIS.xlsx. It happens one small reasonable choice at a time.

You start with one tab for clients – fine, it is a list, and lists are what spreadsheets are for. Then a colleague adds a column for job status, because the real job board is in your head and the head is full. Then invoice amounts get pasted next to it, because the accounting package does not talk to the client list. Then a summary tab appears so you can see the month at a glance, and the summary tab becomes how you make decisions. Then someone duplicates the file to work offline, and the duplicate becomes the one they trust, because it is the one they updated.

At no point in that sequence was a bad decision made; each step solved the problem in front of you. But by step six you have an operating system with no access control, no validation, no audit history, no defined states, and no single source of truth – and you have been too busy to notice, because you were too busy keeping it upright. Practitioners call this the spreadsheet-as-database pattern, and it is the most common accidental architecture in small business. The CFO Connect 2025 survey of 253 finance leaders in Europe and the US found 71% of companies still depend on spreadsheets for financial planning, citing complexity, cost and change management as the reasons better tools never got adopted. Tech Times ran that finding into a wider 2026 point: plenty of companies still run genuinely critical operations on sheets, not because anyone chose to, but because nobody ever had to decide.

The Actual Difference Between a Document and a System

The distinction is simpler than it sounds. A document records; a system runs. A spreadsheet is a recording surface. It holds what you type into it, and it will hold wrong things with the same enthusiasm as right things.

A system is a set of rules with data attached. It decides what is allowed, it enforces it, and it refuses what is not. It knows the difference between a customer, a job and an invoice, and it will not let you create an invoice for a job that does not exist. It knows who did what and when. It can trigger the next piece of work without a human remembering to.

Put it in operational terms: a spreadsheet tells you what the situation was at the moment someone last typed; a system tells you what the situation is, because it is the thing the situation is stored in. A spreadsheet relies on people following the convention; a system relies on the rule, which is what you want when the person doing the work is new, rushed, or you. A spreadsheet is edited by whoever has the file; a system is operated by whoever has the permission.

None of this is a judgment on spreadsheets. Excel is a magnificent analysis tool. But analysis and operation are different jobs, and one file doing both is where trouble starts.

What It Costs You When a Recording Surface Runs the Business

Here is where the numbers come in, because this is not folklore – it is one of the most studied problems in business computing. Raymond Panko’s work for the European Spreadsheet Risks Interest Group is the standard reference, and his summary of the inspection studies is not subtle: across six studies covering 85 operational spreadsheets, errors were found in 94% of them. Per-cell rates are low, often 1 to 5% at best, which sounds survivable until you remember that a single wrong cell can be the bottom line. The survey paper “What We Don’t Know About Spreadsheet Errors Today” agrees on all of it: errors are rare per cell, nearly certain in a large model, and extremely hard to find or fix.

If you want the scale of what that has cost, two examples do the pointing. In 2010, the economists Carmen Reinhart and Kenneth Rogoff published the paper that gave policymakers a tidy -0.1% average growth figure for countries carrying debt above 90% of GDP, cited in defense of austerity across the Western world. When Herndon, Ash and Pollin tried to replicate it, they found a spreadsheet coding error. Corrected, the average for those same countries was +2.2%. The arithmetic mistake was in a spreadsheet; the policy consequence was not. In 2012, JPMorgan Chase’s “London Whale” positions produced losses above $6 billion, and the Senate Permanent Subcommittee on Investigations documented a risk model in a spreadsheet with a flawed formula – a divisor that should have been an average was a sum – which understated the risk by roughly half and went unnoticed for months. They had some of the most sophisticated risk systems ever built, and a spreadsheet in the middle of it, quietly disagreeing with reality.

You are not making billion-dollar trades, but the mechanism is identical, and the small version is the one that hurts: an invoice column that stops summing because a row was inserted above it, a pricing sheet where someone typed a space instead of a digit, a status column where “done,” “Done” and “closed” are three different things to three different people. These are not errors of competence. They are errors of medium.

There is a second cost that never appears on a spreadsheet because it is the spreadsheet: the labor of keeping it alive. Re-keying the same customer into three files, reconciling two versions, double-checking the total before trusting it, being the person everyone calls because you know which sheet is current. In most small businesses that is booked as general administration rather than as what it actually is – unpaid software maintenance.

Six Signs Your Spreadsheet Has Become the Business

You can feel this before you can measure it. Here are the telltales, roughly in the order owners notice them.

  1. More than one person has a copy. The moment the same data exists in two places, you have an argument waiting to happen, and the only referee is whoever notices first. File naming becomes a folk tradition: FINAL, FINAL v2, DO NOT USE THIS ONE.
  2. The file has a guardian. Someone is the keeper of the spreadsheet. They know the quirks, which tabs are live, what not to touch. That person is now a critical dependency with no backup.
  3. You are afraid to restructure it. A formula in the depths refers to a cell you would rather not discuss, so you leave the old columns in place. The file has grown load-bearing struts nobody can see.
  4. Status lives in your head; the sheet only reflects it afterwards. The tab is updated after the thing happened, by whoever remembered. It is a diary of your business rather than an instrument panel.
  5. Reporting is manual and monthly. Building the numbers takes half a day, so you do it monthly, so you learn things monthly, so by the time you learn them the decision has already been made by instinct.
  6. Nobody can say who did what. When a figure is wrong, there is no way to find when it changed, who changed it, or what it said before. You can detect a problem but you cannot investigate it.

If three or more of those are familiar, your spreadsheet is no longer a spreadsheet. It is an application, being run badly, by people, at your expense.

The Fair Rebuttal: Where Spreadsheets Stay Excellent

It would be dishonest to say “stop using spreadsheets,” and it would be a bad sale: you will keep using them for years. They are genuinely the right tool when:

  • The question is still forming. You do not yet know what you want to track, and a sheet is the cheapest way to run an experiment. This is why you should use sheets early and move late.
  • The work is analysis, not operation. Ad hoc what-ifs, scenario planning, a quick margin calculation, sorting a messy export for one afternoon decision. This is what spreadsheets were built for and they remain close to unbeatable.
  • The volume is small and the people are few. One owner, a handful of records, nobody else touching it. A sheet is fine here. Premature system-building is a real failure mode too – owners have bought software to manage a business that fits comfortably in a head.
  • It is a presentation, not a record. A chart for a lender is not a problem, as long as the numbers in it come from a place that is the truth.

So the rule is not “no spreadsheets.” The rule is one sentence, and it is the whole argument of this article: a spreadsheet should never be the only place a fact lives. The moment a piece of information has to be relied on by the business – used to schedule, bill, pay, order, promise, or decide – it needs to live in a system, and the sheet may sit downstream of it.

What a Real System Actually Is

Owners hear “system” and picture either an enterprise rollout with a consultant in a lanyard, or a spreadsheet with more columns. Neither is what I mean. A business system has five parts, and you can check any tool you are evaluating against them.

  • A structure for the things your business is about. Not rows and columns, but entities: customer, job, appointment, part, invoice, subscription. Each is one object with one identity. You cannot create a job without saying whose it is, and the system knows when you try.
  • Rules about what may happen. Allowed states and allowed transitions. A quote cannot become an invoice without a decision. A price cannot go below your floor without someone’s approval. Overlapping bookings cannot be saved. The rule is enforced by the software, which is the difference between a rule and a wish.
  • One copy, many views. Everybody looks at the same record through the view that matters to them – the technician sees today’s jobs, you see the week, your accountant sees the month. The views are cheap; the copy of the data is one.
  • Permissions and history. The right people see and change the right things, and every change leaves a trace: who, when, from what to what. That trail is not surveillance; it is what lets you investigate a mistake in thirty seconds instead of losing a day to “I thought you had it.”
  • Connections and triggers. Work flows between steps without a human carrying it. Completing the job creates the invoice. The unpaid invoice at day 8 sends the reminder. The signed form files itself into the record.

“But I Already Have Software” – The Shadow IT Problem

Many owners will read this and reply: I do have software. I have the scheduling tool, the accounting package, the abandoned CRM trial, the form tool, and a project board.

That is usually where the spreadsheet comes back – not as the primary tool, but as the glue. The customer record lives in three systems and the sheet is the only place they agree. The invoice is in accounting, the job is in scheduling, and they do not describe the same work, so someone reconciles them by hand. That unofficial layer is what people mean by shadow IT: it exists because the official tools were never designed to meet. The industry has noticed – Gartner projected that by 2025, 70% of new business applications would use low-code or no-code tools, up from under 25% in 2020, with a majority of custom apps now built outside IT departments. Good for owner agency; a warning about architecture. When every gap gets filled with a new tool or a new sheet, the gaps are not gone – they are just more numerous and harder to see.

If your business runs on five subscriptions and one spreadsheet that connects them, you have not bought software. You have bought five pieces of a system and taken the assembly job yourself.

The Kind Way to Move: Demote, Do Not Delete

Pick one thing your business genuinely depends on – usually customers, jobs, or money owed. Put that one object in a place with structure and rules, and let everything else follow. The spreadsheet you love stays; it stops being the source of truth and becomes what it should have been all along: a view of the truth, generated automatically, for you to think with. That one change kills version conflicts, ends the re-keying, and makes the numbers trustworthy at the moment you stop having to check them.

Three notes for doing it without regret:

Define before you build. A spreadsheet forces nothing, which is why it lets you stay vague for so long. The first act of system work is writing down what your business actually consists of: what counts as a job, what the statuses mean, what your pricing rules are, who may change what. It is not software work. It is thinking work, and owners describe it afterwards as the most valuable half of the project.

Buy for the ordinary, build for the reason. If a part of your operation is standard for your trade, an off-the-shelf tool probably handles it better and cheaper than anything custom; use them without guilt. A custom build earns its keep where the workflow is why customers choose you: your intake questions, your pricing logic, your service tiers, the records your team needs to do good work. A subscription rents somebody else’s assumptions about your industry, forever. A system you own is a one-time build plus maintenance, and every process you later standardize can sit on top of it.

Expect the second month, not the first. Nothing that fixes data plumbing shows up in week one. The honest pattern is friction during the switch, visible time savings by week four or five, and compounding gains over the following quarters – faster onboarding, cleaner reporting, taking on a job type you used to refuse. Any provider who promises otherwise is selling you something else.

The Acherus Take

The uncomfortable part of this article is not the criticism of spreadsheets. It is that a spreadsheet used as a system is invisible. It does not arrive with an invoice, a login fee or a renewal email, so it never gets evaluated. It just sits there absorbing hours, and those hours leave the business as slightly slower responses, slightly worse margins, and an owner who is the only person who really understands how it all works.

We build software for small and growing service businesses, and a large share of our work begins exactly here: a client who has been sensibly getting by on sheets and has now outgrown them in a way they can feel but not name. The first thing we do is almost never write code. It is name the objects, write the rules, and find the places where a person is currently doing what a system should do. Then we build only what is needed to carry the load, often integrating with the tools already in place rather than replacing them.

If you take one idea from this, take the demotion, not the ban. Keep the spreadsheet for thinking. Move the truth into something that enforces it. That is the difference between a business that is documented and a business that runs.

Frequently Asked Questions

Is a spreadsheet really worse than software I would have to pay for? For analysis, no. For operating the business, usually yes – but the comparison is not the subscription price. It is the subscription price versus the hours spent maintaining, reconciling and protecting the sheet, plus the decisions made on numbers that were quietly wrong.

We are a small business with three people. Is this overkill? Possibly, and overkill is a real risk in the other direction too. At that size the deciding question is volume and repetition, not headcount. If the same five tasks happen daily and the data has to be right the first time – billing, scheduling, promises to customers – structure pays. If it happens twice a month and you are the only one who sees it, keep the sheet.

Can I not just build a better spreadsheet? You can push one a long way – data validation, named ranges, protection, pivot tables, even scripts – and it will keep working up to a point. What it never gains is referential integrity, a reliable permission model, real audit history, or the ability to enforce a workflow instead of reminding people of it. Those are architectural properties, not features.

How do I know which single thing to move first? Pick the fact that causes the most arguments. Whichever number people dispute, whichever status is unclear, whichever record is duplicated – that is the object to put in a system. Removing the arguments is feedback owners notice immediately, and it makes every later step easier.

About Acherus Inc.

Acherus is a software company that builds practical, well-engineered tools for small and growing businesses. We help owners and operators pick and implement the technology that actually fits how they work, so the software saves time instead of creating a new job.

© 2026 Acherus Inc. All rights reserved. This article is provided for general informational purposes and does not constitute professional advice. Prices and features are approximate and subject to change. Confirm details with each vendor before purchasing.

Elizabeth

Elizabeth is a tech writer who translates real-world business challenges into custom software strategies. Welcome to Acherus insights!