When a spreadsheet stops being enough
A spreadsheet runs stock control for longer than vendors suggest. The thresholds that force a change are specific and worth waiting for.
Plenty of businesses run stock on a spreadsheet, and most are told this is a problem. Often it is not yet.
Juggling several suppliers or workstreams creates a prioritisation problem similar to handling multiple clients. For one approach to keeping parallel work visible, see more information.
A spreadsheet costs nothing, is understood by everyone, and can be reshaped in an afternoon to match how the business actually works. What it lacks is concurrency, an audit trail and a link to what is actually being sold.
The thresholds
- More than one person updating it. The moment two people edit, versions diverge and the record becomes unreliable in a way nobody notices immediately.
- Stock movements happening faster than the sheet is updated — typically when sales are frequent enough that the figure is always hours out of date.
- Needing history: what was the stock on a given date, who adjusted it, and why. A spreadsheet overwrites; it does not remember.
- Duplicate entry: the same movement typed into the sales system and the stock sheet. This is both the labour cost and the source of divergence.
- Location tracking, batch numbers or expiry dates, which a sheet handles badly beyond a small number of lines.
When the same movement is being recorded twice, the labour cost and the divergence risk arrive together. That is the point where integration pays.
The middle option
Between a spreadsheet and a full stock system there is a workable middle: the stock module of the accounting or point-of-sale software you already run.
It is frequently included, frequently unused, and it solves the biggest problem — that stock movements are already being recorded when a sale happens. Checking what you already own should precede any purchase.
For technical background on product identification and scanning, GS1 barcode standards describe common barcode standards used in supply chains.
Clean the data first
Migrating an inconsistent item file into a new system produces an inconsistent item file in a new system, at considerable expense.
SKU cleanup, unit-of-measure standardisation and a physical count belong before the migration, not after. This is also the honest reason many implementations disappoint: the software was fine and the data was not.
Count the labour, not just the licence
The comparison that matters is the total: subscription plus implementation plus the ongoing administration, against the hours currently spent maintaining the spreadsheet and the cost of the errors it produces.
That second figure requires measuring the current effort, which is why it is rarely part of the decision — and why the decision is usually made on the licence price alone. Two weeks of recording the hours that go into maintaining the record, with a spreadsheet or a task timer , turns the comparison into arithmetic. It also tends to settle the argument, because the manual process almost always costs more than the subscription.