Offline Billing Software for Shops With Unreliable Internet: What 'Offline-First' Really Takes

Good offline billing software keeps the counter selling when the internet drops: each sale is recorded on the device and synced to the server once the connection comes back.

Without that, a dropped connection on a busy afternoon means a spinner on the billing screen, a customer waiting at the front and a queue that starts to leave. For a shop, billing software that can't work offline is a single point of failure.

In many places, including Lahore where we're based, connections drop more often than anyone would like. We've built an offline-first billing application with thermal-printer receipts for exactly this reason, and a billing and inventory system for Ahad Brothers, an educational shop, where every sale and stock change is recorded together.

"Works offline" is easy to promise and hard to get right. This guide covers what it really takes, whether you're building or buying. It's the kind of system we build as business process software.

The one rule: the counter never waits for the network

An offline-first system flips the usual design. The device works from its own copy of what it needs (products, prices, the current shift's bills), and the server is where everything ends up, not where the counter waits for permission.

When the connection is up, changes reach the server in the background within seconds. When it's down, they queue and go later. Either way, the cashier sees the same fast screen. Everything below follows from that rule.

1. Give every bill an ID the device can create on its own

In an online system, the server usually numbers each new record: 1041, 1042, 1043. Offline, two counters would both create "bill 1042".

The fix is for each device to create a unique ID when the bill is made (a random UUID is the usual choice), so records never collide when they sync. For the bill number customers see, use a series per counter, such as A-00518 and B-00231.

If your tax rules require a single continuous sequence of invoice numbers, check them before designing this part. It's one of the few places where local law shapes the database.

2. Sync with an outbox, and make retries safe

Every change the counter makes (new bill, payment, return) goes into a local outbox queue. A background process sends the queue to the server whenever it can.

The hard part is what happens when a request times out. Did the server save the bill or not? If the device simply sends it again, you might record the sale twice.

The standard answer is an idempotency key: a unique value sent with each change, which the server remembers. Payment providers such as Stripe use the same idea. If a request with that key arrives again, the server returns the saved result instead of doing the work twice. Combined with the bill's own unique ID, that makes retries harmless.

On the server, record each bill and its stock changes in a single database transaction, so they're saved together or not at all. That's how the system we built for Ahad Brothers keeps sales and stock telling the same story.

3. Record stock as movements, not as a number

This is where homemade offline systems often go wrong.

Suppose two counters both start with "Notebook: 10 in stock". Offline, counter A sells 2 and counter B sells 3. If each device syncs its new stock figure, the server receives "8" and then "7", and the last one wins. The real answer is 5.

So never sync the stock figure. Sync movements instead: "−2 sold at counter A", "−3 sold at counter B", "+50 received". Stock is the sum of movements, so every sale counts, in any order.

Two decisions follow:

• Can stock go negative? Offline, two counters can sell the last item. Blocking the sale annoys a real customer. Allowing it and flagging the shortfall for the shop to check is usually better.
• Prices at the moment of sale. Store the price on each bill line, so if the price list changes while a counter is offline, the bill still shows what the customer actually paid.

4. Receipts must print without the internet

A sale isn't finished until the customer has a receipt. Receipt printers typically speak ESC/POS, a command language that Epson created and many other brands follow. A billing app can print in one of three ways:

• The browser's print dialog, with a page sized for 80 mm or 58 mm paper. It works offline and needs no special drivers, but shows a dialog for each receipt unless the device is set up for silent printing.
• A small local print helper on the counter computer, which the app sends receipts to. Fast and reliable, but one more thing to install and maintain.
• WebUSB, which lets a web app talk to a USB printer directly. Chrome and Edge support it; Safari and Firefox don't. It only fits counters running Chromium-based browsers.

Whichever you choose, test it with the router unplugged.

5. Don't trust the browser to keep data forever

A browser-based billing app keeps its offline data in browser storage, usually IndexedDB. That storage is generous, but browsers can clear it when the device runs low on space, and WebKit (Safari) can also remove data for sites that haven't been used for a while.

• Ask the browser for persistent storage (navigator.storage.persist()), which makes eviction less likely.
• Sync often. The less that only exists on the device, the less you can lose.
• Show the cashier how many changes are waiting to sync, so a stuck queue doesn't go unnoticed for a week.

For counters that must work offline for days at a time, a desktop app with a local database can be the safer choice. If the counter is an iPad or iPhone, check what a PWA on iPhone can and can't do first, including how Safari treats stored data and its lack of WebUSB.

6. Payments: cash works offline, cards usually don't

Cash sales are easy to record offline. Card payments generally need the card terminal or payment provider to be online. Decide in advance how the counter handles a card payment during an outage: switch to cash, use a terminal with its own mobile connection, or record it as pending and confirm later, if your provider allows that. Make the call on a quiet day, not with a queue at the counter.

How to test offline billing software before you trust it

Before it runs a real shop, try to break it:

1. Unplug the router mid-shift and keep billing for an hour. Plug it back in and check every bill arrived once.
2. Close the app halfway through a sale, then reopen it.
3. Sell the last item on two counters while both are offline.
4. Change a price on the server while a counter is offline, then sell that product.
5. Set a device's clock wrong. The system should record both the device time and the server's time on sync.
6. Pull the printer cable mid-receipt and make sure the sale isn't lost.

Questions to ask a vendor who says "it works offline"

• What exactly works offline: billing only, or returns, stock checks and reports too?
• How long can a counter stay offline before something breaks?
• How do you stop a sale being recorded twice when the connection is flaky?
• What happens when two counters sell the last item?
• Where is the data stored on the device, and what happens if the device is lost or wiped?
• Can receipts print with no internet?

Vague answers to any of these are a warning sign. If you're having the system built instead, put the same questions in writing in your software project scope.

Frequently asked questions

The bottom line

Offline-first isn't a feature you add at the end. It's decided at the start, in how bills get their IDs, how sync retries, how stock is counted and how receipts print. Get those right and an outage becomes a non-event at the counter.

Planning billing or inventory software for a shop where the internet can't be trusted? Book a free consultation and we'll walk through what your counters need to handle when the connection drops.

Sources

• MDN Web Docs, IndexedDB API: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
• MDN Web Docs, StorageManager.persist(): https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
• WebKit, Updates to Storage Policy (August 2023): https://webkit.org/blog/14403/updates-to-storage-policy/
• Stripe API reference, Idempotent requests: https://docs.stripe.com/api/idempotent_requests
• MDN Web Docs, WebUSB API (browser compatibility): https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
• Epson, ESC/POS command reference: https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/index.html