Payroll looks like arithmetic and is really a compliance system with an arithmetic component. In India a single monthly run touches provident fund, employees' state insurance, professional tax, income tax deduction at source, labour welfare fund in some states, and gratuity provisioning — each with its own thresholds, its own filing, and in several cases its own state-level variation. Software that computes a net figure correctly and cannot produce the returns has solved the easy half.
The variation by state is what defeats products designed elsewhere. Professional tax is a state levy with different slabs, different due dates and, in some states, no levy at all. Labour welfare fund applies in some states and not others, sometimes half-yearly. Minimum wages are notified by state and by category of work. A company with people in four states runs four different rule sets in the same payroll cycle, and hard-coding any of it guarantees a rewrite.
Structure matters as much as computation, because the salary structure determines the statutory outcome. How basic, allowances, reimbursements and variable pay are defined changes what is subject to provident fund, what is taxable, and what an employee actually receives. Software that treats the structure as a flat list of components, rather than as a model with rules about which components attract which deductions, will produce numbers that look right and are not.
The filings are the deliverable, not a report. Monthly and annual returns, challans, and the formats each authority expects — including the ones that must be submitted through a specific portal in a specific file layout. A payroll product that computes correctly and leaves the user to prepare filings by hand has left the hardest and most error-prone part with the customer, and that is the part they were buying software to remove.
Then there are the things that arrive as exceptions and are actually the normal case: mid-month joiners and leavers, arrears from a backdated increment, loss of pay, full and final settlement with gratuity and leave encashment, and a salary revision applied retrospectively across a quarter. Each requires recomputation of prior periods and correct treatment of the tax already deducted. Products that handle the steady state elegantly and the exceptions badly are the ones payroll teams end up running alongside a spreadsheet.
Two design principles hold across all of it. Keep the rules as data with effective dates rather than as code, because rates and thresholds change with budgets and notifications and you cannot ship a release for each. And make every payslip reconstructable — what rules were in force, what inputs were used, what was computed — because an employee query about a deduction from fourteen months ago is a routine request, and answering it should take a lookup rather than an investigation.
