Offline POS without double billing: what happens when the connection drops

The risky moment is not "offline"

A till that is clearly offline is easy to handle: it keeps a queue of sales and sends them when the connection returns. The risky moment is the one in between. The till sends a sale, the connection drops before the reply arrives, and nobody knows whether the server recorded it.

From the counter, that sale is uncertain. It may already be an invoice with stock deducted and cash expected in the drawer. It may never have arrived. How your point of sale handles this one case decides whether you end up with duplicate invoices, missing sales or a cashier quietly guessing.

Three states, not two

Every offline sale is in one of three states:

1. Not sent. It is still in the till's queue. Safe to send.
2. Posted. The server confirmed it. Nothing more to do.
3. Uncertain. It was sent, but no confirmation came back.

Many problems come from treating the third state as if it were the first or the second.

Why the obvious fixes go wrong

• Resend it. If the first attempt did arrive, you now have two invoices, stock deducted twice and a receivable that does not exist.
• Delete it locally. If the first attempt did not arrive, the sale is gone. The cash in the drawer will be over at the end of the day, and nobody will know why.
• Edit it and send again. Now there may be two different versions of the same sale in the books, with different totals.
• Leave it to the cashier. Busy counter staff will make a reasonable guess, and some of those guesses will be wrong.

Principles of a safe offline point of sale

When you evaluate a point-of-sale system, or design your own procedure, look for these principles.

1. Every sale attempt has its own identity

Each sale created on the till carries a unique identifier from the moment it is rung up. If the same attempt reaches the server twice, the server recognises it and records it once. Engineers call this idempotency; for the business it means a retry can never create a second invoice.

2. Ask the server before acting on an uncertain sale

An uncertain sale should be resolved by asking the server what happened, not by guessing. If it was posted, the till should mark it posted and link to the invoice. If it was not, the till can proceed.

3. Retire the attempt that did not arrive

There is a subtle trap. The server says "not received", the cashier corrects the sale and sends it again, and then the original, delayed copy finally arrives. A safe system records the original attempt as retired when it confirms it was not posted, and refuses that attempt if it turns up later.

4. Keep the invoice number

Customers may already hold a printed receipt. A corrected sale should keep its invoice number so the paper and the books agree.

5. Never discard what might have posted

If the server cannot yet say either way, for example because the attempt is still being processed, the sale stays uncertain. It is better to leave it for a supervisor than to throw it away.

Branches matter offline, too

In a business with several branches, an offline sale still has to land in the right place. Stock should be deducted from the branch that actually handed over the goods, and the sale should appear in that branch's figures. That means the till needs the list of branches available offline, and checkout should require a branch whenever there is more than one.

A simple counter procedure

1. Keep selling when the connection drops. Print receipts as usual.
2. When the connection returns, let the till send its queue.
3. Before end-of-day settlement, a supervisor reviews any uncertain sales and checks their posting status.
4. Posted sales are left alone. Sales confirmed as not posted are corrected or discarded deliberately, with the reason noted.
5. Count the drawer only after every uncertain sale is resolved, so differences are real differences.

Decide in advance who may correct or discard an offline sale. Cashiers should be able to sell offline; correcting a sale that might affect the books is a supervisor's decision.

The same problem in the back office

Duplicates are not only a till problem. A supplier return saved on a slow connection can be submitted twice when someone clicks again. The same principle applies: give the operation an identity, and let the server record it once however many times it arrives.

How NAQIX handles it

NAQIX's point of sale keeps selling offline and follows the principles above.

• When a sale's status is uncertain, Check posting status asks the server whether it was posted.
• If it was, the sale is marked posted and linked to its invoice, so it is never billed a second time.
• If it was not, the server records that attempt as retired, so a delayed copy is refused. Only then can the sale be corrected or discarded, and the corrected sale keeps its invoice number.
• If the answer is not yet known, the sale stays uncertain.
• In a company with several branches, the branch list is available offline and a branch is chosen at checkout.

In the back office, supplier returns are recorded once, even when a network retry sends them twice; see the Purchasing page.

Questions to ask any point-of-sale vendor

• What happens to a sale that was sent but not confirmed?
• Can a retried sale ever create a second invoice?
• If a corrected sale is sent, what stops the original copy posting later?
• Does the receipt number survive a correction?
• How does an offline till know which branch it is selling from?

Ask for a demonstration with the network unplugged at the wrong moment. The answer is more informative than any feature list.