A retail counter is judged on one number: how long the queue is. Everything a billing system does well is invisible, and everything it does badly is visible to every customer standing in line. That is why the features that sell software in a demo are rarely the ones that matter at 7pm on a Saturday.
This guide is written around the four things that actually decide whether retail software works: billing speed, stock that stays true, GST that files without a scramble, and what happens when the internet drops. Nothing here is specific to us - take it to any vendor.
Billing speed is a keyboard question, not a feature question
The single biggest difference between fast and slow billing software is whether the person at the counter has to touch the mouse. A trained cashier billing 40 items should never leave the keyboard: scan, quantity, scan, quantity, tender, print. If the software forces a mouse click to add a discount or pick a payment mode, you have added two seconds per bill, and two seconds per bill is a queue.
Ask to bill twenty mixed items in the demo yourself rather than watching the salesperson do it. Loose goods sold by weight, an item with no barcode, a price override, a part-cash part-UPI payment, and a return - if all five are smooth without the mouse, the software was designed by somebody who has stood at a counter.
- Scan to print without the mouse, including quantity and discount entry
- Fast search by item code, short name or first letters for unbarcoded goods
- Weight-based and loose item billing without a separate screen
- Split payment across cash, card, UPI and credit in one bill
- Hold and recall a bill when a customer goes back for one more thing
Stock figures should be derived, never incremented
Ask how the stock quantity is calculated. There are two answers. The weak one is that a number is stored against the item and adjusted up on purchase and down on sale. The strong one is that the quantity is derived from the movement ledger - every purchase, sale, return, transfer and adjustment - so the figure can always be traced back to the entries that produced it.
The difference only shows up after a year. In an incrementing system, one missed decrement during a crash or a badly cancelled bill leaves the count permanently wrong, and nobody can tell you when it drifted. In a derived system the same crash costs you one entry that can be found and corrected. If a vendor cannot explain which model they use, they use the weak one.
- Every movement recorded with date, type, quantity and who did it
- Physical stock count that posts an adjustment entry, not a silent overwrite
- Batch and expiry tracking if you sell anything dated
- Purchase entry that updates cost and margin, not just quantity
GST should be a report, not a project
Filing should be a matter of opening a report for the period and exporting it. If your staff currently spend the first week of every month reconciling sales registers by hand, that is a software failure, not an accounting one. The system already holds every invoice with its HSN code, tax rate and party GSTIN; producing the return from that is arithmetic.
Watch for the specific gaps. B2B invoices need the buyer GSTIN captured at billing time, not added later. Credit notes must carry the original invoice reference. Rate changes need to apply from a date rather than retrospectively rewriting old bills, or last year's filed figures will stop matching your own reports.
- GSTIN captured on the bill for B2B sales, with validation
- HSN summary and rate-wise breakup available as an export
- Credit notes linked to the original invoice
- Tax rate changes effective from a date, leaving history intact
Ask what happens when the internet dies
Cloud software is the right choice for almost every shop, but only if it keeps billing when the connection drops. The question to ask is not "is it offline capable" - everyone says yes - but "show me". Pull the network cable during the demo and bill three items. Then reconnect and show me those three bills in the reports.
The honest answers vary and all of them can be acceptable. Some systems queue bills locally and sync on reconnect. Some run a local server with cloud backup. What is not acceptable is a blank screen and a queue of customers, which is what you get from a system that was only ever tested on an office broadband connection.
- Billing continues with the network down, and syncs cleanly on return
- Bill numbers do not collide or reorder after a sync
- A printed bill is never lost because the sync failed
The shortlist checklist
Take this to any vendor, ours included. If a question cannot be answered with a straight demonstration rather than a promise, treat it as unanswered.
- Bill twenty mixed items yourself, on the keyboard, without help.
- Ask whether stock quantity is stored or derived from movements.
- Disconnect the network mid-demo and keep billing.
- Export a GST return for a sample month and read it.
- Add a second counter and check both bill at once without number clashes.
- Ask who can delete a bill, and where that deletion is recorded.
- Get the migration answer in writing: who moves your item list and opening stock.
- Confirm the monthly price includes support, updates and the mobile app.
Retail software built around the counter
Our retail solution covers fast GST billing, derived stock, customer khata and day close - with the offline behaviour and audit trail this guide argues for.
