POS system for small business: what actually matters, counted across 60 real products
Shopping for a POS system for a small business is a strange experience. Every product leads with the same two things — the hardware on the counter and the monthly price — and neither of them is what decides whether the system works for you in a year.
What decides it is duller and almost never on the comparison page: whether the stock number reconciles, whether a refund reverses everything the sale created, and whether one member of staff can ring up a sale, take the cash and remove the record. That last one is the risk a small retailer carries most and hears about least, because it does not photograph well.
This is the counted version. We went through 60 real retail POS products and tallied what each one actually ships. Below is that list, what each capability has to do to be real, the two controls that matter disproportionately to small businesses, and the tests to run before you commit.
What you are actually choosing between
The market presents itself as a long list of products. It is really four options with different shapes.
A card reader that grew a till. The Square and SumUp shape: payments first, everything else added later. Excellent at taking money, genuinely cheap to start, and the stock and reporting side is thinner than the marketing suggests. Right for a market stall, a pop-up, a service business, or a shop with a few dozen lines.
A full retail POS. Built stock-first with the till on top. More to learn, more to set up, and the only shape that answers "what do I have and what is it worth" properly. Right once you carry real inventory.
A till plus something else for stock. Extremely common and rarely admitted: a simple register for taking money, and a spreadsheet for what you have. Honest and workable at small scale, and it fails in a specific way — the two never agree, and nobody can say which is wrong.
Build your own. Now a real option rather than a fantasy, with a specific catch covered further down.
Most bad purchases in this market are someone buying shape two when they needed shape one, or running shape three for two years past the point it stopped working.
The counted core
Ranked by how many of the 60 products ship each capability:
| Capability | Products | Share |
|---|---|---|
| Cashier sell / checkout | 60 | 100% |
| Actual stock visibility | 58 | 97% |
| Source-backed reporting | 51 | 85% |
| Customer context | 44 | 73% |
| Tender handling — cash, change, split | 36 | 60% |
| Multi-location and transfers | 34 | 57% |
| Returns, refunds and exchanges | 29 | 48% |
| Register / shift / cash close | 18 | 30% |
| Staff permissions and approval | 16 | 27% |
| Purchasing and receiving | 13 | 22% |
Two things stand out immediately, and both are useful.
The top of the list is almost universal — every product sells, nearly every product shows stock. That is not differentiation, it is table stakes, and any comparison built on those rows is telling you nothing.
The bottom of the list is where the differences live. Cash close appears in 30% of products and staff approval in 27% — and those are the two capabilities a small business needs most, for reasons the next section covers. A feature grid ranked by prominence will show you the opposite of what matters.
What each capability has to do to be real
Cashier sell — 60 of 60. The product centre at every price point. What separates a good one is speed and recovery: search, scan, quick keys, an editable basket, and the ability to fix a mistake mid-sale without starting again. Test: ring in eight items, change the quantity on the second, remove the fifth, and apply a discount to one line. Count the taps and the dead ends.
Actual stock visibility — 58 of 60. The decorative version is a number on a product page. The real version is a stock list as a top-level screen with movement history behind each figure, so you can answer why it says nine. Test: find a product, open its movement history, and see whether every change has a reason and a person attached. If there is no history, the number is an opinion.
Source-backed reporting — 51 of 60. Widgets that drill through to the exact rows behind them. Test: click a figure on the dashboard. If nothing happens, you have a static card, and static cards drift from reality the moment anything is refunded or edited.
Customer context — 44 of 60. Optional at the small end, and worth being honest about: loyalty schemes are frequently bought and rarely used. Attach a customer to a sale if you want purchase history; take the loyalty module when you have someone whose job it is to run it.
Tender handling — 36 of 60. Cash and change due are the core. Split payment across two methods is where cheaper products stop, and it is more common in real shops than vendors assume. Test: take half in cash and half on card, then refund it.
Multi-location and transfers — 34 of 60. Frequent in the market, conditional on you. If you have one shop, this is the first thing to ignore — and the first thing a salesperson will demonstrate.
Returns and exchanges — 29 of 60. Only 48%, which is remarkable given that every shop takes returns. Most products do refunds; far fewer do a proper exchange with restock and a balance to pay or refund. Test: exchange a £20 item for a £15 one and see whether stock, the money and the record all move correctly.
Purchasing and receiving — 13 of 60. The lowest on the list, and reasonable to defer. Opening stock plus manual receipt is a legitimate first version for a small shop.
The two controls small businesses need most
Here is the finding worth the price of the research. The two capabilities lowest in the market — cash close at 30% and staff approval at 27% — are the two that matter most to a small independent retailer, and for the same reason: you are not always behind the counter.
Register, shift and cash close
The full trading-day lifecycle: open with a float, record cash in and out during the day, count at close, and record the variance.
The decorative version is a button that says "close". The real version produces a number — expected versus counted, by tender type — and stores it with the person who counted. That variance record is the single most useful management report a small shop has, and it does not exist unless the system was built to produce it. A till that is short by a few pounds twice a week tells you something. A till that never counts tells you nothing, and you will not notice the pattern for a year.
Test: close a shift with a deliberate discrepancy and see what the system records and who it attributes it to.
Staff permissions and second signature
Not an admin console with user accounts — that is table stakes. The control that matters is approval at the point of work: a discount above a threshold, a void, a refund, a price override, a no-sale drawer open. Each needs a second person, and critically, a person who is not the one performing the action.
This is not a theoretical risk, and we watched a build discover it in real time. Of three POS systems built from the same specification by three different coding models, one ran its own review and found a hole where a single person could ring up a sale, take the cash and erase the record afterwards. It removed the ability outright, routed every correction through the returns path so that money, stock and loyalty all reverse together, and made it impossible to approve your own action. All three of those changes held when we tested them.
That is the exact shape of small-retail shrinkage, and it is why "can I void a sale" is a better purchasing question than "does it do loyalty".
Test: try to approve your own discount. Then void a completed sale and check whether it still appears in the day's report as a voided transaction — it should. A void that removes a sale from history is an erasure tool.
The money path, which is what a till is for
When we audited three independently built POS systems, we ranked them on one axis: whether the money path is correct. Four checks, all of which you can run on any product in a trial:
- A refund reverses everything the sale created — stock back, loyalty points clawed back in proportion, gift-card or stored value restored, in the same step. Partial reversals are the common failure.
- A refund cannot be applied twice, in either direction.
- A void does not erase. It marks.
- Moving money needs a second signature from someone other than the person acting.
Every one of the three builds handled some of this well, and the differences between them were entirely here rather than in features. One had the cleanest money path of the three and the most accurate self-assessment. One shipped a build that did not compile for production while its own handover claimed it had been verified — a correct system with a dishonest report attached, which is its own kind of failure.
Also worth noting, because it is the honest position: all three kept card payment in a clearly labelled test mode rather than pretending to have an integration. If you are evaluating a build — your own or someone else's — a simulated payment that says so is a far better sign than one that does not.
What it costs, honestly
Nobody publishes a straight answer here, and the reason is that the monthly price is the smallest component.
- Per-terminal pricing compounds. The headline figure is usually one till. A second counter, or a second shop, multiplies it.
- Card processing is the real cost. For most small retailers the percentage taken on every transaction dwarfs the software subscription within a year. Compare that number first, and check whether it is fixed or negotiable at your volume.
- Hardware is a one-off with a lifespan. Terminals, scanners, printers and drawers wear out and are often proprietary, which quietly determines your next purchase too.
- Migration in and out. Ask what a full export contains before you put two years of sales history into it.
We have written the arithmetic up separately in POS system cost, and the free tiers in free POS software.
When building your own makes sense
Two years ago this was a bad idea for anyone without a development budget. It is now a serious option, because a coding agent will produce a working till in a couple of days. Three complete ones, built from a single specification by three different models, are running as live demos.
The catch is specific. An agent will build the top of the counted list well — the sell screen, the stock list, the reports look fine. What it will not build unprompted is the bottom of the list, and the bottom of the list is the part that protects you: cash close with variance, second-signature approval, a refund that reverses every ledger the sale wrote, and a void that marks rather than erases. Nothing in "build me a POS" asks for them, and the version a model has seen ten thousand times does not have them.
Which means building is right when you can specify those things, and wrong when you cannot — and that is the whole difference, not the coding.
Build is a good answer when: you run more than one till or shop and per-terminal pricing has become a real number; your product does not fit a standard catalogue (weights, bundles, made-to- order, consignment); you need a workflow no vendor sells; or you want the money controls above enforced your way rather than theirs.
Buy is a good answer when: you are a single till, you want it working this week, and you would rather someone else be responsible at 9am on a Saturday. Which is most small businesses, most of the time, and there is no shame in it.
The checklist to take into a demo
- Ring in eight items with a modification and a line discount. Count the taps.
- Open a product's stock movement history. Confirm every change has a reason and a person.
- Click a dashboard figure. Confirm it drills to source rows.
- Take a split payment, then refund it.
- Exchange an item for a cheaper one. Check stock, money and the record.
- Close a shift with a deliberate discrepancy. Find the variance and who it is attributed to.
- Try to approve your own discount.
- Void a sale. Confirm it still appears in the day's report as voided.
- Ask what a full data export contains, and get it in writing.
Nine checks, about twenty minutes, and they will tell you more than any comparison table. Note that six of the nine are about what happens after a sale goes wrong — which is the part of retail software nobody demos and every shop lives in.
If you are still deciding whether you need this at all, cash register versus POS system covers the honest line between the two. POS system cost works through the arithmetic, and free POS software covers where the free tiers stop.
If your stock is the harder problem than your till, what a retail inventory management system includes is the counted inventory for that side.
And if you are building, the Retail POS planner is the specification we hand our own agents — cashier-first, with the cash close, the approval path and the reversal rules written in so they cannot be skipped.