Paying staff in the Nepali month, not a borrowed Gregorian one

A Nepali office runs on the Bikram Sambat calendar, and payroll keyed to the Gregorian month is paying the wrong three weeks. Ashar 2083 ran from 15 June to 14 July 2026, not from 1 to 31 July. A payroll run that calls itself "July" is a run for a month nobody who works there recognises, and the attendance sitting next to each name is counted against the wrong dates. OfficeYak's payroll module opens a run against the actual Nepali month, "2083-03" rather than "July", and works out the real Gregorian dates behind it automatically.

This is not a cosmetic difference. It decides which days of attendance get counted, which holidays fall inside the run, and whether the number on a payslip matches the days the person was actually at their desk.

A Nepali month and a Gregorian one do not line up

Nepali months do not run to a fixed length the way Gregorian months mostly do. They are published year by year rather than calculated from a simple rule, which is why a run has to ask a calendar what a given month actually covers rather than assume it. Baisakh, Jestha, Ashar and the rest each have their own start and end date in the Gregorian calendar, and that start date moves slightly from year to year.

Treat a Nepali month as "the Gregorian month it mostly overlaps with" and the error is not large, but it is not zero either, and payroll is one of the few places in an office where a few days in either direction shows up as a real number in someone's bank account.

A run is opened against the real month, not a guess

A payroll run in OfficeYak is stored as a Nepali year and month, such as 2083-03 for Ashar 2083, and the Gregorian start and end date is worked out from that whenever the system needs real dates, mostly to decide which attendance falls inside the run. That conversion goes through a dedicated calendar library rather than a table typed out by hand, for the same reason the months are not a fixed length: a hand-copied table is only as good as whoever copied it, and nothing flags a wrong entry until a run closes on the wrong days.

A branch can also run on the Gregorian calendar instead, for the handful of offices that genuinely want that, but the Nepali calendar is the default and the one most consultancies in the country actually mean when they say "this month".

The days on the payslip come from the clock, not from memory

Once a run opens, each person's line starts with the number of days the branch was open that month, which is the days between the run's start and end date minus whatever holidays were recorded against that branch, and the number of days that person actually clocked in during the same window. The present and absent counts land on the payroll line at that moment and stay there. OfficeYak's payroll reads the days actually clocked rather than a figure typed from memory, which is why a late attendance correction the following week cannot quietly change what a payslip already said.

That matters most for the roles where "I'll adjust it later" is the normal way an office runs, because later is exactly when nobody remembers why a number changed.

Gross, deductions, and what is still typed in by a person

The days a person worked decide the attendance half of the line. The pay half is entered the same way most Nepali offices already think about it: a basic figure, an allowance and a bonus on one side, and social security, provident fund, tax deducted at source, Citizen Investment Trust contributions, any advance recovered, and anything else on the other. Nothing about the calendar removes the judgement calls a payroll person still has to make, a bonus is still a decision, a deduction still needs a reason. What the calendar fixes is the one number that should never be a judgement call at all, which is how many days someone was actually there.

A branch at a time, which is the only way a second office works

A run belongs to one branch and one month, not to the consultancy as a whole. A three-branch consultancy opens three runs for the same Nepali month, one per branch, rather than trying to run payroll for the whole organisation in one pass and then split it afterwards. That matters for the same reason splitting responsibility between branches matters everywhere else in the office: a branch manager closing their own run should not be waiting on another branch's attendance to finish being entered.

Once it is paid, it is paid

A run moves from draft to paid, and a paid run is locked at the point where the data is stored, not just hidden behind a warning in the interface. Nobody, including the owner, can edit a line on a run that has already been marked paid. For an incentive structure that depends on being calculated the same way every month rather than renegotiated after the fact, a payslip that genuinely cannot be quietly changed is the whole point, not a detail.

That is the same promise this site has made about incentive pay before: a counsellor paid by a rule that can be rewritten after the fact is being paid by goodwill, not by a rule. A payroll run locked at Ashar's real dates, with Ashar's real attendance, paid once and then frozen, is what makes that promise something more than a sentence on a page.