Offline-first point of sale: keeping stores trading

Offline-first point of sale means the till is the system of record for the duration of an outage — it scans, prices, takes payment and prints locally, then reconciles every transaction when connectivity returns. The hard part is not capturing sales offline. It is reconciling them afterwards without double-counting, overselling, or quietly losing a basket.

“Offline mode” and offline-first are not the same thing

Most point-of-sale systems advertise an offline mode. In practice that usually means a degraded fallback: the till caches a price list, accepts cash, and queues transactions in a local file. It works for a short blip and starts producing exceptions after an hour.

Offline-first is an architectural decision rather than a fallback. The till writes to a local store first and treats the server as a peer to sync with, not a dependency to call. Every transaction carries an identifier generated at the till, so the same sale can be submitted repeatedly without being counted twice. The store keeps trading for the length of the outage rather than the length of a cache.

The distinction shows up in one question: what happens at hour three? A fallback mode degrades — price lookups miss, promotions stop applying, returns cannot be validated. An offline-first till behaves the same at hour three as at minute one.

Reconciliation is the actual engineering problem

Capturing a sale offline is straightforward. The difficulty is what happens when a few hundred tills across an estate all reconnect and replay their queues into a system that has also been serving an online storefront the whole time.

Three properties make that survivable:

• Idempotency. Every transaction gets a globally unique identifier at creation, on the till. Replaying it is a no-op. Without this, a flaky reconnect that retries a batch produces duplicate revenue and duplicate stock movements — and duplicates are far harder to find after the fact than missing records.
• Deterministic ordering. Transactions carry a monotonic sequence per till plus a timestamp. Reconciliation applies them in a defined order rather than arrival order, so a slow till's late batch does not overwrite a later state.
• Explicit conflict rules. When an offline sale and an online sale both claim the last unit, something must give. The rule should be written down and enforced by the system, not decided ad hoc by whoever notices first.

Stock truth during an offline window

This is where offline-first collides with omnichannel. If a store is offline for two hours and sells forty units, the central stock ledger does not know. Meanwhile the storefront is happily selling the same units online.

There is no way to make that impossible without giving up either offline trading or online availability. What you can do is bound the exposure:

• Reserve rather than deduct. Online orders hold a reservation against available-to-promise stock, not a hard decrement. Reservations expire, which limits how long a phantom hold blocks real demand.
• Hold a buffer per location. Fast-moving lines keep a small quantity unavailable to the online channel. It is deliberately unsold inventory in exchange for not cancelling customer orders — usually a good trade on the lines where a cancellation is most likely.
• Prefer ship-from-store fallback. When a reconciliation reveals an oversell, the order should reroute to another location automatically rather than surfacing as a customer-facing cancellation.

The goal is not zero conflicts. It is that conflicts resolve into a fulfilled order rather than a refund and an apology.

Payments are the part that carries real risk

Card payments offline mean store-and-forward: the terminal captures the authorisation locally and submits it when the link returns. Some of those submissions will decline, and by then the customer has left with the goods.

That risk is managed with floor limits — a value ceiling below which offline authorisation is accepted — and with card-scheme rules that differ by region and by scheme. The important governance point is that this is a commercial decision, not a technical default. Someone with authority should be setting the floor limit deliberately, and the reporting should show what the offline decline rate actually is, per store and per period. If nobody can answer that question, the limit is a guess.

Testing it honestly

Offline behaviour is almost always tested in the least representative conditions: one till, a clean network cut, a short window, an empty basket queue. Real outages are messier.

The tests worth running before go-live:

• Partial connectivity, not a clean cut. High latency and intermittent packet loss break more systems than a hard disconnect, because requests hang instead of failing fast.
• A long window. Multiple hours, spanning a shift change, so you find the local storage limits and the queue-growth behaviour.
• Simultaneous reconnect. Every till in a region coming back at once, which is what happens after a regional network incident and is precisely when the reconciliation path is least tested.
• Reconciliation with contention. Online orders competing for the same stock during the offline window, so the conflict rules actually fire.
• Returns and exchanges offline, where the original transaction is not locally available for validation.

What to ask a vendor

These questions separate offline-first architecture from an offline checkbox on a feature matrix:

• Where is the transaction identifier generated — at the till, or by the server?
• What is the documented conflict rule when an offline sale and an online sale contend?
• How long can a till operate offline before behaviour degrades, and what degrades first?
• What happens to promotions, loyalty accrual and returns validation while offline?
• Can I see the reconciliation exception report from a real outage, not a demo?

The last one is the most revealing. Every estate has offline exceptions. A vendor who can show you the report, explain the categories and tell you the typical volume is describing a system that has been through real outages. A vendor who says exceptions do not occur is describing a system that has not.

Where to start

If you are assessing an existing estate, the first measurement is not uptime — it is how many transactions were captured offline in the last quarter and how many of those produced a reconciliation exception. That ratio tells you whether offline trading is genuinely working or quietly generating manual cleanup that someone absorbs at month end.