Your internet is down and there are six people at the counter

It is twenty to eight on a Saturday. Six people at the counter, two of them visibly in a hurry, one holding a child. The light on the router has gone amber and your billing screen is showing a spinner.

This is the moment that should decide which software you buy, and it is almost never the moment anybody evaluates. Shortlists get built on feature lists — barcode scanning, GST reports, loyalty points — and every product on your shortlist has all of those. The difference between them shows up on a Saturday evening, once, and then you live with it.

Cloud billing is the right architecture for a shop. It also has one specific failure mode, and how a product handles that failure mode tells you more about how it was built than any brochure will.

The twenty minutes that decide which software you should buy

Add up your outages honestly over a month. A fibre cut on the main road. The building power going and taking the router with it while your counter runs on an inverter. Mobile data crawling at exactly the hour the whole neighbourhood is home and streaming. It might come to twenty minutes.

Twenty minutes a month sounds like nothing, and it would be, except those are rarely random minutes. They cluster in the evenings and on weekends, because the causes are correlated with everybody being home — which is also when your shop is full. So the cost is not twenty minutes of sales. It is the queue that leaves, the customer who watches you write a bill on a notepad and quietly downgrades their opinion of your shop, and the two hours somebody spends that night keying the notepad back in, badly, from memory.

Which means there is one question to ask in every demo, in roughly these words: what happens on this screen when the internet stops in the middle of a bill? Then pull the cable and watch.

Offline-capable, cloud-only, fully local: three different bets

There are three honest architectures on the market, and each is a defensible position rather than a mistake.

• Fully local. Everything lives on a PC in your shop. It never depends on a connection, and it depends entirely on that machine, its hard disk, and whoever configured it three years ago.
• Cloud-only. A browser talking to a server. Your data is off the premises, reachable from anywhere, updated without anybody visiting — and the counter stops completely when the link does.
• Offline-capable cloud. Primarily a cloud system, but the counter keeps billing when the connection drops, queues what it did locally, and syncs when the line comes back.

The third is not automatically the best. It is the most complicated of the three, and complication has to earn its place. It is the right bet specifically when your counter cannot afford to stop and you also want your data somewhere other than a box under the billing table.

What offline mode has to mean to be real

Every vendor will tell you their product works offline. The range of things that sentence can mean is enormous, so make them be specific. The genuine bar looks like this:

• Ring up a full sale from a barcode scan, using the catalogue and prices already sitting on the machine
• See stock and batch details for what you are selling, as of the last sync
• Take payment in every mode you actually accept, including a split between cash and something else
• Print a bill the customer can carry out of the shop
• Hold the sale locally so it survives the browser being closed, the tab crashing, or the machine being restarted
• Sync by itself when the connection returns, with nobody having to remember to press anything

There are things that reasonably cannot work offline, and a vendor being honest about them is a good sign rather than a bad one — a UPI collection needs the bank, a purchase order needs to reach the distributor, a report aggregating three branches needs all three. Nobody needs any of that at twenty to eight on Saturday.

The two lines to test hardest are the last two. Plenty of products keep an in-progress sale alive in a browser tab and lose it entirely when the machine restarts. That is not offline billing. That is a delay before the same loss, and it usually shows up during a power cut, which is exactly when the internet went too.

Invoice numbering across an outage: the part that must not break

This is the technically difficult part, and it is the honest reason a lot of cloud products simply refuse to bill offline at all.

Your GST invoice series has to run without gaps and without duplicates. If a counter mints its own numbers while it is offline, and the server is also minting numbers, you can end up with two bills carrying the same number, or a hole where a queued bill was assumed and never arrived. Both are worse problems than the outage was.

The clean design is to separate the sale from its number. The counter records the sale offline and queues it; the final invoice number is assigned at sync by the one component that can see everything — so the series stays continuous and unique across the whole outage, however many bills were rung on however many terminals. The customer walks out with a slip that ties back to it.

So ask precisely this, and listen for mechanism rather than reassurance: while offline, where does the invoice number come from, and what prevents two bills getting the same one?

Any shop can keep selling through an outage with a notepad. The question is whether your numbering survives it.

Sync conflicts, and who wins

Two counters, both offline, both selling the last four units of the same item. When they reconnect, your shop has sold eight units of something it had four of. No clever algorithm makes that not a problem, and any vendor claiming otherwise is describing a single-counter product without saying so.

The honest handling looks like this:

• Sales are additive and all of them get accepted — you did sell them, the customers did leave with goods, and it is the stock position that needs correcting, not the sale that needs deleting
• The resulting negative stock has to be visible rather than quietly clamped to zero, because it is telling you something true about your shelf
• Master data — prices, new products, reorder levels — is edited in one place only, so an offline terminal is never authoring your catalogue
• Anything that must never be duplicated is minted centrally at sync, not locally in hope

If you run one counter, none of this will ever affect you and you can stop worrying about it. If you run two, or plan to, it is the difference between a stock report you trust and one you have learned to ignore.

Local billing software: what you give up

Let me be fair here, because desktop software is the reason a whole generation of Indian shops got computerised at all, and a lot of it is genuinely deep. Pharmacy, distribution, jewellery — the mature local products carry trade-specific detail that plenty of cloud entrants have not caught up with. If one of them fits your trade, that is a real advantage and not nostalgia.

What you are giving up is worth naming plainly rather than being talked out of:

• The data lives on one machine. Backups become somebody's weekly discipline, and that somebody is usually the owner's nephew.
• You cannot see the shop from anywhere else. For an owner who stands at the counter all day, that genuinely does not matter. For an owner with two shops, or one who wants to check yesterday from home, it matters every day.
• Updates arrive when a person comes to install them, and tax changes do not schedule themselves around service visits.
• The exit is hard. The data format belongs to the vendor, and moving to anything else ranges from tedious to impractical.
• The two risks nobody plans for: the hard disk, and the developer who stops answering the phone.

None of that makes local software the wrong answer. One counter, no branches, an owner who is always present and a backup that actually happens — a good desktop product will serve that shop for years. The mistake is not choosing it. The mistake is choosing it without knowing you did.

Hardware questions: scanner, printer, drawer and the old PC

The unglamorous half of the decision, and the half that determines whether anybody at your counter will actually use the thing:

• Barcode scanner — nearly all USB scanners present themselves as a keyboard, so any software that cannot accept that input is doing something unusual and you should ask why
• Thermal printer — 58mm or 80mm; confirm it prints to your printer, not just to a PDF on a laptop
• Cash drawer — usually opens off the printer's kick port; confirm rather than assume
• Weighing scale and label printer, if you are in groceries or loose goods
• The counter machine itself: often five years old, 4GB of RAM, and an antivirus consuming most of it
• A phone as the fallback terminal, which is an outage plan all by itself

That fifth line is the honest test. Demos run beautifully on a salesperson's new laptop. Ask to load your own catalogue onto your own billing machine and scan twenty real items from your shelf. If it is smooth there, everything else is detail.

A buying checklist for a single-counter shop

Take this list to the demo and ask them to run it, on your data if they will let you:

• Pull the internet mid-bill. Finish the sale, print it, restart the machine, reconnect. Did the bill survive, and did it get a proper gap-free number?
• Scan a real product off your shelf with your own scanner. Does it pull the correct batch, expiry and printed MRP?
• Ring a split tender — part cash, part UPI — on one bill
• Do a return against a bill from last week and confirm the stock went back into the batch it came from
• Receive a purchase with two batches at two different costs and check that stock and supplier payable both moved
• Pull last month's GST report and show it to your accountant before you sign anything
• If you are a pharmacy: record a prescription and dispense a schedule-H item against it, with batch and expiry on the bill
• Ask what happens to your data if you stop paying, and get the export format in writing

Most shops buy billing software on a feature list and meet its architecture much later, at the worst available moment. Spend twenty minutes at the demo mirroring the twenty minutes you are going to lose this year. It is the cheapest due diligence a shopkeeper can do, and almost nobody does it.