How to Test a POS Offline Mode in 10 Minutes
Almost every Philippine POS now advertises an offline mode, which makes the claim close to unfalsifiable. It is also easy to check — on any system, including ours — during one shift, without any technical knowledge. Here is the test, and what the results mean.
Reviewed September 2026 · Vendor-neutral. Run it on whoever you are considering.
The test
Do it during a real shift, not a demo
Vendor demos are run on good wifi in an office. Disconnect at your own counter at your busiest hour, with a real order half-entered. What you are testing is not whether the software has an offline mode — most claim one — but whether the people using it can keep working without phoning anyone.
Pull the internet, not the power
Unplug the router or turn off the data on the terminal only. Do not restart the POS, do not close the app. Restarting hides the exact failure you are looking for: what happens to a session that was already in flight.
Take an order you already started and finish it
Add items, apply a discount, take payment, print the receipt. This is the test. Watch for anything that greys out, spins, or asks the cashier to wait. If the till stops mid-transaction to talk to a server, you have found the answer.
Send an order to the kitchen
If you run a kitchen display, put an order through to the kitchen while disconnected. If the KDS is a screen talking to the internet, the kitchen goes quiet at exactly the moment the dining room is busiest. If it talks to the till over your own local network, it carries on.
Close and re-open the app
Force-quit the POS and open it again, still offline. A system that survives a disconnect but dies on a restart is not offline-capable; it is just holding a stale session in memory. Check that your offline sales are still there after the restart.
Print your readings
Print an X-reading or Z-reading while offline. These are the numbers you reconcile the day against. If you cannot produce readings without internet, you cannot close a shift without internet — which is the same as not being offline-capable, just one step later.
Reconnect and check for doubles and gaps
This is the part almost nobody tests and where problems actually live. Reconnect and check three things: does every offline sale appear exactly once, do totals match your printed readings, and did anything get silently dropped? A missing sale is worse than a visible error because you only discover it during an audit.
What a pass and a fail look like
Six checkpoints. Print this and take it to the demo.
| Checkpoint | Passes | Fails |
|---|---|---|
| Core selling | Orders continue to be taken and paid without waiting on a server | Any part of taking payment pauses, spins, or shows a connection error |
| Printing | Receipts print from the till | Receipts queue up and fail to print, or print only after reconnecting |
| Kitchen flow | Kitchen tickets continue where the KDS talks to the till over the local network | Kitchen goes silent because the KDS depends on the internet |
| Durability | Offline sales survive a restart of the application | Offline sales exist only in memory and vanish on restart |
| End of shift | X/Z readings and cash closure can be produced while offline | Cannot close a shift or produce readings without connectivity |
| Reconciliation | Each offline sale appears exactly once after reconnecting, and totals reconcile | Duplicate sales, dropped sales, or totals that do not match the printed reading |
A system can pass the first four and still fail the last one, which is the one that costs you money at audit. Do not skip step 7.
How WSI POS approaches this — and what we will not claim
We publish no uptime guarantee. No POS should, and you should be sceptical of any that does. What we can tell you is architectural, and you can verify it by running the test above on our system.
- •The till is the system of record. Orders and payments are written to a database on the machine itself as they happen, not queued for a server to confirm.
- •Kitchen displays run on your local network. The kitchen screen talks to the counter over your own LAN rather than out to the internet, so tickets keep flowing when the line drops.
- •Receipts and labels print from the till over the local printer connection, including X-readings and Z-readings for closing a shift.
- •Cloud functions are additive, not load-bearing. Off-site backup and remote visibility for an owner are what a connection adds. They are not what keeps the counter running.
To be precise about limits: specific behaviour depends on your hardware, your printer connections and how your deployment is configured, and we verify the offline path with you during implementation rather than assuming it. We would rather scope it honestly than print a “100% offline” badge and let you discover the edges at your busiest hour. Run the ten-minute test on us — that is the whole point of writing it in a way that does not depend on trusting us.
Questions people ask after the test
Why do so many POS systems claim an offline mode but behave badly offline?
Because the claim is usually about caching rather than architecture. In a cloud-first system the database is remote and the terminal keeps a local cache to survive short interruptions. That works for a dropped connection of a few seconds and degrades badly for an outage of a few hours, because the terminal is only pretending to be the system of record. Asking whether the POS works offline does not distinguish between those two designs. Disconnecting mid-order does.
What is the single most important thing to test?
The reconnection step. Anyone can make a till keep accepting orders while disconnected; the hard engineering is merging those offline sales back without duplicating them, dropping them, or breaking your reconciliation. If a vendor is confident about offline mode, ask them to demonstrate the reconnect specifically, and watch the totals on both sides.
Can I test this before I buy, on the vendor's own demo unit?
You should insist on it. Ask them to take a sale, kill the internet mid-order, finish the sale, restart the application, then reconnect while you watch the totals. A vendor who will not run that on a demo has told you something. Any POS that genuinely cannot survive it is a risk you are taking on before you have even opened.
Does an offline-capable POS mean I never lose sales during an outage?
No, and we will not tell you otherwise. WSI POS publishes no uptime guarantee. Hardware fails, tablets run out of battery, printers jam and someone will eventually restart something at the wrong moment. What a local-first architecture buys you is narrower and more honest than a guarantee: the software is not the reason you stop selling. Your order taking, printing and readings do not depend on a connection that you do not control.
What happens on reconnection in a local-first system?
The till already holds the record — it was written to a database on the machine as the sale happened, not queued to be sent later. Reconnecting lets connected functions such as off-site backup and remote visibility catch up. Because the sale was never pending server confirmation, there is no merge problem to get wrong. That is the architectural difference the reconnect test exposes.
Run the test on us
Book a demo and we will disconnect it on the call — take an order, print a reading, restart, reconnect, and check the totals together.
Related: cloud vs local-first architecture · POS cost calculator