What true offline mode actually looks like, the failure points buyers should test for, and how to evaluate vendors before you sign.
It is a Saturday afternoon in March. Your multi-site estate is trading as normal across 80 stores when the support inbox starts filling up. Store 47 is processing transactions but cards are declining. Store 12's tills are frozen on a loading screen. Stores 18 through 23 are taking cash only, which they have not been configured to reconcile properly. Three stores look fine.
Somewhere between your ISP, your data centre and your POS vendor's cloud, something has failed. The vendor's offline POS mode was supposed to catch this. It has not. By the time connectivity returns four hours later, you have lost trade at two stores entirely, authorised card payments at three you cannot now reconcile, and your Monday morning is going to be a mess.
This is not a connectivity problem. It is a POS architecture problem.
Every POS vendor claims offline capability. Few deliver it properly. The phrase is elastic, and most buyers discover where the elasticity lives only during an outage.
Genuine offline POS looks like this. Terminals hold local copies of products, prices, promotions and customer data, refreshed continuously when the terminal is online. They process transactions fully on the device, not against a central server. They authorise payments locally, either through the payment device itself or via stored authorisation tokens, so cards keep working when the network drops. They queue transactions locally and sync automatically when connectivity returns, with explicit conflict resolution for the awkward cases. And, critically, they handle partial failure. Network flaps, intermittent DNS issues and a single terminal going offline while others keep trading are harder than a clean total outage, and most systems fail them.
The question to ask is not whether your POS has offline mode. It is what specifically your POS does when the network fails. Not what the vendor says. What it actually does.
Payment authorisation is the hardest part, and the one most “offline” platforms quietly sidestep. Many stop authorising cards the moment the network drops, leaving staff taking cash or turning customers away. True offline payment requires either a payment device capable of standalone authorisation or locally stored authorisation tokens with clear limits and risk controls.
After that, the failure points stack up. Pricing and promotion data go stale if the terminal was not refreshing properly before the outage, which means customers are charged the wrong price in either direction. Loyalty lookups fail if they rely on a live connection to the central database, and member discounts are lost or applied inconsistently. Gift cards and vouchers redeem twice if two terminals accept the same code offline and only reconcile later. Stock decrement either happens locally and reconciles on sync, or blocks the sale entirely, and the difference depends entirely on architecture.
The most revealing tests are partial failures. One store online while the rest are offline. One terminal offline within a store where others are fine. A connection that drops for ten seconds every minute rather than staying down cleanly. These are the realistic failure modes, and they expose how the platform actually behaves when the marketing slide is no longer on screen.
Do not accept a demo of offline mode. Run the test yourself, in a real store.
Ask the vendor to set up a live terminal configured exactly as it would be in production. Run a normal transaction. Then physically disconnect the network cable from the terminal. Watch what happens at the terminal screen, at the payment device, and at the local server if there is one. An error screen tells you one thing. A seamless transition to offline mode tells you something else entirely.
Run five more transactions with the network still disconnected. Include a card payment, a loyalty member lookup, a voucher redemption, and a full refund. Each one tests a different part of the stack. Note every error, every fallback prompt, and every transaction the system refuses to process. Then reconnect the network and watch the sync. How long does it take? Does it queue cleanly or throw reconciliation errors? What happens to the refund you just processed offline?
Finally, ask the vendor what changes if the network stays out for 24 hours rather than 24 minutes. Ask where the local data refresh cycle breaks. If the vendor cannot run this test in your actual store environment, with your actual hardware and network, that is your answer.
Offline reliability is not a feature toggle. It is an architectural decision, made years before you evaluated the product. Terminals need local data rather than cached fragments, local processing rather than remote calls the platform disguises as local, and local payment capability with risk controls that match your business. Underneath all of that, they need a sync-and-reconcile model that treats reconciliation as a first-class concern rather than an afterthought.
Platforms built around a thin client model, where the terminal is essentially a window into a central server, will always have offline limitations regardless of how the product is marketed. No amount of configuration closes that gap.
LS Central, as implemented by BC4 on Microsoft Dynamics 365 Business Central, is architected for full terminal-level offline trading with automatic sync to the central system. That is one of the reasons retailers including Selco Builders Warehouse migrated across 74 stores without trading downtime.
When did you last actually test your POS's offline mode under realistic conditions? Not a vendor demo. Not a lab scenario. An actual store, with actual terminals, and an actual disconnection.
If the answer is “we haven't”, or “we relied on what the vendor told us”, you are carrying outage risk you have not quantified. The cost of a four hour Saturday afternoon outage across a multi-site estate is rarely under six figures. The cost of knowing, in advance, exactly what your POS will and will not do under failure is a 45 minute conversation.
BC4 has delivered over 1,700 POS installations across 350+ global locations, with a 100% delivery success record. We run POS resilience reviews for retailers scoping new platforms, and for those stress-testing what they already have.
Book a POS resilience review with BC4.
Multi-site retailers do not reduce outage risk by trusting the offline mode slide in a vendor deck. They reduce it by choosing POS platforms architected for offline trading, and by testing them under the conditions their stores actually face.
That is what keeps tills running when the network does not.
Speak to BC4 if you want to stress-test your current POS's offline mode, or scope a platform built to survive real failure conditions.
It keeps the terminal fully operational without a network, processing transactions, authorising card payments and reading local product data, then syncs everything automatically when connectivity returns. Platforms that only cache data or fall back to cash-only are offline in marketing terms, not operational ones.
Disconnect the network cable from a live terminal in a real store and run a card payment, a loyalty lookup, a voucher redemption and a refund, then reconnect and watch the sync. If the vendor cannot demonstrate that in your actual environment, that is your answer.
The cause is almost always architectural: platforms built as thin clients rely on a central server and cannot fully operate without one. Specific failure points include payments that stop authorising, loyalty lookups that need live data, and partial network failures the system never accounted for.