IustumHR

NSSF contributions, Tax on Salary withholding, GDT filing outputs, seniority accrual, shift scheduling, leave balances, geofenced attendance, daily NBC exchange rates, multi-tenant isolation at the database level.

An employee can hold two contracts in one month for two entirely different reasons: one replaced the other mid-month, or they genuinely hold both at once. In the data those are the same shape — two contract rows overlapping one payroll period — and they have to produce different arithmetic. Gross pay was never the problem; it summed and itemised correctly throughout, and so did the tax and contributions drawn from it. Every rate derived from it was wrong. On a back-to-back renewal the overtime hourly rate, the price of an unpaid day and the seniority base were all computed from the two salaries added together, even though only one contract was ever in force on any given day. Nothing on the payslip looked wrong, because the headline figure was right.

The first correction took the highest salary in the period instead of the sum. That is right for a renewal and wrong for genuine concurrency, where it prices overtime against one contract rather than the combined wage — and under-pricing overtime is a compliance question, not a rounding preference. We had also proposed simply preventing contracts from overlapping. That was the wrong instinct: holding two at once is a real employment shape, not a data-entry error, and the engine had to serve it rather than forbid it. So it stopped asking which contract applies and started asking which day. Every rate now derives from the salaries actually in force day by day — one contract on a renewal day, both on a concurrent one. Single-contract months come out byte-identical, which the test suite proves, and that suite is the point: its expected figures are worked out by hand from the statutory rules and written beside the assertions, never copied from whatever the engine happened to produce.

In production, running real payroll every month.