An employee comes to the office with a payslip and asks why the deduction is what it is. Somebody opens the payroll system, looks at the figure, and can see that it is the figure, but not how it got there. So the conversation moves to a spreadsheet, and from there to a guess.
This happens in systems that calculate perfectly correctly. The arithmetic is not the problem.
Numbers versus dated rules
Most payroll software stores a statutory rate as a number. The EOBI wage ceiling is a value in a settings table; the tax slabs are a table someone edits when the budget changes; the provident fund rate is a field on a form.
The moment that rate changes, one of two things happens, and both are bad.
Either the old value is overwritten, in which case last year's payslips will now recalculate differently from the way they were paid, and the history quietly becomes fiction. Or a second copy is created and the code has to decide which one applied in March, which usually means somebody writing a condition that is right for this change and wrong for the next one.
The alternative is to store the rule with the dates it was in force. Not "the ceiling is X" but "the ceiling was X from this date until that one". Then a March payslip is not a stored total that must be trusted; it is a recomputable result of the rules that were live in March.
What that buys you
Three things, and they only arrive together:
- An answer to the question. Every figure links back to the rule and the rate that produced it, so the conversation with the employee ends at the rule instead of at somebody's recollection.
- Closed months that stay closed. A historic run keeps the rates it ran on. Nobody has to reopen an approved month to check something, which is what usually breaks it.
- A correction that is not a cover-up. When a mistake does need fixing, it is a recorded adjustment attributable to a named user, not an edit that leaves the original looking as though it was always that way.
The same argument applies to gratuity
Gratuity is the clearest case, because the failure is delayed. If it is calculated when someone resigns, the liability does not exist on the books until the day it becomes urgent, and by then it is a number you are learning about rather than one you have been carrying.
Accruing it monthly is not more precise arithmetic. It is the difference between a liability you can see and one that arrives with a resignation letter.
What to ask
If you are evaluating payroll software, the useful question is not "does it handle EOBI". Almost everything does. Ask instead:
- Show me the rule behind this deduction, and the dates it applied.
- Recalculate a payslip from eight months ago. Does it match what was actually paid?
- Correct an approved month in front of me. What does the audit trail say afterwards, and whose name is on it?
A system built on dated rules answers all three in about a minute. One built on numbers will answer the first by opening a spreadsheet, which is the whole problem, demonstrated.