Choosing an HRMS in Nepal: A Buyer's Checklist

Most HR software demos look the same. Employee directory, leave requests, a dashboard with a chart. The differences that decide whether a system survives its first year in Nepal are not in the demo, and they are not usually on the feature list either.

This is a checklist of what to test before committing, written for companies operating under Nepali statutory requirements.

On numbers: this article contains no contribution percentages, tax slabs, or deadlines. Those change, and a stale figure is worse than none. Confirm current rules with the Inland Revenue Department, the Social Security Fund, or your auditor.

1. Payroll built for here, not localised afterwards

The single biggest divider. An international HRMS will handle employee records and leave perfectly well, then treat statutory deductions as configurable line items you are expected to define yourself. That works until a rule changes and you discover the logic lives in a formula somebody set up two years ago.

Ask the vendor directly:

• Are PF, CIT, SSF, and eTDS handled as first-class concepts, or as generic deduction fields I configure?
• When statutory rules change, do you update the system, or do I?
• Can you produce reporting in the format the filing actually requires, or an export I then reshape?

The third question separates most products. Producing a payslip is easy. Producing what a filing needs, per employee, without manual assembly, is the part that saves real time.

2. Your SSF position, and how the system reflects it

How your retirement contributions are structured depends on which arrangement your company is enrolled in, and that determines the shape of the rest of payroll. Confirm your own position first, then check the system handles it without workarounds. Do not copy another company's configuration; their enrolment may not match yours.

3. Attendance that arrives without being typed

If your biometric device exports a file that someone reformats and uploads each month, you have automated nothing. That step is where overtime and leave errors enter payroll, and it is the reason two records drift apart.

Test with your actual device:

• Does it integrate directly, or only through manual file upload?
• How are shifts, night shifts, and overtime rules configured?
• What happens on a missed punch, and who resolves it?
• Does approved leave automatically reconcile against attendance?

Bring a real month of messy data to the demo. Clean sample data proves nothing.

4. Multi-company and multi-branch, if that is you

Many organisations run more than one legal entity, or several branches with different working patterns. Retrofitting that later is painful. Check whether entities are genuinely separate for payroll and reporting, whether an employee can transfer between them with history intact, and whether permissions can be scoped so a branch manager sees only their branch.

5. Employee self-service that actually deflects questions

A large share of HR admin is answering the same questions: what is my leave balance, where is last month's payslip, how much notice do I need. If employees can answer those themselves, the HR team gets its time back.

Check that payslips are self-serve for past months, leave balances are visible without asking, requests route to the right approver automatically, and it is usable on a phone. If self-service exists but nobody can find anything in it, it will not deflect anything.

6. The exit path

Ask how you get your data out before you put any in. Employee records, payroll history, and leave balances should be exportable in a usable format without a support ticket or a fee. A vendor that cannot answer this clearly is telling you something.

7. Support in your timezone, on your calendar

Payroll is deadline-driven. Support that responds within a business day from another continent is not support during a filing week. Check working hours, whether the team understands Nepali statutory requirements rather than just the software, and what the escalation path is when something is wrong on pay day.

8. The reports you will actually need

Dashboards demo well and get used rarely. The reports that matter are the ones somebody has to produce on a deadline, and those are worth testing specifically rather than assuming.

Ask to see, with real-shaped data:

• A per-employee statutory breakdown for a given month.
• A month-on-month payroll comparison that shows what changed and why.
• Leave liability across the organisation at a point in time.
• Attendance exceptions for a period: missed punches, unapproved absence, overtime above a threshold.
• Headcount movement, joiners and leavers, over a date range.

If any of these requires exporting to a spreadsheet and reshaping it, that work does not disappear when you buy the system. It just moves.

9. Permissions and the audit trail

HR data is the most sensitive data most companies hold, and payroll is the most disputed. Two things to check that rarely appear in a demo.

Permissions granularity. Can a line manager approve leave without seeing salaries? Can a branch administrator see only their branch? Can finance see payroll without seeing performance reviews? If roles are coarse, people end up with more access than they should have because the alternative is that they cannot do their job.

The audit trail. When a payroll figure is questioned six months later, can the system show what it was, when it changed, and who changed it? Without that, every dispute becomes a matter of memory.

Questions to ask a reference customer

Ask the vendor for a reference at roughly your size and in your sector, then ask them things the vendor would not volunteer:

• How long did implementation actually take, against what you were told?
• What did you have to change about your process to fit the system?
• What broke in your first payroll run?
• When a statutory rule last changed, how did you find out and what did you have to do?
• What do you still do in a spreadsheet?

The last question is the most revealing. Every implementation leaves something outside the system. Knowing what that is for a company like yours tells you what your own residue will look like.

Before you migrate

Three things, whichever system you choose:

• Write down your current rules explicitly, including the ones that only exist as habits. You cannot configure a system around undocumented conventions.
• Clean the employee data first. Duplicates, inconsistent date formats, and missing fields will follow you in.
• Run parallel for at least one cycle. Process a month in both the old process and the new system and reconcile line by line. Every difference is either a configuration bug or a rule nobody had written down. Both are worth finding before you depend on it.

The question that decides it

Ask each vendor: what happens in this system when a statutory rule changes next year? If the answer is that you update a configuration field, you have bought a spreadsheet with a login. If the answer is that they handle it and you get a release note, you have bought a system.

Yoddha Lab builds NepalHRM, a cloud HRMS whose payroll is structured around Nepal statutory requirements, with PF, CIT, SSF, and eTDS handled inside the platform, real-time biometric integration, and IRD-ready reporting across 25+ connected modules. For the underlying compliance concepts, see what PF, CIT, SSF, and eTDS mean in practice.

This article is general information, not tax or legal advice. Confirm current rates, thresholds, and deadlines with the Inland Revenue Department, the Social Security Fund, or your auditor.