The internet goes down. Your counter doesn’t.

It is 7 PM on a Saturday. There are six customers at the counter, two more deciding between shades of the same suit piece, and the broadband light on the router turns red. In most shops, that is the moment billing stops. Out comes the duplicate book. Tomorrow somebody spends an hour keying yesterday into the computer, hoping the stock still tallies — and it usually doesn’t, because two of the paper bills are illegible and one was written for the wrong design.

Kapda Stock is built for shops where the line is not always reliable, which in much of India means every shop. When the server cannot be reached, POS billing does not fail. It parks the sale on the device, clears the cart, and lets you serve the next customer. The bill becomes a real invoice with a real number the moment the connection returns.

This post is the honest, complete version of how that works — including the parts that do not work offline, because knowing where the edge is matters more than a marketing promise. If you want the reference version rather than the explanation, it lives in Offline mode & sync.

Why offline billing is harder than it sounds

It is easy to say "works offline" and much harder to mean it. A billing app is not a notes app: a sale changes the stock on hand, the customer’s outstanding balance, the day book, the GST figures for the month and the running invoice number. Every one of those is shared. Two counters and a phone all touch the same numbers, and the server is the only thing that knows the truth about all of them at once.

So a system that lets every device invent invoice numbers while disconnected creates duplicates. A system that lets every device deduct stock independently oversells. A system that quietly buffers everything creates an hour of reconciliation the next morning — which is exactly the problem the paper duplicate book already has.

The design decision in Kapda Stock is deliberately narrow: protect the one screen that cannot wait, and be explicit about everything else. The counter keeps selling. The rest of the app tells you plainly that it needs the connection, rather than pretending and getting it wrong.

What actually keeps working

We would rather be precise than make a big promise. This is the whole list:

Which leads to the single habit worth teaching every member of staff, and the only one that really matters: keep POS open on the counter device all day. If the line drops, carry on billing in that window. Do not refresh it, do not navigate away to check a report, and do not close the tab to "free up memory".

The short-lived cache, and why it is not offline editing

There is a second, softer behaviour worth understanding. The app keeps recently used screens and API responses in a short-lived cache: it waits up to 5 seconds for the network before falling back to cached data up to 24 hours old. On a slow or flaky connection — the far more common failure in a busy market — this means screens still render the last data they fetched instead of hanging.

Treat that strictly as a convenience. It makes a bad connection feel usable; it is not a licence to edit stock or customers while disconnected. The only thing that is genuinely queued and replayed is a POS sale.

What an offline sale looks like at the counter

Nothing about the checkout changes, and that is the point. Your staff do not learn a different flow for bad days.

1. Ring it up as normal. Add items by scanning or tapping tiles, pick the customer or leave it blank for a walk-in, apply discounts, take the payment and press Complete sale (or F9).
2. Get a calm message instead of an error. *📴 No internet — sale saved as OFFLINE-…* with the note *It will sync automatically when you’re back online.* The cart clears.
3. Serve the next customer. The queue is already behind you; the parked sale needs nothing from you right now.

An amber bar then sits at the top of POS showing N offline sale(s) waiting to sync, listing each temporary receipt number — something like `OFFLINE-LZ8K2Q-7F3A` — with its item count, total and customer. At any point in the evening you can glance up and know exactly how much of the day is still sitting on the device rather than on the server.

Sync happens on its own

The moment the browser reports that the connection is back, the app replays the queued sales in the order they were rung up. Each one becomes a proper invoice with a normal invoice number in your usual series, and stock is deducted at that moment. You see a short confirmation — *✅ Synced N offline sale(s): INV-…* — and that is the entire ceremony.

If you would rather not wait for the browser to notice, there is a 🔄 Sync now button on the amber bar. If the line is still down you get *📴 Still offline — will retry when the connection returns*, which is also a useful diagnostic: it means the device genuinely cannot reach the server, not that the app has forgotten about your sales.

Why the number on the paper changes

This is the part that confuses people the first time, so it is worth being blunt about. An offline sale carries a temporary receipt number like `OFFLINE-LZ8K2Q-7F3A`. It becomes `INV-2026-0142` — or whatever your invoice number format produces — only when it syncs.

That is not a quirk; it is the only safe answer. Invoice numbers must be unique, gapless within a financial year and never reused — that is what a tax invoice series means, and it is what your CA reconciles against at the end of the month. If a disconnected device were allowed to allocate one, two counters billing simultaneously through an outage would hand out the same number to different customers, and the mistake would surface three months later in a GST return nobody can explain. So the server allocates the number, at the moment the sale actually lands, and the sequence stays clean whatever the line did that evening.

The practical consequence is the one nobody likes: an offline sale cannot be printed until it syncs, because until then there is no invoice to print. If the customer needs paper in their hand right now, write a note with the OFFLINE- number and tell them the proper bill will be sent on WhatsApp, or print it from Invoices once the line returns.

And when the server says no

Stock and validation checks run when a sale syncs, not when it was rung up. This is the honest trade-off at the heart of offline billing: a disconnected device cannot know what the other counter sold two minutes ago. So if the last two pieces of a design went out on another till while you were offline, that sale gets rejected when it arrives.

When that happens you see *⚠ N offline sale(s) were rejected by the server — review or discard them*, and the sale stays in the amber bar with the reason written beside it. Nothing is silently dropped, and crucially, sales that synced cleanly are never affected by one that did not.

Once each rejected sale has been dealt with, tap Discard rejected to clear those entries from the queue. Do it the same evening — a rejected sale left in the bar for a week is a sale nobody will remember the details of.

The queue lives on that device — and only that device

This is the single most important warning in the whole feature, and it is worth reading twice. Offline sales are stored in the browser on the device that rang them up, until they sync. They are not on the server, they are not in your account, and they are not visible from another counter or from your phone.

• Clearing the browser’s site data on the counter device deletes unsynced sales.
• A private or incognito window loses them when it is closed.
• Uninstalling the app before syncing loses them.
• Another device cannot see them — so you cannot sync them from the back office.

Three habits that make it bulletproof

Everything above collapses into three rules simple enough to put on a card taped to the counter:

1. Open POS in the morning and leave it open. Install Kapda Stock as an app on the counter device so there is no address bar to reload by accident.
2. Ring up offline sales on one device, not three. The queue is not shared, so spreading an outage across two counters means two queues to babysit. Pick the till device and keep the rush on it.
3. Sync before closing. Check the amber bar is empty every night before the shutter comes down.

When sync does not happen: a short troubleshooting pass

Occasionally the bar says sales are waiting and nothing moves. Work through this in order — it is almost always the second one:

• Is the device really online? Open any other website on the same device. The browser’s connection indicator can be optimistic.
• Is it a captive portal or an exhausted data pack? A phone or laptop can be firmly connected to Wi-Fi with no internet behind it — very common with shared market connections and prepaid dongles. The app will keep saying *Still offline* because, as far as it is concerned, it is.
• Press 🔄 Sync now rather than waiting for the browser to notice a flaky connection coming back.
• Did someone reload the POS tab during the outage? Reloading needs the connection, so the screen will not come back until the line does. The queued sales survive in the browser — they sync when POS opens again.

The full list, including what each rejection message means, is in Offline sync problems.

Offline and "the internet is bad today" are different problems

Shopkeepers describe both as "the net is not working", but the app sees them very differently, and knowing which one you have saves a lot of confusion.

• A clean outage — the line is down, the browser knows it, the sale is queued instantly and you carry on. This is the case everything above describes.
• A slow or flapping line — requests eventually succeed, so sales are not queued; they just take longer. The 5-second network wait and the 24-hour cache exist for exactly this, so screens keep rendering instead of hanging.
• A connected-but-dead connection — Wi-Fi is joined but there is no internet behind it, typically a captive portal or an exhausted data pack. The app treats this as offline, which is correct, but the device will keep insisting it is connected. Check with any other website before assuming the app is at fault.

The practical difference is where your patience goes. In a clean outage, nothing needs fixing until the line returns. In a flapping one, the fix is the connection, not the app — and the fastest workaround at the counter is to tether the till device to a phone for the evening.

A one-page counter drill

Software that only works when the owner is standing there is not much use. Print this, tape it beside the till, and walk the staff through it once. It takes five minutes and it is the whole feature, in language that works at 7 PM on a Saturday:

1. Every morning, open Kapda Stock on the counter device and go to POS. Leave it open all day.
2. If billing suddenly says *📴 No internet — sale saved as OFFLINE-…*, carry on. Nothing is lost. Do not close or refresh the window.
3. Tell the customer their bill will come on WhatsApp shortly — an offline sale cannot be printed yet.
4. Keep billing on this one device until the line is back.
5. When the amber bar disappears or says *✅ Synced*, the sales are on the server. Print or send anything the customer is waiting for.
6. If a sale turns red with a reason next to it, leave it for the owner. Do not discard it.
7. Before closing, check the amber bar is gone. If it is not, press 🔄 Sync now.

What this changes about running a shop

The value of offline billing is not really the evening the line goes down. It is what stops happening around it.

• No parallel paper system. The duplicate book does not have to exist, so there is no second source of truth to reconcile.
• Stock stays honest. Every offline sale deducts stock on sync, so the counts that drive low stock alerts and reorder suggestions stay real.
• The khata stays correct. A credit sale rung up offline lands on the customer’s ledger when it syncs, so the udhaar balance is not a day behind.
• Nobody works Sunday morning. The hour that used to go on retyping yesterday simply disappears.

“The line in our market goes twice a week. We stopped noticing. The bills are simply there in the morning, with the stock already adjusted.”

If your connection is genuinely terrible

There is a point past which no amount of offline queueing is the right answer. If your shop loses power and connectivity for hours at a stretch, or you are in a location where a fixed line simply is not available, the offline queue is a patch over a structural problem.

Two things are worth considering. The cheaper one is a mobile data fallback on the counter device — a modest prepaid pack on the phone that runs POS covers the outages that matter, because billing is a very light workload. The larger one is the On-Premise edition, where the software runs on hardware inside your shop and does not depend on a connection to reach the server at all. It is sold as a one-time licence through our sales team rather than as a subscription; most shops are better served by the Cloud edition, but if your line is the bottleneck, it is the honest answer. Talk to us and we will tell you which one actually fits.

Reliability as a feature nobody sees

None of this is a feature customers ever notice, and that is exactly the point. Nobody at your counter will ever say "I appreciated how your billing software handled the outage." They will simply have been served, given a proper bill, and not made to wait while somebody hunted for a pen.

The shop keeps selling, the khata stays correct, the stock figures stay real, and nobody spends Sunday morning typing yesterday back into the computer. If you are still setting up, the order we recommend for the first month — including where offline habits fit — is in Your first 30 days on Kapda Stock. Or see the rest of what the app does on the features page, and start a workspace when you are ready.