What Is an Online POS System, and Does Your Shop Need One?

An online POS is a till that keeps its data on a server instead of inside the machine at the counter. That sounds like a technical detail and it is not: it is the difference between an owner who can see today's takings from home and an owner who finds out at nine in the evening, after someone has reconciled three tills by hand. This article covers what actually separates a good one from a bad one, and the one question most buyers forget to ask.

What "online" really changes

A traditional till is a closed box. It knows its own sales and its own stock, and everything else is a reconciliation exercise at closing time. Add a second counter and you have two boxes that disagree. Add a second branch and you have a spreadsheet.

Moving the data to a server changes four things at once:

• One stock number. Every counter reads and writes the same figure, so a unit sold in one place disappears everywhere.
• One price change. Update once; every till has it. No more "that branch is still on the old price".
• Visibility now, not tonight. Takings, discounts and voids are readable while the day is still happening.
• One reconciliation. Each terminal is stamped on its own sales, so the end-of-day count is still per till — but the totals roll up on their own.

The question most people forget: what happens offline?

This is the question to ask first, and it is the one glossed over most often in a sales demonstration.

A browser-based till with no offline handling stops selling the moment the connection drops. In a market with reliable fibre that may be an acceptable risk. In a shop that loses power or connectivity regularly, it is a queue of customers and a shut counter.

Ask for it to be shown, not described:

"Turn off the wifi. Now sell me something."

Systems that handle it properly queue the sale locally and sync when the connection returns, showing the cashier a clear offline indicator meanwhile. Systems that do not will say the feature is "on the roadmap". Both answers are fine — you simply need to know which one you are buying.

The features that decide whether it survives a busy counter

Feature lists are long and mostly irrelevant. These are the ones a cashier notices on a Saturday:

Barcode first, keyboard second, mouse last. A scanner types the code and presses Enter. A till that requires a mouse click to add each item will be slower than the shop it replaced.

Split payment. Two thousand in cash and the rest on card is not an edge case; it is Tuesday. So is a mobile wallet. If a sale can only take one tender, staff will work around it and your cash reconciliation will be wrong.

Change due, large. The number the cashier reads out should be the biggest thing on the screen.

Park and recall. One customer goes back to the car for their wallet. Without a way to set that sale aside, the whole queue waits.

Returns against a receipt. A refund with no original sale behind it is how money leaves a till quietly. A good system looks up the receipt, refuses to return more than was bought, and records a reason code — so return patterns become reportable instead of anecdotal.

Register open and close. An opening float, a counted drawer at close, and the variance between expected and counted. Without this, a shortfall is simply invisible.

POS alone is rarely the whole answer

A till records the sale. It does not answer what should I reorder, which lines are dead stock, or did this month make money.

That is why POS and inventory belong on the same data. When they are, reordering comes from real movement rather than from a manager's memory, dead stock is a report rather than a discovery, and margin is calculated from what the goods actually cost rather than an estimate.

And every sale is also an accounting event. A till that posts its takings, returns and cash movements into the ledger automatically removes the closing-time ritual of typing the day into the books — and removes the disagreement between the two records that follows whenever someone mistypes.

Cloud, on-premise, or both

Three arrangements, honestly compared:

	Strength	Cost
Cloud / hosted	Nothing to maintain, reachable anywhere, updates handled	You depend on connectivity; usually a per-terminal monthly fee
On-premise server	Works on the local network with no internet	You own the backups, the hardware and the failures
Hybrid	Local speed, central visibility, survives an outage	More to build and more to keep in sync

For a single shop with decent internet, hosted is usually correct. For multiple branches, or anywhere connectivity is unreliable, the offline question decides it.

What to ask in a demonstration

1. Turn off the network and sell me something.
2. Take a payment as half cash, half card.
3. Return one item from a receipt — now try to return more than was bought.
4. Close the register with a deliberately wrong cash count and show me the variance.
5. Sell the last unit at this counter and show me the stock number at the other one.
6. Show me the accounting entry this sale created.

See a till rather than read about one

We have published a demonstration that includes a keyboard-first till — barcode search, split tender with change due, park and recall, counter returns against a receipt, and a register close with an X/Z report and drawer variance — sitting on the same catalogue and stock as a trade desk and an online store.

It is a design preview running on fabricated sample data, not a deployed installation, and every screen says so. Open it and try the six questions above yourself; it is a faster judgement than any feature table.