Grocery and Mart POS Software in Nepal

A mart’s problems are volume problems. Thousands of SKUs, several counters, a queue at peak hours, supplier credit running in both directions, and stock that is wrong in ways nobody can trace.

The software requirements follow from that: speed at the counter, accuracy in stock, and control over purchasing.

Speed is a feature

A retail counter at peak has a queue. Every second per item is multiplied by hundreds of items an hour, and a till that hesitates creates a visible line.

The things that actually determine counter speed:

• Scanning must be instant. Item lookup happens against the local database. If it waits on a server, the counter feels slow no matter how fast the network usually is.
• Keyboard-first operation. Experienced counter staff do not use a mouse. Every common action needs a key.
• Loose items handled sensibly. Vegetables, pulses and grains sold by weight need scale integration or a fast quantity entry, not a dialog box.
• Non-barcoded items findable. A short code or a quick-select grid for the items that never have a barcode.
• Suspend and resume. A customer who forgot something should not block the queue.

Stock accuracy is a discipline, not a feature

Every mart’s stock drifts from reality. The system’s job is to make drift visible and attributable rather than to pretend it does not happen.

That requires every movement to be a transaction: purchase receipt, sale, return to supplier, customer return, damage, expiry, internal consumption, and physical count adjustment. If any of those routinely happens without a corresponding entry — and damage and internal consumption almost always do — the count will never reconcile and staff will stop trusting the number.

Cycle counting beats annual stocktakes. Counting a section a week, with variance recorded and investigated, keeps the number honest and finds problems while they are small enough to explain.

Purchasing and supplier credit

Most marts in Nepal buy on credit from distributors, with terms that vary by supplier and sometimes by product line. Getting this right in the system matters more than most owners expect, because it is where working capital lives.

What is needed:

• Purchase entry against the supplier’s invoice, item by item, with the actual purchase rate
• Supplier ledger with outstanding balance and ageing
• Payment recorded against specific invoices, not as a lump sum, so both sides can reconcile
• Purchase rate history per item, because distributor prices move and the margin quietly changes with them
• Returns to supplier as a proper transaction that reduces the payable

Purchase rate history is the underrated one. Without it, an item whose cost rose 15% keeps selling at the old margin until someone happens to notice.

Margin per item, and the MRP problem

Many packaged goods in Nepal carry a printed maximum retail price, so the selling price is largely fixed and all of the margin is determined at purchase.

That inverts the usual retail logic. Instead of managing price, you are managing purchase cost and mix. The reports that matter are margin by item and by category, and contribution by category rather than by revenue. High-turnover, low-margin categories can look like the core of the business by sales value while contributing very little.

Expiry and near-expiry

Any mart selling packaged food, dairy or personal care carries expiry risk. Batch-level tracking is heavy for a mart with thousands of SKUs, so a practical middle path works better: expiry tracked for the categories where it matters, with a near-expiry report that lists what needs discounting or returning while the supplier will still accept it.

The return window is the part that costs money. Distributors accept returns up to a point; past it, the loss is yours. A report that surfaces items entering that window is worth real money each month.

Multiple counters, one stock

Two or three counters selling from the same stock has to work without either counter waiting on the other, and without stock diverging.

Practically that means each counter bills locally and syncs continuously, with stock reconciled centrally. During an outage counters run independently and reconcile afterwards — including the case where the same last unit sold twice, which is a real event to be recorded rather than an error to be blocked. This is covered in more detail in offline POS software in Nepal.

Customer credit and khata

Many neighbourhood marts run informal credit for regular customers. If the system does not support it, it happens in a notebook and never appears in the books.

Supporting it properly means: a customer record, a running balance, bills marked as credit rather than paid, collection recorded against specific bills, and an outstanding report by customer with ageing. It turns a personal arrangement held in someone’s memory into a business asset that survives a change of staff.

Reports that get used

Most POS systems ship dozens of reports and owners use four. The ones worth checking daily or weekly:

• Sales by day and by hour, for staffing
• Top and bottom movers by quantity and by contribution
• Stock value on hand, and how it has moved
• Items below reorder level
• Near-expiry and return-window items
• Supplier outstanding with ageing
• Cash variance at counter close

We build accounting and inventory software for retail businesses in Nepal, with barcode billing, supplier credit, expiry control and offline operation. If your stock report and your shelves disagree, talk to us.