Offline POS Software in Nepal: Billing That Survives an Outage

Ask any shopkeeper in Kathmandu who has used a cloud point-of-sale system what happens when the internet drops, and you will get the same answer: the queue stops, someone starts writing on a pad, and at some point that evening a person sits down to type the pad into the system. Or does not.

Every bill written on paper is a bill that might never reach the books. Stock stays high in the system because the sale was never recorded. Cash in the drawer does not match the day’s sales report. The gap grows quietly and shows up weeks later as an unexplainable variance.

This is not a connectivity problem. It is an architecture problem. Software that requires the internet to complete a sale is the wrong shape for this market.

What offline-first actually means

The phrase gets used loosely. Genuinely offline-first means:

The local machine is the source of truth for the transaction. The bill is written to a database on the machine at the counter. It is committed there. Nothing about completing the sale involves a network call.

Sync is a background process, not a step. A separate process pushes local changes to the cloud and pulls remote changes down, whenever it can. If it cannot, it retries. The person at the counter never sees it and never waits for it.

Every record can be created anywhere. Bill numbers, IDs and references have to be generated locally without asking a server for the next number — otherwise the first thing that breaks offline is issuing a bill at all.

The system is honest about sync state. The owner should be able to see which counters have synced and when. A branch that has not synced in three days is a problem to fix now, not a surprise at month end.

What it does not mean is a cached web page that lets you browse products but not complete a sale. That is a cloud system with a nicer error message.

The hard part: bill numbering

This is where most offline implementations quietly break, and it matters more in Nepal than in many markets because bill numbers need to be sequential and gapless for tax purposes.

If two counters are offline simultaneously and both issue “Bill 1042”, you have a duplicate that surfaces at sync time, and resolving it by renumbering one of them means a customer’s receipt no longer matches the record.

The workable approaches all involve deciding the number space up front rather than reconciling afterwards:

• Per-counter series. Each counter has its own prefix and its own sequence. Counter A issues A-1042, counter B issues B-1042. Both are sequential within their series, no collision is possible, and the tax position is defensible because each series is complete.
• Pre-allocated blocks. Each counter is issued a block of numbers in advance and draws from it. Requires monitoring so a counter does not run out mid-outage.

What does not work is a shared sequence assigned at sync time. Bills get issued to customers before sync, and the number on the paper has to be the number in the system.

Conflict resolution has to be decided in advance

Stock is the other place offline systems get into trouble. If a counter sells the last unit of an item while offline, and another counter also sells it, the system will discover a negative stock position at sync.

The wrong answer is to block the sale. A customer standing at the counter with cash is not going to be told the system thinks the item might be gone.

The right answer is to let the sale complete, record it, and surface the conflict as an exception for someone to reconcile — because in a physical shop, the item was in the customer’s hand. The stock record was wrong, not the sale. The system’s job is to flag it, not to prevent it.

The same principle applies broadly: sales are facts and always win; master data changes — price updates, new items, user permissions — flow the other way and last-write-wins from the cloud is usually fine.

Sync should be incremental and resumable

A sync that transfers the whole database is fine on day one and unusable in year two. It needs to be change-based: each record carries a version or timestamp, and sync moves only what changed since last time.

It also has to survive being interrupted halfway, because on a marginal connection it will be. That means sync is a series of small committed batches, not one long transaction that either completes or is lost.

What you get from the cloud half

If billing works entirely offline, why sync at all? Because the local machine is useless to anyone who is not standing in front of it.

The cloud copy is what gives you:

• Consolidated sales across every branch, visible from anywhere
• Backup — a counter machine will eventually fail, and the shop’s history should not be on it alone
• Accounting and reporting that spans outlets
• Your auditor’s read-only access without visiting each shop
• Price and item changes pushed out centrally instead of updated on each machine

That combination is the actual goal: no dependency on connectivity to make a sale, and no dependency on being physically present to see the business.

Questions worth asking a vendor

• Can I complete a sale, print a receipt and open the cash drawer with the network cable unplugged? Ask for a demonstration, not an assurance.
• How are bill numbers generated offline, and what happens if two counters collide?
• What happens to stock if the same last unit sells at two counters during an outage?
• Can sync resume after being interrupted, or does it restart?
• How do I see, right now, when each branch last synced?

The first question eliminates most options immediately.

We build accounting, inventory and business software for companies in Nepal — marts, restaurants, bakeries, pharmacies and distributors — with local-first billing and background cloud sync. If your till stops when your internet does, talk to us.