Designing software for Nepali businesses

Designing software for Nepali businesses means treating local rules as correctness, not polish. Amounts are in NPR and are often grouped in lakhs, dates are in Bikram Sambat, the fiscal year starts on Shrawan 1, a PAN has exactly nine digits, VAT at 13% is often already inside the price, Nepal's clock is UTC+05:45, and a shop's day mixes cash, credit tabs and QR payments. Each of these changes what a form accepts, what it fills in by default and what a summary shows, so getting one wrong produces a screen that looks fine and records the wrong thing.

I'm the only UI/UX designer on Tigg, an accounting and POS product for Nepali businesses made by BIC Technology. This post collects what I've learned about UX design for Nepal from that work, with links to the cases where each lesson comes from.

What changes when you design for Nepal

The short version is in this table. The rest of the post explains the rows that taught me the most.

Nepal reality	What it changes in the design	Where I met it
NPR is the base currency	Every rate is "to NPR"; NPR is listed first; every amount carries its currency	Currency case
Lakh grouping (1,66,750)	Number formatting can't assume groups of three	Currency case
Bikram Sambat calendar	Date pickers, defaults and conversion to AD	Admin and ERP case
Fiscal year from Shrawan 1 (mid-July)	Default accounting start dates, year-end numbering	Admin and ERP case
Nine-digit PAN	Exact-length validation	Admin and ERP case
13% VAT, often inclusive	Prices that must not be taxed twice	Batch and serial case
Notes from Rs 1 to Rs 1,000, plus Rs 25 and Rs 250	An editable denomination list	Cash sessions case
Credit tabs settled in cash	Its own row in the cash drawer	Cash sessions case
Cash alongside QR payments	Count only cash in the drawer; show the QR to the customer	POS operations case
UTC+05:45	Timestamps that are easy to get wrong by 15 minutes	Cash sessions case
Local words such as "Godown"	Field matching and labels	Bulk import case

Money: NPR, lakhs and the rate to NPR

Most Nepali businesses keep their books only in rupees, so NPR is the base. When multi-currency support arrived, I set three rules for the money forms: an amount always carries its currency; the bank account decides the currency of a payment; and leaving NPR clears the exchange rate.

The last rule exists because of a Nepal-shaped bug. NPR's rate to NPR is 1, so a form that opens in NPR shows 1. Switch to USD and the 1 used to stay, so a USD 1,250 payment could be saved as NPR 1,250 instead of roughly NPR 1,66,750. A default that is true in one context became a wrong number in another. The fix was to empty the rate and make it required whenever the form leaves NPR.

Number formatting is part of the same problem. Nepali readers group large amounts in lakhs and crores (1,66,750), not only in thousands (166,750). A product should pick one format and use it everywhere, with the currency beside the number.

Dates: designing a Bikram Sambat date picker

Nepali businesses work in Bikram Sambat (BS), alongside the Gregorian calendar (AD). The fiscal year starts on Shrawan 1, which falls in mid-July. That shapes three things in a date picker.

Show the calendar people use

Where the business thinks in BS, the picker should show and accept BS dates, with AD conversion behind it. Conversion errors are not cosmetic: a wrong date moves a document into the wrong fiscal year.

Never refill a cleared field

In Tigg's company-creation flow, the accounting start date uses a BS date picker. If you cleared it and pressed Enter or Tab, it used to fill a default date back in. That is worse than an error, because it looks like your own input. I fixed it so a cleared field closes and stays empty, and the "required" message can appear. I wrote about the general rule in empty is not zero.

Work out defaults from the calendar

The default accounting start date is mid-July because of Shrawan 1. Today that default is a fixed date that someone has to update each year. Working it out from today's BS date is on my list. It's a small example of a wider rule: a local default should come from the local calendar, not from a constant.

Tax: nine-digit PAN and inclusive VAT

Nepal's Inland Revenue Department (IRD) issues a nine-digit PAN. Tigg's company form accepted 9 to 12 digits, and in November 2025 I changed it to exactly nine. A wrong tax number is easy to type and hard to notice later, so exact validation is kinder than a loose one.

VAT is 13%, and many Tigg businesses price with VAT included. That matters wherever a price comes from somewhere else. In batch tracking, each batch carries its own selling price, and that price has to reach the order line as the final price without VAT being added a second time. The configuration redesign I'm working on follows the same logic: IRD sync appears only for organisations that have IRD enabled and verified, so people don't see controls that don't apply to them.

Cash, credit and QR at the counter

A Nepali shop's drawer is not just sales. In designing cash sessions I wrote the drawer down as a ledger first, and three local patterns showed up:

• Credit tabs. Customers often run a tab and pay later. That cash is real but isn't a new sale, so it has its own row.
• Cash beside QR. Shops take QR and wallet payments next to cash. The drawer card counts only the cash share; other methods stay in the transaction summary.
• Local notes. The default count goes from Rs 1,000 down to Rs 1, in the order a cashier counts. Rs 25 and Rs 250 are less common, so they aren't in the default, but a shop can add them.

QR payments have their own local shape. In many shops a digital payment starts with a printed QR on a stand, and the customer types the amount. A dynamic QR carries the amount for one bill. I designed the screens for a small customer-facing display, NiziPOS by Yarsa Tech, so the customer sees the amount, the QR and the result without typing anything.

Time: UTC+05:45

Nepal is five hours and forty-five minutes ahead of UTC. That 45 minutes is a common source of bugs. In cash sessions, timestamps came back with the offset written in more than one form, and the history has to read both, because a quarter-hour slip is enough to make a sequence of corrections look out of order. Session times also moved to a 24-hour clock.

Shared counters and local words

Two smaller lessons:

• Devices are shared; records shouldn't be. A counter tablet is used by several people across shifts. So a cash session belongs to one person, and only that person or an admin can change its drawer. Others can see it.
• Use the words people use. Businesses in Nepal often say "Godown" for a warehouse. An importer that only matches "Warehouse" fails on a perfectly normal sheet, so the bulk import's column matching treats them as the same field.

A checklist for UX design in Nepal

• Are amounts shown with their currency, in one consistent grouping?
• Does any default (a rate, a date, a tax setting) stop being true when the context changes?
• Do date fields use BS where the business does, and stay empty when cleared?
• Do defaults follow the fiscal year from Shrawan 1?
• Is PAN validated as exactly nine digits?
• Are VAT-inclusive prices protected from being taxed twice?
• Does the cash flow separate cash from QR and credit collection?
• Can shops edit the denomination list?
• Are timestamps correct at +05:45?
• Do labels and matching accept local words?

Where this knowledge comes from

I should be honest about the method. I learn about user problems mostly through the CEO, QA, support and sales. I haven't run field studies in shops for these features, and none of the outcomes above has been measured. Most of these lessons came from bugs and edge cases, so I now run local rules as a checklist before design review rather than fixing them later. For how that review fits into the team's process, see being the only designer on a product team.