When Your Inventory Spreadsheet Stops Working

A spreadsheet does not stop working on a particular Tuesday. Every number in it was accurate the moment it was typed, and it keeps displaying with exactly the same confidence after it stops being accurate. That is the whole failure mode, and the four sections below are four versions of it.

This post is a diagnostic. It is not an argument that you should buy something, and it deliberately does not price the alternatives. It also stays inside the file: for the symptoms that show up elsewhere, in your sales data, your buying process and your cash position, ten signs a store has outgrown manual forecasting is the checklist.

Where the spreadsheet starts fine

For a small catalog, a spreadsheet is a good inventory tool, not a compromise you should feel behind for using. It costs nothing. Every number in it is one you calculated yourself, so there is no dashboard between you and your own reasoning. You can add a column for anything, including the things no software models: a supplier who is reliable in March and not in November, a product you are quietly discontinuing, a customer who buys in bulk twice a year.

With a few dozen products, one supplier and one location, a monthly review in a spreadsheet catches everything worth catching. Nothing below contradicts that.

What follows are four things a spreadsheet structurally cannot do, arranged in the order they usually start to matter. They accumulate. By the time the fourth one shows up, the first three are still there.

Failure one: velocity goes stale

Somewhere in the file is a units-per-day column. Every other calculation depends on it: the reorder point, the weeks of cover, the suggested order quantity. It is also the only column that changes every single day and the one refreshed by hand least often.

When you typed 5 units a day, it was right. The product now sells 11. Nothing in the file objects. The formulas run, the reorder point still displays as a clean number, and the sheet looks exactly as it did when it was correct. You find out at the point the shelf is empty and the delivery is a week out.

This one arrives first because it needs nothing but a single product changing pace, which can happen at any catalog size. The obvious fix is to recompute velocity more often, and it works, right up until the recompute takes longer than the interval between meaningful changes. Deriving demand from your own Shopify sales data covers what a defensible velocity figure actually requires, which is more than an average of the last 90 days.

Failure two: nothing fires an alert

A spreadsheet is a pull system. It is only true when you open it. You can have a perfect reorder point in column F and still run out, because nothing carries the crossing of that number from the file to your attention.

This is the failure that is easiest to underestimate, because the file is not wrong. Every calculation in it is correct. The gap is entirely in delivery, which means no amount of improving the spreadsheet closes it. Conditional formatting turns the cell red, and the cell is still only red when someone is looking at it.

Shopify's own low-stock badge has the same shape: it is a filter you visit, not a message you receive. The free native route to an actual notification is a Shopify Flow workflow, and the setup for both is covered in the guide to Shopify low stock alerts. It arrives second because it needs only enough products that you can no longer hold the review in your head between openings of the file, and once the catalog is large enough that no review covers all of it, planning by exception across a high-SKU catalog is the operational problem that replaces this one.

Failure three: committed stock is invisible

A spreadsheet holds one number per product. Shopify holds several distinct quantities per variant, and they are not interchangeable. Whichever one you imported or typed becomes the sheet's entire notion of "how many we have".

Almost everyone carries on-hand, because it is the number that matches what is physically in the room. On-hand includes units already committed against orders you have not shipped yet. So a wholesale order or a run of pre-orders reserves 40 units that are still sitting on the shelf, still counted in your sheet, and no longer sellable. The sheet says you have two weeks of cover and the storefront says sold out. Incoming stock creates the mirror-image error: units on an open purchase order are not on hand, so a sheet built on on-hand will happily recommend ordering them a second time.

Those quantities, what each one means and what moves them, are explained properly in how Shopify inventory tracking works. The point for a spreadsheet is narrower: it has one slot and the platform has several, so the reconciliation has to happen in someone's head every time the file is updated. This is the failure that needs a particular kind of growth rather than more of it. A store selling one channel, no pre-orders, no wholesale, may never meet it.

Failure four: version drift

The moment a second person can edit the file, or one person edits it from two machines, or a monthly copy is taken as a backup, there is more than one version of the truth and no reliable way to tell which is current. A shared cloud sheet solves the copies and not the drift.

The specific damage is that a manual override is indistinguishable from a calculation after the fact. Someone types 200 over a formula because they know a shipment is coming. Three weeks later the cell reads 200 and looks exactly like every other cell on the row. There is no record of who set it, when, or why, so the only way to audit the file is to re-derive it. When a count and a record disagree, the question is always what changed and when, which is the question a spreadsheet is least equipped to answer; preventing inventory discrepancies covers what that investigation actually involves.

It arrives last for a mundane reason: most stores add a second person to the buying process later than they add products, order types or channels.

The point it stops being worth fixing

Each of these has a fix that lives inside the spreadsheet. A scheduled export or a live connection keeps velocity fresh. A calendar reminder half-solves alerting. Importing available rather than on-hand handles committed stock, until you also need incoming. Locked cells, a change log and one owner reduce drift.

They all work. Every one of them also adds something the spreadsheet now needs you to maintain, and the maintenance is the cost you were avoiding by staying on a spreadsheet in the first place.

So the useful test is not a product count. It is this: are you spending time keeping the tool correct, rather than using the tool to make decisions? A spreadsheet that needs a weekly hour of upkeep before it can be trusted has quietly become a system to administer. That is the moment the comparison is worth running, and comparing manual upkeep against automated recalculation is what automatic versus manual reordering is for. Deciding is a separate exercise from diagnosing, and this post is only the diagnosis: the spreadsheet versus planning software decision has the gates, what each side actually costs, and the cases where staying on the file is the right answer.

One disclosure, since we make an inventory app: StockCue is one of the options in that comparison, and its Free plan covers 50 SKUs, which is enough to check its numbers against your own sheet before deciding anything.

Frequently Asked Questions

Why does an inventory spreadsheet stop working as a store grows?

Because a spreadsheet records what was true at the moment someone typed it and has no mechanism for noticing that it has stopped being true. Sales velocity moves, orders commit stock that is still physically on the shelf, and a second person edits a second copy. Every cell still displays and every formula still calculates, so the file gives no signal that its inputs have gone out of date.

How many SKUs can you realistically track in a spreadsheet?

There is no fixed number, and product count is a weaker predictor than it looks. This site's reorder point guide puts the practical ceiling for a spreadsheet with a monthly review at roughly 30 SKUs, which is a reasonable starting figure. A catalog of 15 volatile products with three suppliers and a wholesale channel will outgrow a spreadsheet sooner than 60 steady products with one supplier and one sales channel.

Can a spreadsheet account for committed stock?

Only if you deliberately import the available quantity rather than the on-hand quantity, and keep importing it. Shopify tracks several distinct quantities per variant, and a spreadsheet almost always holds one number per product. If that number is on hand, it silently includes units already reserved against unfulfilled orders, so the sheet reads higher than what a shopper can actually buy.

What breaks first in an inventory spreadsheet?

Sales velocity, usually. It is the input that every other calculation depends on, it changes daily, and it is refreshed by hand least often. It also fails silently: the reorder points and cover figures downstream of it keep calculating and keep looking correct, they are just answering a question about a store that no longer exists.