KMI HRM · PROBLEM SOLVED · OCTOBER 2026
Every company changes its salary rules eventually. Overtime gets capped, the late policy changes, one plant works differently from another. If those rules live in the code, each change needs a developer and puts old calculations at risk. Any business running payroll, in any country, meets this problem.
How attendance, HR and payroll for a Pakistani company of several sites and plants came together, from fingerprint machines to the phone in an HR manager’s hand.
Salary rules change, but last month’s salary must stay exactly as it was. We solved it by giving each rule a start date and a level in the company, so payroll always uses the rule that applied on that day.
The simple design is one settings page: overtime rate here, short-day limit there. It works until someone changes a number and a past month is recalculated. Suddenly October’s salary sheet no longer matches what was paid, and nobody can explain why.
So payroll asks one question for each day of each employee: which rule was in force for this person on this date?
Short days, overtime rounding and limits, the sandwich rule for leave around holidays, and the full attendance bonus all became policy settings. So did statutory deductions such as social security and provident fund, along with leave entitlement and carry-forward. The final settlement when someone leaves reads from the same rules.
People do not trust a calculation they cannot check. So the Policies page has a one-day tester: pick a case and see which rule applies and what it produces, before it touches a salary sheet. HR can answer “why was this deducted?” without calling a developer, and that matters as much as the calculation being correct.
Anything that decides money should have a date on it. If you cannot answer “what was the rule on that day?”, you cannot defend the number.