Offline POS System: How Does a Cashier Work Without Internet?

If a product stops at level 1, selling practically stops during an outage. Level 2 keeps the kitchen going but the till jams. When levels 3 and 4 are not both present, the revenue does not reconcile at the end of the day: the record of outage sales is lost or processed twice.

The offline cashier is part of the Pro plan and works with the Genu Desktop application installed on the till computer. The cashier and the Desktop agent are designed to keep working when the connection drops; the flow below is the behaviour in the inventory.

• •Outage detection: a three-state state machine runs. A first network error counts as 'degraded' (temporary) and causes no alarm; with at least two consecutive errors and at least 10 seconds unreachable, the state becomes 'offline'. During an outage the Desktop window's title bar turns red and a full-screen offline warning badge appears.
• •Open bills stay visible: the cashier screen keeps showing the inside of open bills (order items, amount, payment status) from the live snapshot the agent downloads every 120 seconds; orders entered during the outage are overlaid on that snapshot and the screen updates instantly. The list of bills closed that day (the last 60 closings) can also be opened during an outage.
• •What can be done during an outage: opening a table, adding an order, taking payment, closing a bill, starting a shift and writing a debt to a customer account. An order can be entered on a table, a pickup/takeaway or a counter order and shows on screen at once; even if the page is refreshed or the cashier screen is reopened, the cashier opens during the outage, and a dine-in bill can be paid and closed. The bank transfer/EFT method (if enabled) is valid on the offline cashier too.
• •Receipts: for an order entered during the outage the kitchen ticket reaches the relevant station printer, and the bill receipt can be printed during the outage too. Happy hour discounts are calculated at the right price during the outage. Incoming print jobs are saved to a local SQLite queue; even if the computer restarts, unprinted jobs are not lost and printer definitions are not erased.
• •Every transaction is an event: each transaction is packaged as a deterministic local event and sealed with a time-ordered unique ID (ULID). A new order or table session opened offline is given a local clientId; when the connection returns, the cloud converts these to permanent IDs atomically and writes them to the mapping table.
• •One record, one print: even if the same event is sent twice because of a network flutter, the server applies it only once by event ID and transaction ID; the receipt is also de-duplicated in the print list. No order or receipt is processed twice.
• •By itself when the connection returns: the cashier does not need to press a button or refresh the page, and accumulated events flow to the cloud. While this device has transactions that have not yet reached the cloud, the cashier shows a 'Pending sync' tab with a counter; each pending transaction is listed with its time, table label and a description in Turkish. Neutral colour means no connection/waiting, green 'Syncing…' means the queue is flowing, and red 'Cannot sync' means the server rejected a transaction.
• •A stuck queue is never silent: in the red state a warning strip appears at the very top of the screen; the rejected line shows the server's reason in Turkish with guidance. Only a manager can say 'Skip this transaction'; the manager who skips, the time and a note are written to the audit line. The venue's last 7 days of offline event records (applied / skipped / failed) are shown in pages.
• •Report integrity: outage windows are kept on the local disk and, when the connection returns, listed in the end-of-day report as a 'Network Outage Window'. At a venue waiting for sync, the automatic end-of-day is skipped; a report is not produced from incomplete data.

The table below reports only what products say on their own sites. We left statements whose scope is not detailed as 'not detailed'; this means it is not written on the site, not that it does not work. Because we have not tested them ourselves, we pass no verdict of 'works' or 'does not work' on any product.

• •Set up the demo account with your own menu and open the application on the till computer; define an open table and a printer.
• •Unplug the till computer's network cable or turn off Wi-Fi. Check whether the product shows the outage on screen.
• •Open inside an open bill (items, amount); is it only the list or the detail too?
• •Open a new table and enter an order of two products; does the kitchen ticket come out of the printer?
• •Take a split payment (for example part cash, part card) and close the bill; is the bill receipt printed?
• •Restart the computer and open it again; does the cashier screen still open, are the printers and pending jobs in place?
• •Give the connection back and watch: do the transactions go by themselves, is anything recorded twice, are the pending ones visible, and who sees it if a transaction is rejected?
• •Open the end-of-day report: are the outage sales there once and with the right amount, and is the outage information visible in the report?

Each of these steps matches the behaviour in Genu's inventory; still, try it yourself on the demo account. The 30-day free trial requires no credit card. For broader selection criteria see the how to choose POS software and cloud, local and hybrid POS guides.

• •Restaurants and cafés in areas with an unstable internet infrastructure (tourist areas, bazaars, basements, the coast).
• •Venues where even a short outage at peak hours breaks table turnover and delays kitchen tickets.
• •Venues whose till must not jam at load peaks such as holidays, weekends and events.
• •Venues that want the end-of-day revenue kept in one go and correctly, independent of outages.