Software
Leave management software for Nepali organisations
Nepal’s leave types behave differently from one another. Software that models one configurable pool will need manual handling for most of them.
Updated August 2026
Leave looks like a simple problem until you model it. Nepal’s Labour Act provides several distinct leave types, and they differ in how they are earned, whether they carry forward, and whether an unused balance can be paid out.
Types that behave differently
Home leave typically accrues in proportion to days worked, so a new joiner starts near zero and builds. Sick leave is more commonly an annual entitlement available from the start of the year. Mourning, maternity and paternity leave are granted on a qualifying event rather than accrued at all.
Configuring all of these as one pool with a single annual grant will over-credit new joiners on accrual-based types and misrepresent the event-based ones entirely.
What the software has to support
- Separate leave types, each with its own accrual model, entitlement and carry-forward cap.
- A leave year aligned to the Bikram Sambat fiscal year, so it resets with payroll and tax.
- A Nepali public holiday calendar including additional days for female employees.
- Approval chains that follow the reporting structure, with delegation when an approver is away.
- Balances visible to employees before they request, which removes most HR queries.
- Encashment and final settlement routed into payroll as taxable salary income.
Balances and history
An employee querying a leave balance is usually asking about a past period — what they had at a point in time, and what consumed it. A system that stores only the current balance cannot answer that.
Keeping the transaction history — accrual, consumption, carry-forward, lapse, encashment — makes the current balance a derived figure that can always be explained.
Leavers and final settlement
- 1Freeze accrual at the last working day rather than at the end of the month.
- 2Apply any carry-forward or lapse rules that fall due before the exit date.
- 3Compute the encashable balance under the policy for each leave type.
- 4Pass the encashment into payroll so it is taxed in the correct fiscal year.
- 5Retain the leave history after exit, since queries can arrive later.
Where leave systems usually fail
Leave software rarely fails on the request-and-approve flow, which is the part everyone demonstrates. It fails at the year boundary and at the exit date, which nobody demonstrates.
| Symptom | Underlying cause |
|---|---|
| Balances jump on new year | Carry-forward cap not applied, or applied on the Gregorian boundary |
| New joiners have a full annual balance | Accrual-based leave configured as an annual grant |
| Encashment missing from tax | Leave module not connected to payroll |
| Balance disputes cannot be settled | Only the current balance stored, no transaction history |
| Requests stall | No delegation when the approver is on leave themselves |
Frequently asked questions
Should leave software follow the Nepali or Gregorian year?
The Bikram Sambat fiscal year, so leave carry-forward resets on the same boundary as payroll accumulators and the tax year. Different boundaries create annual reconciliation work.
How should leave encashment be handled?
As a payroll event. The payment is salary income in the year it is made, so it belongs in the annual income projection and is taxed at the employee’s marginal rate.