How to Run Retail Point of Sale Platforms Offline and Sync Sales Later

Every retail point of sale (POS) platform claims it can run offline. Fewer can tell you, with any precision, what happens to a card payment taken thirty seconds before the connection dropped, or where the stock count lands once three tills reconnect at different times. That gap between the marketing claim and the operational reality is where retailers lose money, not during the outage itself, but in the hour after it ends.

This is a playbook, not a buyer's checklist. If you are still evaluating whether your platform's offline mode is any good, BC4 has already written that piece: How to Choose a Reliable Offline POS Mode for Retailers. What follows here is for retailers who already have offline capability switched on and need to know exactly how to run it: how to keep taking payments safely, how to protect stock accuracy while disconnected, and how to reconcile everything cleanly once the network comes back.

We cover offline transaction processing step by step, from the moment connectivity fails to the moment your reports match reality again.

Before the Outage: What "Offline Ready" Actually Means

Offline mode reliability is not something you switch on during an outage. It is a state your retail point of sale (POS) platforms need to be in before the outage starts, and most retailers never check whether they are actually in it.

A terminal that is genuinely ready to trade offline holds a current local copy of products, prices, promotions and customer or loyalty data, refreshed continuously while it has a connection. If that refresh cycle has been quietly failing for two weeks because of a misconfigured sync job, the terminal will drop into offline mode with stale prices and no one will notice until a customer is undercharged, or overcharged, at scale.

So the first step in any offline playbook happens on a normal Tuesday, not during a crisis. Confirm your point of sale estate is refreshing master data on schedule, confirm payment devices are configured for standalone or token based authorisation, and confirm every terminal, not just the ones at your flagship store, has been tested offline in the last quarter. If you cannot answer those three questions with confidence, fix that before you worry about the reconnection process.

Capturing Payments Safely During an Internet Outage

Payment processing during an internet outage is the part staff panic about, and rightly so. It is also the part where the wrong instinct causes the most damage.

When a terminal loses its connection, a well configured system does not simply refuse cards. It authorises locally, either through the payment device's own standalone capability or through stored authorisation tokens with a defined floor limit, and queues the transaction for submission once the connection returns. This is standard offline transaction processing, and it carries a specific trade off worth understanding: authorisation is provisional. The card is not checked against the issuer in real time, so a small proportion of offline transactions will come back declined or flagged once the connection is restored and the batch is submitted.

That trade off is manageable if you set it up properly in advance:

• Agree a transaction value ceiling for offline authorisation with your payment processor, so a single large offline sale cannot expose the business to an outsized loss.
• Make sure card data is encrypted at the point of capture and in local storage, not held in plain text on the terminal while it waits to sync. This is a PCI compliance requirement, not a nice to have.
• Brief staff on what offline mode looks like on screen, so nobody mistakes a normal offline authorisation for a system fault and starts turning customers away unnecessarily.
• Set a maximum offline window. Most processors expect stored transactions to be submitted within a defined timeframe; leave it too long and you risk losing the ability to process the sale at all.

Cash, obviously, has no such problem. The risk sits entirely with card and contactless payments, which is exactly why offline authorisation limits and encryption matter more than any other single control in this playbook.

Keeping In-Store POS Systems Accurate While You're Disconnected

Payments get the attention during an outage, but stock accuracy is where the damage usually shows up days later, in a discrepancy report nobody can explain.

Well architected in-store POS systems decrement stock locally the moment a sale is rung through, whether or not the terminal is connected. The decrement then queues alongside the transaction and reconciles centrally on reconnection. That sounds simple until two terminals in the same store both sell the last unit of the same product while both are offline. Neither terminal knows about the other's sale, and the sync process has to make a judgement call about which sale stands and which one now needs a stock correction, a refund, or a backorder conversation with a customer.

The same logic applies to anything that relies on shared, live data: loyalty point balances, gift card and voucher redemption, and any promotion with a capped number of redemptions. If two terminals accept the same voucher code while both are offline, you will find out about the double redemption at reconciliation, not at the till. None of this means offline trading is unsafe. It means the sync process needs to treat these conflicts as an expected part of normal operation, not an edge case, and your team needs a defined process for resolving them rather than discovering them by accident in next week's stock take.

The Reconnection Playbook: Getting Inventory and Sales Synchronisation Right

The moment connectivity returns is where most of the operational risk in offline trading actually lives, because it is the moment everything queued during the outage arrives at once.

Run the reconnection in this order:

• Let transactions sync automatically first. Most systems check for connectivity on a short interval, often every sixty seconds, and begin uploading queued transactions without staff intervention. Resist the urge to force a manual sync immediately; let the automatic process run and confirm it is progressing before you touch anything.
• Pull the offline transaction report before you do anything else. This should show every transaction taken while disconnected, and its current status: approved, declined, or still pending. This is your single source of truth for what needs following up.
• Action the declines immediately. A card that declines on reconnection is now an unpaid transaction for goods the customer has already taken. Depending on value, this might mean a follow up call, a write off, or a lesson for your offline authorisation limits.
• Reconcile stock conflicts before the next trading day. Any product that was sold offline by more than one terminal needs a clear resolution: which sale stands, and what happens to the customer who now has no stock. Don't let this roll into the following week.
• Check pricing and promotion consistency. If master data was stale on any terminal during the outage, some customers will have been charged the wrong price. Decide your policy on this before it happens, not while a customer is at the till.

Retailers running stock and warehouse management as part of the same platform have an advantage here: because the reconciliation happens against the same source of truth the rest of the business already uses, there is no separate integration step where errors can creep in. If your offline POS and your inventory system are different products stitched together, this is usually where the sync breaks down.

How Business Central and LS Central Handle Offline Mode

The reason this playbook is workable at all comes down to architecture, not luck. LS Central, as implemented by BC4 on Microsoft Dynamics 365 Business Central, is built for full terminal level offline trading with automatic sync back to the central system, rather than treating offline as a bolt on fallback mode.

In practice, this means the till itself holds a genuine local database, not a thin cache pointing back at a server that has gone dark. Master and setup data is pushed down to terminals continuously, most commonly using Web Replication over Azure Storage in current LS Central versions, which removed the need for retailers to run and maintain a separate on premises replication server. The Scheduler that manages this can sit in Head Office in the cloud while offline terminals keep trading independently of it, and LS Central maintains backwards compatibility across several major versions specifically so that offline tills don't need to be upgraded in lockstep with Head Office.

The result, when it is implemented properly, is that a network outage becomes an inconvenience rather than a trading stoppage. It is one of the reasons retailers including Selco Builders Warehouse were able to move 74 stores onto this architecture without losing trading time in the process.

None of this removes the need for the discipline covered above. Good architecture makes offline trading possible; it does not make payment limits, stock conflict resolution, or reconciliation checklists optional. The businesses that get the least value out of a strong offline capable platform are the ones that never build the operational habits to use it properly.

Frequently Asked Questions

Can retail point of sale (POS) platforms take card payments during an internet outage?

Yes, provided the platform supports offline transaction processing. Card payments are authorised locally through the payment device or stored tokens, within a defined floor limit, and submitted for full authorisation once connectivity returns. A small proportion may be declined at that point, which is why transaction limits matter.

How long can a till run in offline mode before it needs to reconnect?

This depends on your payment processor's rules and your POS platform's configuration, but most processors set a maximum window for submitting stored offline transactions. Confirm your specific limit with your processor rather than assuming; running past it can mean losing the ability to process the sale entirely.

What happens to stock levels when two tills sell the same item offline?

Both sales queue locally and the conflict surfaces at synchronisation. A defined reconciliation process, rather than an ad hoc one, should determine which sale stands and how the resulting stock or refund issue is resolved with the customer.

Does offline mode work the same way for loyalty points and gift vouchers?

Not exactly. Loyalty lookups and voucher redemptions that depend on live, shared data carry the same double redemption risk as stock. Retailers should treat these the same way as inventory conflicts: expect them, and have a resolution process ready rather than discovering the issue during reconciliation.

Is offline transaction processing safe from a PCI compliance standpoint?

It can be, provided card data is encrypted at capture and in local storage while the terminal waits to reconnect. This is a standard requirement of PCI compliant offline processing, not an optional configuration, and it should be confirmed with your payment provider before you rely on offline mode in production.

What is the biggest mistake retailers make when running POS offline?

Treating the reconnection as an afterthought. Most of the operational risk in offline trading surfaces in the minutes after connectivity returns, when queued transactions, stock conflicts and price discrepancies all need resolving at once. Retailers who plan for that moment recover cleanly; those who don't spend the following week untangling it.