Custom Web Applications for Retail and Wholesale Businesses in Nepal

Retail and wholesale businesses in Nepal need different software because they sell differently: a retail counter needs fast barcode billing for walk-in customers, while a wholesaler needs dealer-specific prices, credit limits and a reliable record of every rupee of udharo owed by shops down the line. Tarka Raj Jaishi, a full-stack web application developer in Lamki, Kailali, builds retail and wholesale management software that handles both sides, including the many businesses in the region that do both from the same godown.

A kirana shop in Lamki bazaar and the wholesaler in Dhangadhi that supplies it may stock the same biscuits, oil and soap, but their days look nothing alike. The kirana owner serves a stream of customers buying two or three items each, mostly paying cash or by QR, and the queue at the counter is the pressure point. The wholesaler handles fewer, larger orders from shopkeepers who often pay later, and the pressure point is knowing who owes what and whether to send more goods to a shop that has not paid.

Software built for one usually frustrates the other. A retail POS has no idea that Ram Kirana gets a different price from Sita Store. A wholesale ledger is too slow for a counter with six people waiting. The table below summarises the differences that shape the design.

For VAT invoices or PAN bills on either side, check current IRD requirements with your auditor and the invoice format is built to match them.

Every trader in Nepal knows the udharo khata. It is also where most money quietly disappears: an entry written on the wrong page, a payment received by the owner's son and never noted, a shop that "paid half last Dashain" with nobody sure which half. Credit tracking is the heart of a wholesale system and, in many retail shops, the feature owners ask about first.

• A ledger per customer showing every invoice, every payment and the running balance, in date order.
• Credit limits per customer, with a warning (or a block requiring the owner's approval) when a new order would exceed it.
• Due dates and ageing: how much is current, how much is 30, 60 or 90 days overdue.
• Payment allocation against specific invoices, so partial payments are clear.
• Statements that can be printed or sent on WhatsApp, so the shopkeeper sees the same numbers you do.
• SMS reminders for overdue balances, sent politely and only when the owner decides.
• Who recorded what: every payment entry shows which staff member received it.

That last point is often the one that changes behaviour. When a collection agent's name sits next to every payment, money stops getting lost between the shop and the counter.

1. Barcode billing with a USB scanner, plus quick search by name for loose items without barcodes.
2. Weighed items such as rice, dal and sugar sold by the kilo, with prices that update when the wholesale rate changes.
3. Multiple payment methods on one bill: part cash, part QR.
4. Day-end closing that compares expected cash with counted cash and records the difference.
5. Low-stock alerts so the owner knows what to order on the next trip to the wholesaler.

1. Dealer price lists and quantity slabs applied automatically when the dealer is selected.
2. Order booking by a salesperson visiting shops, with a phone-friendly order form.
3. Credit check before dispatch, so goods are not loaded onto the tempo for a shop already over its limit.
4. Delivery challans and route-wise dispatch lists for deliveries to Tikapur, Ghodaghodi or Attariya.
5. Bulk returns of damaged or expired goods adjusted against the dealer's balance.

Many shops in Kailali run a retail counter at the front and supply smaller shops from the godown behind. In that case, both sides should share one stock record. A carton sold wholesale and a packet sold at the counter both reduce the same stock, with unit conversion handled by the system. Keeping two separate systems is the most common reason stock figures never match.

If stock across several locations is your main concern, read inventory management web applications in Nepal, and for invoices and books, see billing and accounting web applications.

• Not entering opening balances carefully. If the first day's udharo figures are wrong, nobody will trust the system after.
• Letting everyone edit prices. Price changes should be restricted to the owner or manager.
• Running paper and software side by side for months. A short overlap is fine; a long one doubles the work and the errors.
• Ignoring the counter's speed. If billing is slower than the old method, staff will find ways around it.

Yes. The same product and stock records are used, and the sale screen changes depending on whether it is a counter sale or a dealer order. Prices, payment terms and documents follow the type of sale.

A statement can be sent by WhatsApp or SMS, and dealers can be given a simple login to view their own ledger. Many owners prefer to start with sent statements and add logins later.

Most USB barcode scanners act like a keyboard and work with a web application directly. Receipt printers usually work through the browser's print function; the exact model should be tested early in the project.

Yes. A phone-friendly order form lets a salesperson select the shop, add items at that shop's prices and submit the order to the godown, where it is checked against the credit limit before dispatch.

It depends on whether you need retail, wholesale or both, how many users and locations there are, and how much existing data must be imported. Starting with one side and adding the other later is a common approach.

If your counter is slow or your udharo khata no longer adds up, get in touch to talk through how your shop and godown actually work.

• Phone: 9865760285 / 9812636744
• WhatsApp: +977 9865760285
• Website: tarkarajjaishi.com.np
• Facebook: facebook.com/TarkarajJaishi