HR Software in Nepal: What a Growing Company Actually Needs

Most businesses in Nepal run HR out of a folder of documents and a shared spreadsheet until roughly thirty or forty staff, at which point three things break at once: nobody can say who is on leave, payroll takes a week, and someone finds the salary sheet.

The last one is usually what forces the decision.

Start with the employee record

Everything else is derived from it, so it is worth getting right. A usable employee record holds:

• Personal details, contact, emergency contact
• Employment: join date, designation, department, reporting manager, employment type, location
• Compensation: current salary structure, effective from a date, with history
• Statutory identifiers: PAN, and provident fund or social security registration where applicable
• Bank details for salary transfer
• Documents: contract, citizenship or ID copy, academic certificates, appointment and confirmation letters

The two fields people skip and later regret are effective dates on compensation and reporting manager. Without effective-dated compensation you cannot reconstruct what someone was paid in a past month, which makes any payroll query unanswerable. Without a reporting line the system cannot route a single approval.

Confidentiality is the reason to move off spreadsheets

A spreadsheet has one permission level: whoever has the file has everything. HR data does not work that way. A line manager should approve their team’s leave without seeing their salaries. Finance should see payroll totals without seeing performance notes. An employee should see their own record and nobody else’s.

That means role-based access at field level, not just screen level, and it is the single strongest argument for a real system over a well-organised set of files.

Leave has more rules than anyone expects

Leave looks simple and is not. A working leave module needs:

• Multiple leave types with different rules: annual, sick, casual, maternity and paternity, bereavement, unpaid
• Accrual rules — monthly accrual, annual grant, or accrual from join date with pro-rating for mid-year joiners
• Carry-forward and lapse, with caps
• Encashment, where the policy allows it, feeding into payroll
• Half-days, because they are extremely common and a system that only understands full days will be worked around immediately
• Approval routing to the reporting manager, with delegation when that manager is themselves on leave
• A holiday calendar that reflects the Nepali festival calendar and any location-specific holidays

The balance shown to an employee has to be correct and live. If they have to ask HR how much leave they have left, the system is not doing its job.

Bikram Sambat and Gregorian

A practical detail with real consequences: Nepali businesses work in both calendars. The fiscal year runs on Bikram Sambat, statutory filings follow it, and leave policies are typically defined against it — while contracts, international clients and most software default to Gregorian.

The system should store dates unambiguously and display in either, with BS used where the business and the regulator use it: fiscal year boundaries, leave year, payroll periods, statutory reports. Converting by hand at the boundary is where errors get introduced.

Attendance is where HR meets reality

Attendance data is the input to payroll, and it is usually the messiest thing in the company. The realistic sources are a biometric device, a mobile app with location capture for field staff, or a manual register for the sites where neither works.

Whichever it is, the system needs to:

• Import or capture raw punches, and keep them
• Apply shift rules to derive worked hours, late arrivals and early departures
• Reconcile against approved leave, so an absence with approved leave is not flagged
• Surface exceptions — missing punches, impossible sequences, unapproved absences — for someone to resolve
• Lock the period once payroll runs

The important discipline is keeping raw punches separate from the derived result. When an employee disputes a deduction, you need to be able to show the original data, not a computed summary that someone may have adjusted.

Onboarding and exit

Both are checklists, and both are where things get missed in a growing company.

Onboarding: documents collected, bank details captured, statutory registrations done, accounts and access created, assets issued, probation end date set. Exit: resignation and notice recorded, last working day, handover, assets returned, access revoked, final settlement computed including leave encashment and any recoveries, and the experience letter issued.

A system that tracks these as workflows rather than as someone’s memory prevents the two expensive failures: an ex-employee who still has system access a month later, and a final settlement paid without recovering an outstanding advance.

Let employees serve themselves

The highest-return feature in HR software is self-service. Employees apply for leave, check balances, download payslips, view their own record and request corrections; managers approve. HR stops being a queue for routine requests and starts doing work that needs judgment.

It also improves data quality — people correct their own contact details far more reliably than HR does.

Where it connects

HR data that stops at the HR department is half-useful. Attendance and leave feed payroll. Headcount and cost by department feed the accounts. Employment status gates system access.

That is the argument for HR living inside the same system as finance and operations rather than beside it: the data is only interesting where it meets something else.

We build accounting, HR and inventory software for businesses in Nepal, including employee records, leave, attendance and payroll on one platform. If your HR runs on a spreadsheet nobody is supposed to open, talk to us.