T R U F F A I R E
← Blog
Enterprise7 min read

The Real Cost of Running on Spreadsheets

Spreadsheets are the most successful business software ever written, which is why operations outgrow them without noticing. Here are the specific signals that the cost has turned.

T

Truffaire

20 August 2026

Spreadsheets are the most successful business software ever written. They are free or nearly so, everyone can use one, they impose no process, and they will hold whatever you put in them.

Those same properties are why businesses outgrow them without noticing. A tool that never refuses anything never signals that it has stopped being appropriate. There is no error message for "this is now too important to be a spreadsheet."

This article is about identifying that moment — the specific signals that the cost has turned — and about what to do first when it has. It is not an argument that spreadsheets are bad. For a large share of businesses they remain the correct answer.

Where spreadsheets are genuinely the right tool

Worth stating clearly, because the alternative is usually being sold to you.

Spreadsheets are excellent for modelling — asking what-if questions, building a projection, testing a scenario. Nothing replaces them for thinking with numbers.

They are excellent for one-off analysis, where the structure is temporary and the work ends.

They are excellent for low-volume records that one person maintains and consults — a list of suppliers, a fixed price sheet.

The common factor: one author, bounded lifespan, no dependency on being current.

The four properties that make them fail as systems

A spreadsheet becomes a liability when it stops being a document and starts being infrastructure. Four specific properties cause that failure.

No concurrency

Two people cannot reliably maintain one truth. Cloud sheets improved this and did not solve it — simultaneous edits still overwrite, and the file that circulated by email or chat has forked into versions with no way to tell which is current.

The moment a second person needs to write, the spreadsheet is doing a job it was not built for.

No validation

A cell will accept anything. A date typed in the wrong format, a quantity with a stray digit, a product name spelled two ways — all accepted silently, all corrupting every total that depends on them.

This is the property that makes spreadsheet errors so expensive: they are invisible until a number is used for a decision, and by then the source is buried.

No audit trail

Who changed this figure, when, and what was it before? A spreadsheet cannot answer. When a number is wrong, you can correct it but you cannot reconstruct how it went wrong — which means you cannot stop it happening again.

No relationships

A spreadsheet holds a table. It does not know that this sale reduces that stock, which affects that supplier order. Those connections live in the head of whoever maintains it, and are performed manually every time.

This is the property that produces the real cost, because it means the same information gets entered repeatedly in separate places.

The signals that the cost has turned

Not opinions — observable conditions. If several of these are true, the spreadsheet has become the constraint.

Somebody's job is now the spreadsheet. Not using it — maintaining it. When a person spends meaningful hours keeping a file current so others can rely on it, you are paying a salary for what software does automatically.

There is a version problem. Files named "final", "final v2", "final updated". Someone has to determine which is current before anyone can work.

Nobody fully trusts it. People check the sheet, then check something else to confirm. That second check is the tell — it means the record is not authoritative, and everyone knows it.

Only one person understands it. The formulas made sense to their author. If that person is unavailable, the operation slows or stops. This is a genuine business continuity risk, not an inconvenience.

The same figure is entered more than once. Sales into one sheet, stock into another, invoices into a third. Every duplicate entry is a place where the copies drift apart.

Decisions are made on stale numbers. The sheet was accurate when last updated. Nobody is certain when that was.

It has become slow or fragile. Files that take a minute to open, or crash, have exceeded what the format supports. This one is unambiguous.

One is fine. Three is a decision.

Any single signal is manageable. Three or more compounding is how businesses find themselves reconstructing a quarter from bank statements.

What migration actually involves

Businesses postpone this because they imagine it means replacing everything simultaneously. It does not, and it should not.

Start with the sheet that hurts most. Usually stock or receivables. One process, moved properly, teaches you more about the real requirements than any specification exercise.

Expect the data to be messier than you think. This is the part that surprises everyone. Years of accumulated records contain duplicate entities spelled differently, missing fields, and rows nobody can explain. Cleaning is a real phase, and any plan treating it as a formality will slip.

Run both in parallel briefly. Keep the spreadsheet updated alongside the new system until the figures agree for a full cycle. Duplicated effort for a few weeks is cheap insurance against discovering a gap after the sheet is gone.

Keep the modelling. Moving records into a system does not mean abandoning spreadsheets. Export the data and model in a sheet — that is what it is genuinely best at.

What we have seen

Across the ten systems we have delivered, undocumented spreadsheet logic is consistently the largest source of timeline risk — more than any technical requirement.

The pattern repeats: a business describes its process, we sit with the person who actually maintains the file, and the real process includes six exceptions that live in the formulas and one that lives in that person's judgement. None of it appears in a requirements document, because none of it is written down anywhere.

That is why our first phase is documenting the operation as performed rather than as described. The spreadsheet is the specification — it encodes years of decisions about how the business really works, including the parts nobody remembers making. The method is in how Truffaire builds software.

The corollary: if you are considering this, the most valuable preparation is having whoever maintains the sheet walk someone else through it, including every exception. That document is worth more than a vendor comparison.

Frequently asked questions

Can we not just use a better spreadsheet tool?

Better tools improve concurrency and validation, and for some operations that is sufficient. They do not add relationships or a genuine audit trail. If your problem is that the same figure lives in four files, a better spreadsheet gives you four better files.

How long does migration take?

The engineering is rarely the constraint. Data cleaning and undocumented logic are. A business with consistent records moves in weeks; one where the real process lives in formulas and habits takes longer, because that has to be surfaced first.

What if our process is genuinely unusual?

It may be — or it may be vocabulary. Off-the-shelf or custom covers how to tell the difference, which decides whether you configure or build.

Will we lose our history?

You should not. Historical records migrate, and this is a substantial part of the work. Any plan that treats history as optional is worth questioning — it is usually where the trend analysis you actually want lives.

Is it worth it for a small business?

Often not yet. If one person maintains the sheet, nobody else depends on it being current, and it is not slow, the spreadsheet is doing its job. Move when the signals above appear, not before.

Where to start

Do not begin by evaluating software. Begin by listing every spreadsheet the business depends on, who maintains it, who reads it, and what breaks if it is wrong.

That list usually answers the question by itself. A handful of files with single owners and no downstream dependency means stay. Files that several people depend on, that someone maintains as a job, that others cross-check before trusting — that is infrastructure, and it should be treated as such.

What a business operating system actually is covers what replaces it, and where multi-outlet businesses lose money covers what this costs once there is more than one location. If you want a read on whether you are past the threshold, get in touch.

More in Enterprise