Why Payroll Software Is Harder to Build Than It Looks

The first time I was asked to work on a payroll module, I was told the scope was "salary calculation and payslip generation." That description is accurate in the same way "driving a car" is an accurate description of Formula 1 racing. Technically correct. Does not prepare you for what's actually involved.

Payroll is governed by rules that sit outside the software: income tax slabs, social security contributions, professional tax rates that vary by state in India, gratuity eligibility thresholds, leave encashment rules, advance deduction schedules, loan recovery sequences, LTA exemption cycles, HRA calculations that depend on the employee's city of posting. These rules are not static. They change with every union budget, every state government notification, every court ruling on a contested deduction. The software doesn't define the rules. It implements them, correctly, for every employee, every month, with no exceptions.

The Structure of a Pay Run

A payroll system at a mid-sized company, say, 5,000 employees, processes a monthly pay run. The run itself is a batch job, but what feeds into it is several months of accumulated data: attendance records, leave applications and approvals, salary revision letters, joining dates for new hires, exit dates for separations, LOP (loss of pay) deductions for unauthorised absences, advances granted by HR, court-ordered deductions, arrears from delayed promotions, bonus declarations that need to be included or excluded from the current run.

The batch takes all of this input, applies the rules for each employee's pay structure, calculates gross earnings, applies all deductions in the correct sequence, arrives at the net payable, and produces a record of what each employee is owed for the period. The record is used to generate payslips, create a bank transfer file, post journal entries to the general ledger, and produce statutory returns for tax authorities.

The "correct sequence" for deductions matters more than it sounds. If a loan recovery is applied before the statutory deductions, the loan amount is subtracted from a higher gross and the tax calculation changes. If professional tax is applied before provident fund, the base for PF calculation shifts. The deduction sequence is not arbitrary, it is defined by statute and company policy and must be implemented consistently and correctly for every employee in every pay run.

What Makes a Calculation Genuinely Hard

Consider HRA, House Rent Allowance. The tax-exempt portion of HRA an employee can claim is the minimum of three figures: the actual HRA received, 50% of basic salary if the employee lives in a metro city (40% otherwise), and the actual rent paid minus 10% of basic salary. The employee has to submit rent receipts. The city classification matters. "Metro" and "non-metro" have specific lists that the government can update. If an employee transfers cities mid-year, the calculation changes partway through the financial year. If the employee doesn't submit rent receipts by the deadline, the full HRA is taxable. The payroll system has to track all of this, apply the correct exemption amount month by month, and adjust the tax withholding accordingly.

Now multiply this complexity by every other tax-saving component, LTA, medical reimbursements, section 80C investments, NPS contributions, home loan interest deductions, and by the fact that income tax is annual but withheld monthly, which means the system has to project the annual income tax liability, divide it across the remaining months of the financial year, and recalculate that projection every month as new information arrives. A salary revision in October changes the projected annual liability and the monthly withholding for the rest of the year. A declaration submitted in February changes the withholding retroactively, sometimes resulting in a tax reversal that is applied in the current period rather than refunded separately.

None of this is conceptually difficult. Each rule is understandable in isolation. The complexity comes from the interactions between rules, from the sheer volume of edge cases (partial months, mid-period transfers, retrenchment payouts, death-in-service payments, maternity leave pay), and from the absolute requirement that the output is correct. In most software, a 0.01% error rate is acceptable. In payroll, it is not. An employee who received the wrong amount, too much or too little, has a concrete, personal, financial grievance. At 5,000 employees, a 0.01% error rate means five wrong payslips per month, every month.

The Off-Cycle Run Problem

Regular monthly payroll is the main run. Off-cycle runs, ad hoc payments processed outside the normal schedule, are where payroll systems tend to show their weaknesses.

Off-cycle runs happen for a range of reasons: an employee is leaving mid-month and needs a final settlement calculated before the regular run, a bonus that was approved after the regular run needs to be disbursed immediately, an error in the previous run is discovered and needs to be corrected with a supplementary payment. Each off-cycle run has to be processed through the same calculation engine as the main run, producing correct deductions, correct tax calculations, and correct accounting entries, while not affecting the other employees who were in the main run and whose data is now locked for audit purposes.

A common architectural mistake is treating off-cycle runs as simple one-off payments rather than mini pay runs with their own lifecycle. An employee who receives a bonus payment mid-month in an off-cycle run has their income tax liability for the year revised upward. The next regular run has to account for the tax that was withheld in the off-cycle run. If the off-cycle run is not properly integrated into the pay run history, the tax calculation for the rest of the year will be wrong, not by a lot, possibly, but by enough to produce a discrepancy that only surfaces in the final tax reconciliation in February, months after the original error.

Arrears and Why They're Complicated

Arrears in payroll arise when a salary revision is backdated. An employee's promotion was approved in September with an effective date of July. Three months of arrears need to be paid, the difference between the new salary and the old salary for July, August, and September. The arrears payment is straightforward to calculate. The tax implications are not.

In India, arrears can be paid with the benefit of Section 89 relief, a provision that allows the tax on arrears to be calculated as if the arrears had been received in the original year rather than the current year, reducing the tax payable if the employee was in a lower tax bracket in the prior year. Calculating Section 89 relief requires the system to reconstruct the employee's tax liability for prior years as they would have been if the arrear amounts had been included, compare that with the actual tax paid in those years, and compute the relief. This requires accessing pay history going back potentially several financial years, recalculating with different income amounts, and producing a statutory Form 10E that the employee has to file with the tax authority.

Most payroll systems handle basic arrears. Fewer handle Section 89 correctly. Fewer still handle the case where an employee had salary components with different tax treatment in the prior years versus the current year, or where statutory rates changed between the original period and the arrears payment period. These edge cases exist. They affect real employees. They are why payroll is not, in practice, just arithmetic.

Statutory Compliance and the Calendar

Beyond the pay run itself, payroll systems are responsible for a set of statutory filings that have fixed deadlines. PF remittance is due by the 15th of each month. ESI remittance is due by the 15th. TDS (tax deducted at source) remittance is due quarterly. Annual returns, Form 24Q for TDS, ECR for PF, ESI returns, have their own deadlines. Missing these deadlines attracts penalties and interest. In some cases, repeated non-compliance can result in legal action against the employer.

The payroll system has to produce the files, reports, and returns that feed these filings. The formats change periodically, the government updates the ECR format, the TDS return format changes with new budget provisions, new fields are added to existing returns. Each change requires the payroll software to be updated, tested, and deployed before the next filing cycle. For cloud-based payroll software serving thousands of company clients, a format change requires coordinated updates across all client configurations, plus validation that the generated files are accepted by the relevant government portals before the actual deadline.

This is the operational reality behind what looks, from the outside, like "salary calculation software." The calculation is a small part of the system. The larger part is the framework of rules, deadlines, format specifications, edge cases, and error handling that makes the calculation both correct and compliant in every month, for every employee, without fail.