Offline POS Machine in Bangladesh: What Works Without Internet?

Last verified: 2026-08-28

An offline POS machine should keep the minimum sale moving when internet fails. That usually means opening a cached menu, creating a cash order, calculating the total and storing it safely for later synchronisation.

It should not be assumed to authorise online payments, receive new online orders or show live multi-device updates without connectivity. Ask the vendor to demonstrate each function during a real disconnect.

What can and cannot work offline

Local-first vs cloud with offline queue

A fully local POS stores its primary database on one machine or local server. It can work through a long internet outage but needs local backup, maintenance and a plan for remote reporting and multi-branch sync.

A cloud POS with an offline queue keeps selected operations on the device and synchronises after recovery. It is easier across devices, but the offline scope must be explicit. Neither architecture is automatically better for every restaurant.

Rosuii's honest offline boundary

After required data has synced, Rosuii can queue cash orders locally and upload them when the connection returns. This protects basic billing during a short outage.

Online payments, new online orders and live KDS or other multi-device updates require internet. Rosuii should not be marketed as fully offline. A broadband line plus mobile-data backup is the practical Bangladesh setup.

Printer and network details

A USB printer connected to the offline billing device may keep working if the browser and driver path are local. A LAN printer can work on a live local network even when the upstream internet is down, but cloud routing may still be unavailable.

Test power loss as well as internet loss. A small UPS for router, terminal and printer can prevent a two-minute voltage cut from becoming a reboot and lost queue.

Payments during outage

Cash can be recorded offline when supported. Do not mark a card, bKash or Nagad transaction paid merely from a customer screenshot without following the payment provider's verification process.

Write a policy: which methods are accepted, who can approve an exception and how pending payments are reconciled after the connection returns.

Thirty-minute outage test

• Sync menu and sign in normally
• Disconnect internet without closing the POS
• Create and print two cash orders
• Try a prohibited online payment and confirm it fails safely
• Check whether kitchen output behaves as documented
• Reconnect and verify each queued order appears once
• Run day close and reconcile cash
• Repeat after device restart if the vendor claims restart support

Offline buying questions

• Which data must sync first?
• How many orders can queue?
• What happens after restart?
• How are duplicate syncs prevented?
• Which price or stock conflicts win?
• Can staff see unsynced orders?
• What backup and export exist?

Offline is a list of tested functions

A POS should state exactly what works without internet: login, menu access, new order, edit, kitchen output, cash payment, digital payment request, receipt, close and reporting may have different dependencies. Offline capable is not a single yes/no fact.

Ask how long data remains usable, which device owns it, what users see and what happens after reconnect. Do not promise uninterrupted operation without a tested scope.

Offline function matrix

Pending must remain visibly different from synchronized or settled.

Conflict and duplicate prevention

Use unique device and order identifiers, occurrence time and idempotency. If two devices sell the last item offline, the server needs a documented reconciliation and customer-recovery route; it cannot pretend both had current stock.

Never generate a second sale merely because the cashier retries. Preserve failed and corrected events with user and reason.

Branch outage drill

Run on actual devices and network. Record what is supported, prohibited and manual, plus the owner who reconciles the outage window.

Prepare a paper or alternate-device fallback only for the transactions the restaurant can later enter and identify without duplicate payment or production. Number fallback records, capture original occurrence time and responsible user, and mark the later system entry as recovery rather than a new customer order.

After reconnect, compare queued, synchronized, rejected and manually recovered records to kitchen tickets, payments and cash. Resolve conflicts before closing the incident. Record the cause, affected period, customer remedies and control change. Review logs without exposing customer contact or payment secrets.

• Internet loss before login
• Loss during open order
• Cash order and kitchen print
• Digital payment pending
• Two devices edit same table
• Menu changes on server
• Reconnect with queued orders
• Duplicate event delivery
• Close before sync
• User deactivated during outage

Choose an offline POS by the tested failure path, not the label. For most Bangladesh restaurants, limited offline cash billing plus reliable backup mobile data gives a practical balance.

Related guides

• Offline POS Billing in Bangladesh
• Restaurant Billing During Internet Problems
• Restaurant PWA POS
• Compare restaurant management software

See this workflow in Rosuii: Understand Rosuii offline billing limits

Sources checked

• Stripe official POS systems guide

Start using Rosuii for free