The spreadsheet was fine when it was two hundred lines. Now it is four thousand, three people edit it, and the number on screen has not matched the shelf since roughly March. Somebody suggests inventory management software and the search returns four hundred products, all of which claim to do everything.
For ordinary stock, buy. The products are mature, cheap and better than anything worth building. What this article is actually about is the four things that break a bought product, because if one of them describes you, no amount of comparing features will help and you will find out expensively.
Why the spreadsheet fails, specifically
Worth naming, because the failure is not carelessness and understanding it tells you what to replace it with.
- Nobody knows when it was last right. There is no record of who changed a number or why, so a discrepancy cannot be traced, only argued about.
- Two people edit and one wins. Either you serialise access by messaging each other, or you lose changes quietly.
- Nothing enforces the rules. Negative stock, a code typed three ways, a decimal in the wrong place. A spreadsheet accepts all of it cheerfully.
- Movements are not recorded, only balances. You know you have eleven, not that fourteen arrived and three went out, which is what you need when the count is wrong.
- It cannot be in two places. The person on the shelf with a phone and the person at the desk are looking at different truths.
What ordinary stock needs, and what it costs
If your stock is countable units that arrive, sit somewhere and leave, a bought product covers it comfortably. What you are looking for:
- Movements rather than balances, so every change is a recorded event with a person attached.
- Barcode scanning on a phone, because typing codes is where the errors come from.
- Purchase orders and receiving, so incoming stock lands against what you ordered.
- Reorder points, which is the feature that actually saves money by stopping you running out.
- A stock count that reconciles rather than overwrites, so you can see what the discrepancy was.
- A connection to your accounting, which is a named cost rather than a checkbox. More on this below.
Illustratively, $50 to $400 a month for a product that does all of that, plus a few days of setup to get your data in and your people trained. Against a spreadsheet that is costing you stockouts and arguments, that is not a difficult decision.
Where inventory management software stops working
This is the part worth reading carefully, because every one of these is a case where a product will look fine in a demo and fail in month three.
| The complication | Why products struggle | What usually happens |
|---|---|---|
| Batches and expiry | Stock is not interchangeable. You need to know which batch, when it expires, and to pick the oldest first. Many products treat a unit as a unit. | Look specifically for batch or lot tracking with expiry, and test it with your real rules. Food, cosmetics, pharmaceuticals and anything regulated live here. |
| Serial numbers | Every item is individually identified and traceable to a customer, for warranty, recall or service history. | Supported by fewer products than claim it, and often only shallowly. Test the whole journey from receipt to return. |
| Stock you own that is somewhere else | Consignment, kit held by field engineers, samples with reps, goods at a customer site. It is yours, it is not in your building, and it still has to be counted. | Genuinely rare in off-the-shelf products. This is the most common reason we end up building something. |
| Made to order, or assembled | You hold components and sell things that do not exist until someone orders them, so stock is a calculation rather than a count. | Needs a bill of materials and light manufacturing features. Products that have them are a different and more expensive category. |
In the archive this came up repeatedly in exactly these words: a medtech business needing batch tracking and rep-held stock, and an owner pointing out that their accounting package could say how much stock they had but not which batch.
The accounting connection is a real cost
Everybody assumes this is a checkbox and it is a decision with consequences.
You have to agree what flows and in which direction: whether purchase orders create bills, whether shipments create invoices, whether stock value posts to the ledger and how often. Get it wrong and your accountant finds out at year end, which is the worst possible time.
Two practical warnings. First, the connection is much easier if your accounting is a modern online package than a desktop one, and that difference can be larger than the difference between two inventory products. Second, decide who owns stock valuation, the inventory system or the accounts, and never both. Connecting QuickBooks to everything else covers the mechanics, and our systems do not talk to each other covers choosing the master.
Buy, extend or build
| Route | Cost | Right when |
|---|---|---|
| Buy a product | $50 to $400 a month, plus a few days of setup | Countable units, one or two locations, standard movements. The large majority. |
| Buy and extend | The above plus $8,000 to $30,000 | The product fits except for one thing, usually a report, a portal for customers, or a connection nobody offers. |
| Build | $40,000 to $120,000, plus 15 to 25 per cent a year | One of the four complications above genuinely applies and no product handles it, or stock is the heart of how you compete. |
Illustrative ranges from the kind of work we quote, not a price list. The middle row is the one nobody offers you, because it is a smaller sale than a build and not a sale at all for a product vendor.
The stock count, and why yours is wrong
Worth its own section, because it is the thing people expect software to fix and software only half fixes.
A system tells you what should be on the shelf given everything it was told. The shelf tells you what is there. These disagree, always, and the gap is not a software failure, it is theft, damage, mis-picks, unrecorded samples, and things put back in the wrong place. What good software changes is that you can see the gap and trace it, rather than discovering it once a year.
- Count continuously rather than annually. A few items every week, chosen by value and by how often they move, so errors surface within days. An annual shutdown count tells you that something went wrong at some point in the last twelve months, which is almost useless.
- Investigate the discrepancy, do not just correct it. A system that lets you overwrite the number without recording why has quietly discarded the only useful information in the event.
- Count the valuable and the fast-moving most often. Everything else can wait. Treating all stock equally is how counting becomes a job nobody does.
- Expect the first proper count to be bad. It is measuring years of accumulated drift, not the new system. Judge the software on the second count and the third.
The practical implication for choosing: ask specifically how a product handles a count that disagrees, whether it records the reason, and whether it can count part of the warehouse without freezing the rest. Products vary enormously here and demos never cover it.
Before you buy anything
- Write down your five most awkward stock situations. The returns, the part-deliveries, the item that comes in cases and sells in units. These, not the ordinary case, decide the choice.
- Tidy the data first. Duplicate codes, three spellings of a supplier, items nobody has sold in four years. Migrating that mess costs more than fixing it.
- Trial with real data, not the demo set, and specifically test the five situations above.
- Count something properly before and after. Without a baseline you will never know whether it helped.
- Ask about your accounting package by name, and ask whether the connection is one-way or two.
- Check what leaving looks like. Can you export movements, not just current balances? Balances alone are not history.
Not for you if
The question that decides the route: is your stock a count, or a calculation? A count is a product you can buy this week. A calculation, because of batches, serials, location or assembly, is a longer conversation and worth having before you commit to anything.