Choosing a POS for a small grocery or minimarket

A grocery is one of the harder shops to run a till in, which is not obvious until you try. A clothes shop sells forty items a day at a comfortable pace with margins that forgive a mistake. A minimarket sells four hundred items a day, some of them by weight, at a rate where a two-second delay per basket becomes a queue out the door, on margins thin enough that a pricing error erases the profit on the whole shelf.

So generic advice about POS features is close to useless here. Four things break, they break the same way in every grocery, and they are what you should be testing during a trial.

1. Weight, and the decimal point problem

Most till software was designed around the idea that a customer buys a whole number of things. Groceries do not work that way. Loose vegetables, cheese from the counter, coffee beans, rice from the sack, meat: all of it is a number with a decimal point and a unit attached.

Systems handle this in three ways, and the difference matters.

Badly: the product is priced per kilo and you type a quantity of 1.5, which the system happily accepts because it treats every quantity as a plain number. This works until somebody sells 2.5 tins of tomatoes, which is not a thing, and the stock figure for tinned tomatoes is now permanently a fraction. Every count from then on disagrees with the system by half a tin and nobody knows why.

Adequately: there is a separate concept of a weighed item, kept away from the countable stock, usually with its own screen and its own report.

Properly: every product carries a unit, and the system knows which units allow fractions. Beans in kilos accept 0.75. Tins in pieces do not accept 0.5, and refuse it at the point of entry rather than three weeks later at the stock take.

That third behaviour is what you want, and it is easy to test in five minutes of a trial. Create a product measured in kilos and sell 1.75 of it. Then create one measured in pieces and try to sell 1.5. If the second one is accepted, walk away. You have just watched the system agree to corrupt its own stock figures, and in a shop with a thousand lines you will never find them all again.

Ask about scale integration too, but be realistic. Full integration with a counter scale that prints a barcoded label is a specific and not always cheap arrangement. Many small groceries do fine with the scale printing a weight, the cashier entering it, and the till doing the arithmetic. Decide which you need before you pay for the expensive version.

2. Speed at the counter

In a grocery the till is not a form to be filled in. It is a physical rhythm, and anything that interrupts the rhythm costs you money at five o’clock.

Test these specifically, with a real basket of twenty items:

Scan speed. A scan must register instantly. Not quickly. Instantly. A USB barcode scanner types the code like a very fast keyboard, and a well built till adds the item before the cashier’s hand is back on the next tin. If there is a visible pause per item, twenty items is a visible pause per customer, and the queue notices.

Keyboard everything. A cashier’s hands should not have to leave the scanner and the keypad. Look for whether quantity, payment and completion can all be done without a mouse or a precise tap on a small button.

The no-barcode path. Every grocery has loose items, bakery, and the thing whose label has come off in the freezer. Ringing one of those up must take two taps, not a search-and-scroll. A grid of the twenty most common no-barcode items, on the main screen, is worth more here than any report.

The pause. Customer has forgotten their card and gone to the car. In a grocery this happens daily, and if the answer is “clear the basket and start again” you will do it several times a week with a queue watching. Park the basket, serve the next three people, bring it back. Check the system can do that, and check that parking a basket does not release the stock to be sold twice.

3. Margins thin enough to require actual arithmetic

Grocery margins run tight. That means two things a POS must give you and many do not.

Cost per item, kept up to date. Not the cost you typed in when you created the product eighteen months ago. Supplier prices move constantly in food, and a shelf price set against last year’s cost is a slow leak. What you want is a system that recalculates the cost every time you receive stock, ideally as a weighted average across deliveries, so the margin it reports is the margin you are actually getting rather than the one you were getting in spring.

Margin per line, not just sales per line. A busy product with 4 percent on it and a quiet one with 30 percent are very different things, and a report sorted by revenue tells you nothing about which is which. Sorting by margin is what changes the order you place. There is more on the arithmetic in setting a shelf price that pays.

Also, tax. Groceries in many countries have items at different tax rates, some of them zero rated, and getting that wrong is not a reporting inconvenience, it is a filing problem. Check how many rates the system supports before you assume one is enough.

4. Stock that goes off

This is the one no POS solves fully and where you should be most sceptical of a demo.

Fresh stock has a third state that dry goods do not: not sold, not in stock, thrown away. If your system has no way to record that, then every wasted crate looks identical to stock that walked out of the door unpaid for, and you cannot tell your waste problem from your theft problem. That is a genuinely expensive confusion in a grocery, because the fixes are completely different.

At minimum, you need a stock adjustment with a reason so a written-off crate is recorded as waste, not as a mystery. Batch and expiry date tracking, where the system tells you what expires Thursday, is a separate and much bigger feature. Some systems have it. Most small business systems do not. If you sell a lot of short-dated fresh food, ask directly and do not accept “you can put the date in the description” as an answer.

And whatever the system does, keep counting. Fresh lines need counting far more often than dry goods, which is exactly the argument for a rolling stock take rather than one big count a year: you count the milk weekly and the tinned goods quarterly, instead of everything once and badly.

The short version

If you are trialling something this week, do these five things and ignore the feature list.

1. Sell 1.75 of something priced per kilo. Then try to sell half a tin. The second must be refused.
2. Scan twenty items in a row and watch for a pause.
3. Ring up a loose item with no barcode. Count the taps.
4. Park a basket, serve someone else, resume it.
5. Receive a delivery at a higher cost than last time and see whether the reported margin moved.

A system that passes all five will survive a grocery. One that fails the first is going to give you stock figures you cannot trust, which is the only thing a grocery really needs from a till.

Where StoreWave sits

Units are a first-class idea in StoreWave rather than an afterthought, which is mostly why it suits this trade. Every product carries a unit from a fixed list, kg, g, L, ml, m, cm for the divisible things and pcs, box, pack for the countable ones, and the server refuses a fractional quantity on a countable unit at the point of entry. Selling 1.75 kg of beans works. Selling 1.5 tins does not, and cannot be made to.

Quantities are held to three decimals throughout, so a weighed sale is stored as it happened rather than rounded into a whole. Product cost is recalculated as a weighted average on every goods receipt, so margin reflects the last delivery rather than the first. USB scanners work with no setup because the app recognises a scanner’s burst of keystrokes as distinct from a person typing, and the device camera reads EAN, UPC and Code 128 when there is no scanner. Baskets can be parked with their stock properly reserved, so two tills cannot sell the same held item.

Three gaps to weigh honestly, because they are all in this article’s list.

Tax is a single rate per shop. If your country zero rates some food and taxes the rest, StoreWave cannot express that today, and that may well decide the question for you. Ask us before you invest an afternoon in the catalogue.

There is no batch or expiry tracking. Nothing will tell you what goes off on Thursday. If short-dated fresh food is a large part of your shelf, that is a real gap.

Stock adjustments are recorded but not categorised. Every stock change lands in an append-only ledger with its cause, so a manual adjustment is clearly distinguishable from a sale, a delivery or a return, and the running balance after each one is stored. What the ledger does not have is a waste category, so a written-off crate and a recount correction both read as “adjustment”. You can tell an adjustment from a sale. You cannot yet tell waste from shrinkage without your own notes.