Offline POS: How to Keep Selling When the Internet Goes Down

The two ways an outage costs money

An internet outage in a shop causes one of two losses, and they are not equally bad.

The first is lost sales: the till will not open, the queue walks out, and you can count the damage in an afternoon. It hurts and it is visible.

The second is lost records: staff keep selling, but into a notebook, a phone note, or nothing at all. Sales happen, money changes hands, and none of it enters your system. This is the expensive one, because it does not look like a loss on the day. It looks like a normal afternoon and shows up weeks later as stock that does not match, a margin figure you cannot explain, and a suspicion about a member of staff you cannot prove or dismiss.

Most guidance on offline POS treats the first problem and ignores the second. The second is the one that damages a business.

---

What "works offline" has to mean before it means anything

Almost every POS vendor claims offline support. The claim is close to meaningless without answers to four specific questions, so ask them in this form:

1. Where do pending sales live? In memory, or written to storage on the device? Only the second survives the application closing, the battery dying, or the machine being restarted by a member of staff who assumes that will fix it.
2. Are permissions still enforced? If access is checked on the server, an outage quietly gives every user full rights at the exact moment nobody is supervising.
3. What happens on reconnect if the commit half-fails? Anything that does not confirm must be retried, not silently dropped and not committed twice.
4. What is explicitly not available? A vendor that will not tell you the limits has not tested them.

The rest of this guide answers those four for Zeneva, then covers the operational half that no software solves.

---

Exactly what happens in Zeneva when the connection drops

Being specific here is more useful than being reassuring, so this describes actual behaviour rather than intent.

The catalogue is already on the device. Products, prices, customers and recent receipts are mirrored locally, so search and scanning at the counter do not depend on the network. This is also why the app opens fast on a slow connection.

A completed sale becomes a queued action. Rather than writing directly to the server, every write goes into a pending queue. That queue is what makes the outage survivable, and it is the same mechanism used when you are online, which matters: the outage path is not a rarely exercised special case, it is the normal path with the network absent.

In the installed app, the queue is written to a local SQLite database on the device. It survives closing the app, and on the next launch the pending items are loaded and replayed. This is the durable guarantee, and it applies to the Windows, macOS, Android and iOS builds.

In a browser tab, the queue is held in memory for the life of that tab. A brief outage is handled fine. A refresh, a closed tab, or a crash during the outage loses anything not yet committed. This is a real limitation and we would rather state it plainly than let you discover it: if your location loses service with any regularity, run the counter on the installed app from the downloads page, not in a browser.

Permissions are enforced against the cached profile. A cashier restricted from recording sales or editing stock is still restricted during an outage. Access does not widen because the server is unreachable.

Branch attribution is stamped when the action is queued, not when it syncs. Sales made at a branch during an outage still land against that branch afterwards, which is what keeps per-branch figures meaningful. Our guide to multi-branch management covers why that attribution matters more than it sounds.

On reconnect the queue drains, and anything that does not confirm is retained for retry rather than discarded. The failure you want to avoid in a sync design is a write that silently disappears because a single request timed out.

---

What does not work offline

This section exists because a vendor unwilling to write one is hiding something.

Card and bank-transfer verification. Confirmation that money moved comes from the bank. No local software can produce it while the connection is down, and any product implying otherwise is describing something other than verification. Practical consequence: cash, or a recorded debt against a named customer.

Zen AI. Questions run as a server request, so the assistant is unavailable during an outage. Reports built from data already on the device still open.

A live consolidated view across branches. Your own device is fine, but a branch that is itself offline cannot report in. Group stock and group sales figures go stale for the duration. This matters most for a decision you might make mid-outage: do not place a group-wide reorder off numbers you cannot confirm are current.

Photos for products created offline. The product record itself queues normally. Attach the image once you are back online.

---

The oversell problem, stated honestly

Two tills, both offline, both holding a snapshot showing one unit left. Both sell it. Both are correct at the time. After sync, stock reads minus one.

No offline system prevents this, because preventing it requires a live authority that an outage removes by definition. Vendors rarely mention it. It is better handled than hidden:

• For genuinely scarce or high-value lines, keep one till authoritative during an outage and route those items to it.
• Expect to reconcile a small number of lines after a long outage, and treat a negative figure as an ordinary artefact of the outage rather than evidence of theft.
• Adjust with a stated reason, never by deleting and re-adding the product, so the trail survives. Our post on why stock records stop matching the shelf covers the difference and why it matters.

---

The outage drill

Software handles the record. Staff handle the shop. This part is a laminated card near the till, not a policy document.

Before it happens, once:

• Install the app on the till rather than using a browser.
• Decide the payment rule now: cash only, or recorded debt against a named customer. Write it down.
• Make sure every member of staff has their own login. Shared logins destroy attribution, and an outage is precisely when you will want to know who recorded what.
• Run the ninety-second test below so staff have seen it work.

During, in order:

1. Say out loud that the internet is down and the system still works. Silence is what starts the notebook.
2. Switch to the agreed payment rule. No screenshots as proof of transfer, ever.
3. Keep selling normally through the POS. Do not "catch up later" — later never arrives intact.
4. Do not restart the app or the machine to try to fix it, and if you are on a browser tab, do not refresh it.
5. Note the time the outage started and ended. Ten seconds now saves an hour of reconciliation.

After, the same day:

1. Confirm the pending queue has drained to zero.
2. Compare receipts recorded in the outage window against what the counter believes it did.
3. Check stock on anything sold heavily for negative or implausible figures, and adjust with reasons.
4. Record any goods released on trust as a debt against a named customer while people still remember.
5. Confirm the day total reconciles with cash in the drawer.

---

The ninety-second test

Do this on a quiet afternoon, with a real product, before you need it.

Step	What you are checking
Disconnect the device from the network	That the app keeps working rather than showing a blocking error
Search for a product and complete a small sale	That the catalogue and pricing are genuinely local
Print or view the receipt	That the customer still gets proof of purchase
Fully close the application	The real test: is the pending sale stored or only remembered
Reopen it	That the sale is still listed as pending
Reconnect	That it commits exactly once, not twice and not never
Check stock and the day total	That the figures moved by exactly the amount you sold

The fourth and fifth rows are the ones that separate a durable queue from a hopeful one. Run this against any POS you are evaluating, including ours.

---

Why this is a buying criterion, not a footnote

If you trade anywhere with unreliable service or power, offline behaviour is not a feature comparison line — it is the difference between a bad hour and a month of figures you cannot trust. It deserves more weight in a POS decision than the interface, the hardware, or the price, because every other feature depends on the records being complete.

Judge it on specifics: where pending sales are stored, whether permissions hold, what is explicitly unavailable, and whether the vendor will put those answers in writing. Then test it yourself in ninety seconds rather than taking anyone's word for it.

If you want to run that test against Zeneva, install the app and try it on the free plan before committing to anything. Our POS setup guide covers getting the counter configured properly first, and audit logs and permissions covers the attribution that makes outage reconciliation possible at all.