ERP vs Spreadsheets: When a Business Actually Outgrows Excel
Spreadsheets fail in four specific ways as a business grows. Here is what each failure looks like, the signals that you have hit it, and what migrating costs you.
The question is not which has more features
Every comparison of ERP against spreadsheets is written by someone selling ERP, and they all make the same move: a feature table where one column is full of ticks and the other is mostly empty. It is not a useful way to decide, because a spreadsheet will out-feature an ERP on the thing spreadsheets are for, and the comparison tells you nothing about whether you have reached the point of switching.
The useful question is narrower. Spreadsheets fail in four specific, well-understood ways. Until you are hitting at least two of them regularly, an ERP will cost you more than it returns. Once you are hitting three, every month you wait is paid for in reconciliation work and errors nobody catches.
What spreadsheets are genuinely better at
Worth saying plainly, because it is the part the vendor comparisons omit. A spreadsheet is the best modelling tool ever built for a business. It is free-form, it is immediate, and it does not require anyone's permission to change shape. If you want to test a pricing scenario on Tuesday afternoon, nothing in an ERP will beat a blank sheet.
That strength is exactly the weakness at scale. A spreadsheet will let you do anything, which means it will let you do anything wrong, silently, and keep the result looking authoritative. The qualities that make it a superb scratchpad make it a poor system of record.
Failure one: there is no single version of the truth
The first copy is where it starts. Someone emails the stock sheet to a colleague who needs it on the road. Now there are two. One gets edited. A week later nobody can say which is current, so the question becomes a conversation rather than a lookup.
Shared cloud files help and do not solve it, because the problem is not file storage — it is that the same fact lives in several places at once. The customer's credit limit sits in the sales sheet and again in the collections sheet. A purchase order exists in the buyer's workbook and again in the finance workbook. Nothing keeps them equal except somebody remembering.
Failure two: there is no audit trail
A spreadsheet records the current state of a cell. It does not record that the figure was 4,200 until last Thursday, who changed it, or why. Version history in cloud tools gives you a partial answer at the file level, but reconstructing the history of one value across a year of edits is not realistic work.
This matters in three situations, and they tend to arrive together: an auditor asks you to substantiate a balance, a customer disputes an invoice, or a number moves and nobody can explain why. In a ledger, every figure is the sum of dated entries, each tied to a source document and a person. You answer by drilling down. In a spreadsheet you answer by remembering.
Failure three: concurrency
Two people working the same sheet at the same time is tolerable with modern co-editing. Two people working the same sheet in different places at the same time is not, and that is what happens as soon as anyone works offline, on a phone, or in a branch with poor connectivity.
The deeper version of this problem is not simultaneous editing but sequencing. Inventory is a running balance: it only means anything if movements are applied in order. When stock-in from a delivery note and stock-out from a shipment are keyed by different people into different copies, the on-hand figure stops being arithmetic and becomes an estimate.
Failure four: nothing enforces referential integrity
This is the quietest failure and usually the most expensive. A spreadsheet will happily let you record a sale against a customer who does not exist, a stock issue for a part number with a typo, or a payment against an invoice that was already settled. Nothing objects, because nothing knows the relationships.
A system of record refuses. You cannot post a goods receipt against a closed purchase order, you cannot allocate stock you do not have, and you cannot pay an invoice twice without a deliberate override that gets recorded. Most of the value of an ERP is in the operations it will not let you perform.
- Typo'd part numbers creating phantom SKUs that inflate your item master by hundreds of entries.
- Payments applied to the wrong invoice, found only when a customer queries their statement.
- Duplicate supplier records that split the spend and hide your real exposure to one vendor.
- Stock issued below zero, so the on-hand figure goes negative and every downstream calculation inherits the error.
The signals, in the order they usually appear
Roughly in sequence, these are what the four failures look like from the inside:
- Month-end takes longer than it did last year, and most of that time is reconciliation rather than analysis.
- One person is the only one who fully understands the workbook. Their holiday is a business risk.
- You have started keeping a spreadsheet whose job is to reconcile two other spreadsheets.
- Someone asks a simple question — what did we buy from this supplier last quarter — and answering it takes a day.
- An error reaches a customer: a wrong price, a double shipment, an invoice for goods never delivered.
One of these on its own is normal. Three of them together is the point where the arithmetic changes, because the cost of the workaround has quietly overtaken the cost of the system.
What you give up
Honest accounting of the other side, since the migration posts are rarely honest about it. You lose flexibility. A process that took ten seconds to change in a sheet now takes a configuration change and possibly a conversation. For a business whose processes genuinely change every month, that friction is a real cost, not a transition pain that passes.
You also pay in data cleanup, and it is almost always underestimated. Every duplicate customer, every inconsistent unit of measure, every part number with a trailing space has to be resolved before it can be loaded. That work is unavoidable, it is tedious, and it is the single most common reason implementations slip.
How to decide
Count the failures you hit in a normal month, not a bad one. If it is zero or one, keep the spreadsheet and spend the money elsewhere — you will get a better return from almost anything else. If it is two, start looking seriously but without urgency; you have time to choose well. If it is three or four, the decision has already been made for you, and the only remaining question is how long you keep paying the cost of not having acted on it.

