Offline restaurant billing software
that keeps taking orders.
Billing, KOTs and cash payments run from the device, not from the cloud. Orders queue locally during an outage and reconcile automatically the moment the connection returns.
Cloud POS has one failure mode, and it is the expensive one
A cloud point of sale is the right architecture for almost everything: no server in the back office, updates that happen without a visit, data that survives the tablet being dropped. The trade is that a naive implementation stops working when the line does.
In an Indian restaurant that is not a theoretical risk. Fibre gets cut by roadwork, the backup connection turns out to have been unplugged in March, the mall's shared link degrades at exactly the hour everyone is trying to use it. The outage is not usually long. It is usually twenty minutes at seven in the evening, which is the worst twenty minutes you have.
What happens next in most restaurants is a paper bill book, and what happens after that is a reconciliation exercise the following morning that nobody does properly. The revenue that goes missing during an outage rarely goes missing during the outage itself. It goes missing during the re-entry.
What actually happens when the line drops
- 01
Nothing visible, at first
The terminal does not change mode or ask anyone to do anything. Order entry, bill printing and KOT printing were already being served from the device, so they continue.
- 02
Orders queue locally
Each order is written to the device with its own identifier and held in an outbound queue. Cash payments complete normally because cash does not require a network.
- 03
Card and UPI are the exception
Those genuinely need connectivity, and no software can change that. Omega shows them as unavailable rather than appearing to accept a payment that did not happen.
- 04
Reconciliation on reconnect
The queue drains in order. Because every order already carries an identifier assigned on the device, replaying the queue cannot create duplicates, and aggregator orders that arrived during the gap are pulled in at the same time.
Why the local device is the source of truth
The distinction that matters is whether the terminal is a screen for a remote system or a system in its own right that synchronises. Omega is the second. The order is real the moment it is written locally, which is why the interface does not need to change behaviour during an outage.
This also removes a subtler problem. Systems that treat the cloud as authoritative tend to become sluggish on a slow connection rather than failing cleanly, so the counter gets a system that technically works and practically cannot be used at speed. A local-first design has consistent latency whether the connection is good, bad or absent.
What keeps working
Order entry
Full menu, modifiers, tables and tabs. No degraded mode, no reduced item list.
KOT printing
Tickets print to the kitchen over the local network or a directly attached printer.
Bill printing
GST-compliant invoices with correct tax lines and sequential numbering maintained locally.
Cash payments
Completed and recorded on the device, reconciled into the day's takings on reconnect.
Kitchen display
Continues on the local network. The KDS and the terminal talk to each other, not through the cloud.
Reporting, afterwards
Once the queue drains, the day reports as a single continuous shift rather than as two halves with a hole.
Common questions
How long can Omega stay offline?
There is no fixed time limit. The constraint is device storage, which in practice means a terminal can run through an outage far longer than any outage you are likely to have. The relevant limit is not duration, it is that card and UPI payments cannot be taken while the line is down.
Will replaying the queue create duplicate orders?
No. Every order is assigned an identifier on the device at the moment it is created, before any network call. The server treats a repeated identifier as the same order, so a queue that is interrupted mid-drain and retried produces the same result as one that drains cleanly.
What about aggregator orders that arrive during an outage?
Those are held by the platform, since the platform cannot reach you either. When connectivity returns, Omega pulls the orders that arrived during the gap into the queue. This is the part that usually goes wrong with a paper fallback, because nobody re-enters aggregator orders by hand.
Do I need a local server in the restaurant?
No. The terminal itself holds the data and the kitchen display talks to it over the local network. There is no back-office machine to maintain, which is deliberate: an on-premise server is one more thing that fails at seven in the evening.
Related
Stop wrestling your POS.
Tell us about your outlet and we will show you the system running on your own menu.
Book a demo