"Works offline" is on every point-of-sale feature list, and it usually means one thing: the app keeps letting you press buttons while the Wi-Fi is down. That is necessary and not nearly sufficient. A billing counter that keeps selling through an outage has to answer harder questions, and the answers decide whether the outage costs you an afternoon of reconciliation or nothing at all.
Here are the questions we think matter, and how BIZA's POS answers them.
1. What number goes on the receipt?
A tax invoice needs a number from a gapless sequence, and a sequence lives on the server. Offline, the billing counter cannot know the next number without risking a collision with another counter.
The honest answer is two numbers. The receipt prints immediately with the counter's own reference — unique to that device, good enough for the customer to return the item against — and says so: "Invoice number follows once this sale is sent". When the sale reaches the server it takes the next number in the business's sequence, and the reprint, the email and the WhatsApp receipt all carry the real invoice number. Nothing is renumbered, nothing is estimated.
2. Does anything get posted twice?
This is the one that bites. The connection flickers, the app retries, and the customer's single purchase becomes two invoices and two stock deductions.
Every sale in BIZA carries an idempotency key generated on the device. The server accepts a key once; a retry of the same sale returns the original result instead of creating a second one. The queue drains under a lock so only one tab on the device sends at a time, and it drains in order with barrier operations — a sale can never be sent before the shift it belongs to, and a return can never be sent before the sale it refunds. Two offline sales always produce exactly two invoices. This is tested, not promised.
3. What about stock, promotions and prices?
The billing counter holds a cached copy of the catalog — products, prices, stock levels at its location, promotions, price lists, serial numbers and batches — and refreshes it in the background when it can. Offline, it sells from the cache and tells the cashier how old the stock figures are.
Two settings decide policy: whether the billing counter may sell at all while offline, and whether it may sell below the stock figure it last saw. When the sale syncs, the server re-validates everything — the promotion really was running, the serial number really was on hand, the coupon really had uses left. If a check fails for a reason a retry cannot fix, the sale stays visible on the counter as needs attention, with the reason, until a cashier deals with it. Nothing is dropped silently.
4. Can I take a return offline?
Returns are where many offline modes quietly give up, because the original sale is on the server. BIZA's counter keeps its own copy of every sale it rang, so a return can be started against that copy while offline. The return is queued behind the sale it refunds; when both sync, the server issues the credit note and caps the refund at what has not already been returned. If the original sale was completed on a different counter, the return waits for a connection — and says so.
5. Does the drawer stay right?
Counter open, counter close and every cash movement queue exactly like sales. A shift opened offline still records its counted float; a close still records the blind count; the Z report is computed on the server once the queue has drained, from the same rows as everything else. The expected cash figure never depends on whether the outage happened before or after a sale.
6. What does the cashier see?
As little as possible. A small Offline badge and a N to send counter in the billing counter strip; a Send now button for the impatient; and a list of unsent sales with their state — waiting, sending, retrying, needs attention. Receipts print, the drawer opens, the customer leaves. Most cashiers never notice the connection came and went.
Why this matters more when the POS is your accounting
For a POS that syncs a day-end summary to a separate accounting system, an outage is annoying but contained: the summary is just later than usual. For a POS that is part of the accounting system — where each sale is a numbered invoice and a journal entry — the offline design has to be right, because a duplicate is not a reconciliation note, it is a duplicate tax invoice.
That is why the queue, the idempotency keys, the ordering guarantees and the "needs attention" state exist. They are what make it safe to have one system of record and still keep the doors open when the router is not.
How BIZA helps
BIZA's point of sale is offline-first by design, on desktop, tablet and phone, and posts every sale to your own books exactly once. Read the guide to offline selling, shifts and cash control, or talk to the team.