How we made a POS keep billing when the internet and power go down

If you build software for shops in Pakistan, you learn one thing fast: the internet is not a safe assumption.

Power cuts, a router that needs a restart, a mobile network that drops at 6pm when every shop is busy. Any of these can happen while a customer is standing at the counter waiting for a bill. If your POS needs a live server connection for every sale, that customer walks out and the shop loses money.

That's the problem we wanted to fix when we built the POS in AmalERP.

The problem with "online only" POS

A lot of cloud POS tools work like this: you click "Save sale", the app sends it to the server, and the server replies "ok". No reply, no sale.

It's simple to build, but in a country with unreliable internet it breaks at the worst moment. Shop staff also don't know what went wrong. They just see a spinner and an angry customer.

The idea: the shop never waits for the server

Instead of treating the server as the source of truth at the moment of sale, we treat the device as the first place a sale is saved.

1. The cashier makes a sale.
2. The sale is saved on the device immediately, so the bill prints and the customer leaves.
3. The app checks if the internet is available.
4. If yes, it sends the sale to the server in the background.
5. If no, the sale stays in a queue and is sent later when the connection returns.

The cashier never has to think about steps 3 to 5. Billing just works.

What happens when the internet comes back

When the connection returns, the queued sales are sent to the server in the order they were made. Stock levels and accounts update from there.

A few things we had to be careful about:

• No duplicate sales. If the connection drops halfway through a sync, the same sale must not be counted twice.
• Correct stock. Two devices selling the same item offline can both reduce stock, so the server has to reconcile them properly.
• Clear status. Staff should see which sales are synced and which are still waiting, so nobody panics.

Why this matters more than any feature list

When shop owners compare software, they usually compare reports, pricing and screens. But the thing that decides if staff like a POS is much simpler: does it ever stop them from selling?

A POS that works through load shedding earns trust quickly. And once the staff trust it, everything else (inventory, accounts, reports) actually gets used.

What we learned

• Design for the bad day first. The good day takes care of itself.
• Tell the user clearly what's happening. A small "will sync later" message removes a lot of panic.
• Test with real shops, not just a fast office connection.

If you're building something similar, I'd love to hear how you handle offline sync. And if you run a shop and want to try offline billing, you can check out AmalERP.