HR and payroll
People, contracts, attendance, leave and the payroll run that depends on all four being right. This is the platform we know best — Zetta HRM is our own, and it is the system we have spent the most engineering on.
Talk about scopePayroll is where HR software is actually decided
Everything upstream of the payroll run is a form. The run itself is arithmetic that has to be defensible to an employee holding a payslip, to finance, and sometimes to a regulator — and it has to reproduce itself identically if it is asked about a year later. These are the parts that take the time, and none of them are visible in a feature list.
The five things that make a payroll run hard to get right
A period that is not really closed
Payroll is run, and then something arrives late — an approved overtime claim, a backdated raise, a leaver whose last day moved. Reopening a closed period has to produce an adjustment that is traceable to the original rather than a silently amended history, because the employee has already been paid the earlier figure and can see it.
Time is not a number of hours
Attendance arrives as shifts, exceptions, approved and unapproved absence, partial days and holidays that differ by location. Turning that into paid hours is a set of rules per employment type, and the rules change without warning. The rules have to be data rather than code, or every policy change becomes a deployment.
Deductions have their own calendars
Statutory contributions, provident fund, loan instalments and tax do not share the payroll period or each other's rounding. Each accrues on its own basis and each has to reconcile independently at year end, which is why they are modelled separately rather than as columns on a payslip.
Rounding has to total
Amounts rounded per line will not sum to the rounded total, and the difference has to land somewhere deliberate rather than wherever the arithmetic drops it. The same applies to instalments: the final one is trued up so the schedule settles to the exact amount owed rather than a few units short.
It must reproduce, long afterwards
Asked in eighteen months why a figure was what it was, the system has to give the same answer — which means storing the inputs and the rule version alongside the result, not just the result. Recomputing against today's rules answers a different question from the one being asked.
Very few people may see it
Payroll is the most sensitive data in most organisations, and the access model around it has to be finer than the one covering the rest of HR. That is a permissions design decision made early, not a checkbox added when someone notices.
What a run has to survive
- A month that is reopened and rerun after it was closed.
- A mid-month change to a salary, backdated.
- A joiner and a leaver in the same period, both part-paid.
- Statutory deductions that changed partway through the year.
- A rounding rule that must still total exactly at year end.
- Producing the identical figure again eighteen months later.
Storing the inputs and the rule version alongside the result is the difference between answering the question and answering a different one confidently.
Where the depth actually is
These are the parts of Zetta HRM that took real work, listed because they are the ones a generic package tends not to reach.
- Provident fund: contributions, the fund's own balance, and interest apportioned across members.
- Gratuity accrued on an averaged basis rather than a final-salary snapshot.
- Flexible and shift-based timing feeding attendance into the run.
- Loans and advances recovered by instalment, trued up so the last one settles exactly.
- Role and permission control fine enough that payroll is visible to the few people it should be.
- An append-only trail behind every figure, because "why is this different from last month" is the most common question there is.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.