Does your POS system still work when the internet goes down?

A hardware and paint distributor with two retail counters lost internet for four hours on a Saturday morning — their busiest window of the week, contractors stocking up before job sites opened. The POS terminals stayed on. The card machine didn't. The first ten minutes were fine: cash sales rang up as normal, nobody noticed anything wrong. By the twentieth transaction, the manager at the busier counter realized every sale since the outage started had been recorded on the terminal but not one of them had synced anywhere, and there was no way to tell, from where he stood, which SKUs at the other counter three kilometers away were about to be sold out from under him.

The outage isn't the problem. The two hours after it are.

Most people picture a POS outage as a register that stops working — a cashier standing at a dead screen while a line forms. That's rare. Modern POS terminals cache the day's catalog and pricing locally, so a cashier can keep scanning barcodes and taking cash the entire time the connection is down. The transaction itself almost never fails.

What fails quietly is everything downstream of the transaction. Every sale made offline is, from the moment it happens, a claim against inventory the rest of the business can't see yet. At a single-counter operation that's a minor timing issue. At a distributor running multiple counters, plus vans on the road, plus a warehouse filling phone orders — all drawing from the same stock — an offline counter is a blind spot the size of the outage, multiplied by how much inventory overlaps across channels.

At the paint distributor, counter two kept selling from a shared SKU list without knowing counter one had already sold through most of it. When the connection came back and both queues of offline sales synced, seven items were oversold — sold to two different customers who'd both walked out believing they had stock reserved. Two of those were special-order items the customer had waited a week for.

Why the sync-back is the dangerous part, not the outage

An outage that just pauses the register is annoying but safe — nothing gets recorded wrong, sales just wait. The risk shows up specifically when a system keeps selling offline and then has to reconcile a batch of transactions against a stock count that moved somewhere else in the meantime. Three things typically go wrong in that reconciliation:

Oversell. Two counters, or a counter and a van, both sell the last few units of the same SKU during the same window. Whichever sale syncs second is the one that's now short.

Price and promotion drift. If a price change or a promotion was pushed centrally during the outage, offline sales at the counter went out at whatever price was cached locally — sometimes the old price, sometimes a promotion that had already ended. Nobody notices until someone reconciles the day's average selling price against the price list and it doesn't match.

Duplicate or lost transactions. A cashier who isn't sure whether a sale went through — because the screen froze for a second during the outage, not because of the outage itself — rings it up again "to be safe." Without a way to detect that the same cart was submitted twice, both charges land in the ledger.

None of these show up in the moment. They show up during the evening cash-up, or worse, days later when a customer calls asking why they were charged twice, or why the item they paid for was actually already sold to someone else.

What a system that handles this correctly actually does

The fix isn't "have an offline mode" — nearly every POS claims that. The fix is in what happens the instant connectivity returns:

Every offline transaction carries a unique ID generated on the device, not the server. That ID lets the system recognize "this cart was submitted once" even if the same batch gets sent twice during a shaky reconnect. Without it, deduplication has to guess from timestamp and total — which is how legitimate back-to-back sales of the same amount get silently dropped.

Stock deducts locally in real time, then reconciles centrally — it isn't held pending until sync. The counter shows on-hand stock as of the last successful sync, and every offline sale decrements from that number as it happens, so a cashier two hours into an outage still has a reasonably accurate read on what's left.

Oversold items get flagged for a human decision, not silently allowed or silently blocked. When two offline sales of the same low-stock item sync back and only one can be honored, the system should surface that as a specific exception — "this item was sold twice, here are the two orders" — so a manager can call one customer and offer a substitute, rather than either sale vanishing or the counter blocking all sales the moment stock reads zero.

Prices lock to what was cached at the time of sale, and get logged that way. If a price changed mid-outage, the sale should reflect what the cashier's screen actually showed, with the report afterward saying so explicitly — "sold during outage at cached price" — instead of quietly reconciling to whichever price won.

What to check before your next outage

• Ask what happens, specifically, to a sale rung up on your POS when the internet is down for four hours during a busy period — not in theory, but by testing it with the network cable pulled.
• Confirm whether two counters (or a counter and a van route) draw from a shared stock count, and if so, ask what happens when both sell the same near-zero-stock SKU during an outage.
• Check whether offline transactions get a device-generated ID before they're submitted, or whether deduplication depends on matching timestamps and totals after the fact.
• Look at how an oversold item surfaces after a sync — as a flagged exception someone has to resolve, or as a number that just quietly goes negative in the report.
• Run the outage test on a slow week, not your busiest Saturday, so the first time you find a gap isn't also the day it costs you the most.

iotoms's point of sale runs fully offline at the counter, tags every transaction with a device-generated ID so a reconnect never double-books a sale, and reconciles stock across every counter, van, and warehouse against the same live count — flagging an oversold item as an exception for a manager to resolve instead of letting it disappear into the numbers.