POS with inventory management, or just a spreadsheet?

Plenty of shops track stock in a spreadsheet and the spreadsheet is not the problem. A spreadsheet is a superb tool. It will hold ten thousand products, do arithmetic you would struggle to do by hand, and cost you nothing.

The problem is the gap between the spreadsheet and the counter. Every sale changes your stock, and a spreadsheet only knows about it if a human tells it. So the real question is not whether a spreadsheet can track inventory. It is whether you can reliably tell it about four hundred small events a week, including on the Saturday when three people are waiting and the card machine is being difficult.

Nobody can. That is the entire argument, and everything below is detail.

How a spreadsheet actually fails

Not dramatically. It rots.

Week one it is perfect, because you built it on Sunday and it matches the shelves exactly. Week three there are a few lines you did not update because it was busy. Week six somebody sold the last three of something and wrote it on a receipt roll intending to enter it later. Week ten you stop trusting the numbers for the fast-moving lines, so you check the shelf before ordering, which is what you were doing before the spreadsheet.

By week twenty the spreadsheet is accurate for the slow half of your catalogue, which is the half where accuracy does not matter, and unreliable for the fast half, which is the half where it does. This is not a discipline failure. It is the predictable result of asking a person to be a data entry pipeline during their actual job.

A POS closes that gap by making the recording a side effect of the selling. You were going to ring the sale up anyway. The stock decrement is free.

What “inventory management” should actually mean

The phrase is on every pricing page and it covers wildly different amounts of substance. Here is what to look for, in the order it matters for a small shop.

A current stock number per product, updated by sales. The baseline. Nothing else works without it.

A reorder level per product, and an alert when it is crossed. This is the feature that pays for the software. Not the stock number itself: the number is only useful if something looks at it for you. A reorder point per line, worked out once, turns ordering from a memory exercise into a rule. It is the subject of stop running out of your best sellers and it is the single highest-value thing in this list.

A movement history per product. This one is underrated and it is what separates real inventory management from a number in a box. When the shelf says four and the system says seven, you want to see every event that touched that product: sold three on Tuesday, received twelve on Wednesday, someone adjusted it down by two on Thursday. Without that history, a discrepancy is a mystery and all you can do is overwrite the number and hope. With it, you can usually see exactly where it went wrong, which means you can stop it happening again.

Ask about this specifically, because it is the thing most likely to be missing. “Can I see every change to this product’s stock, with what caused it?” A yes is worth a great deal.

Purchase orders and goods receipts. So an order you placed is a record rather than a memory, and receiving a delivery updates stock and cost in one action instead of two manual ones. Also the honest way to find out that a supplier short-shipped you.

Cost that updates when you receive stock. Covered in setting a shelf price, and worth repeating: if the cost figure is whatever you typed a year ago, every margin number the system shows you is decoration.

Stock adjustments, recorded rather than edited. There will always be breakage, waste and recounts. What matters is that correcting a number leaves a trace, so the count history stays honest.

Where the spreadsheet still wins

I am not going to pretend it never does.

Planning. No POS report is as flexible as a pivot table. If you are working out a seasonal buy, modelling a price change across a range, or building a budget, export the data and do it in a spreadsheet. That is what spreadsheets are for and it is a good workflow, not a fallback.

Odd one-off analysis. Anything the reports were not built to answer.

Genuinely tiny shops. Under about forty products, one person, low turnover, and a spreadsheet plus a weekly count is completely reasonable. Do not buy software to solve a problem you have not got.

Which suggests the right arrangement for most shops is not one or the other. It is a POS as the system of record, because it captures events automatically, and a spreadsheet as the thinking tool, because it is better at thinking. The connective tissue is a working export. Which is why “can I export everything to a file, myself, whenever I like” is a question worth asking before you buy anything, and a no is disqualifying.

The test that settles it

If you are unsure whether you have outgrown the spreadsheet, do this. It takes ten minutes and it is more honest than any feature comparison.

Pick your ten fastest-moving products. Count them, physically, right now. Then compare against what your spreadsheet says.

If nine or ten match, your system is working. Keep it and stop reading.

If five match, you already know your numbers are decorative, and you are ordering on instinct while maintaining a spreadsheet that gives you no benefit. That is the worst of both, and it is where most shops in this position actually are.

The reason it comes out at five is never laziness. It is that the fast-moving lines generate the most events, so they drift the fastest, which means the spreadsheet is least reliable precisely where you most need it.

Where StoreWave sits

Stock in StoreWave is not a number someone maintains. Every change is a row in an append-only ledger, written in the same database transaction as the change itself, recording the quantity moved, what caused it, which document it belonged to, and the resulting balance. Causes are explicit: a sale, a voided sale, a purchase receipt, a manual adjustment, a parked basket reserving stock, a hold being released or expiring, a return being restocked.

That ledger is the answer to the movement-history question above, and it is the thing to test if you are comparing systems. When a shelf disagrees with the screen, you can read the sequence of events rather than guess at it.

Beyond that: a reorder level and a maximum per product, low-stock alerts that fire once per crossing rather than once per sale, purchase orders with goods receipts that update stock and recalculate a weighted-average cost together, and every report exporting to a file on the free plan as well as the paid one, because the spreadsheet is still the better thinking tool and we would rather you used it.

Two honest gaps: stock adjustments are ledgered but not categorised, so a written-off crate and a recount correction both read as “adjustment”, and there is no batch or expiry tracking. Both matter more in food than elsewhere.