PF, ESI, PT and TDS: what Indian payroll software actually has to handle

Most businesses do not move off spreadsheets because salary maths is difficult. Basic pay times days worked is not the hard part. They move because four separate sets of statutory rules sit on top of that number, each with its own base, its own thresholds and its own authority to answer to.

Here is what each one actually demands of a payroll system, and why they are awkward to hold in a workbook.

Provident Fund

PF is a contribution from both the employee and the employer, calculated on specific wage components rather than on gross salary. Which components count is the first thing that trips up a spreadsheet, because the answer depends on how your salary structure is built — and if you restructure salaries, the PF base changes with it.

The system has to know which components are PF-applicable, apply the contribution correctly for each employee, handle employees above and below the applicable wage ceiling differently, and produce employee-wise details in the format needed for monthly filing.

The failure mode in a spreadsheet is subtle: someone adds a new allowance, nobody updates the PF formula, and the base quietly becomes wrong for everyone. It is usually discovered months later.

Employee State Insurance

ESI applies to employees earning within a specified wage limit, with contributions from both employee and employer. Two things make it awkward.

First, eligibility is a threshold — an employee crosses it and the treatment changes, but not necessarily from the month they cross it, because ESI operates in contribution periods. Handling that transition correctly matters and is easy to get wrong by hand.

Second, applicability depends on the establishment and its location, so a business operating in more than one place cannot assume a single answer.

Professional Tax

PT is the one that catches growing businesses out, because it is a state subject. The slabs, the deduction frequency and whether it applies at all vary by state.

The moment you have employees in more than one state, PT stops being a single figure in a column and becomes a per-employee calculation driven by the state that employee is mapped to. A workbook built when everyone sat in one office does not survive the first branch opening — and the error is silent, because the sheet keeps producing a number.

Tax Deducted at Source

TDS on salary is the most involved of the four, because it is not a monthly calculation at all. It is an annual liability, projected across the year and recovered in monthly instalments.

The system needs to project annual income per employee, apply the tax regime that employee has opted for, account for declared investments and proofs, adjust when someone joins or leaves mid-year, and re-spread the remaining liability across the remaining months when any of that changes.

That last point is what defeats spreadsheets. A single mid-year change — a salary revision, a late investment declaration, an employee resigning — requires recalculating the projection and redistributing the balance. Doing it by hand for a few employees is tedious; for a few hundred it is not realistic.

The rest of the statutory picture

Depending on state and employee category, Labour Welfare Fund may also apply, usually at a low value and an irregular frequency, which is exactly the kind of deduction that gets forgotten.

Alongside the deductions sit the outputs: payroll registers, employee-wise statements and the supporting data your consultant or filing team needs. A system that calculates correctly but cannot produce the register in a usable form has only solved half the problem.

Why the calculations are not the real argument for software

You can calculate all of this by hand. Plenty of businesses do.

The argument for a system is what sits around the calculation:

• Attendance feeds payroll directly. Payable days, loss of pay and overtime come from attendance records rather than a second, manually maintained sheet that has to agree with the first.
• Changes propagate. A mid-year salary revision updates the PF base, the TDS projection and the payroll register together, not in three places by hand.
• The register is a by-product. Compliance reporting comes out of the same data that produced the payslips, so it cannot disagree with them.
• There is a trail. When someone asks why a deduction changed in August, the answer is in the system rather than in someone's memory.

What to check before you buy anything

Payroll software sold in India varies enormously in how much of the above it genuinely handles. Worth asking directly:

1. Can PF-applicable components be configured, or are they fixed?
2. Is Professional Tax handled per state, per employee — not a single organisation-wide slab?
3. Does TDS projection re-spread automatically when salary or declarations change mid-year?
4. Does attendance flow into payroll, or is it re-entered?
5. Can the register and statutory summaries be exported in the form your filing team actually needs?
6. Is full and final settlement handled, including recovery of loans and unadjusted advances?

A demo that only shows a payslip being generated has not answered any of these.

One caveat worth stating plainly

Rates, thresholds and slabs change, and they differ by state and by establishment. Any system should be configured against the rules that apply to your organisation and verified with your own compliance advisor before the first live payroll run — not assumed correct because the software has the right field names.

If you want to see how this is configured in practice, look at how our HR and payroll system handles it, or book a demo and we will run your own structure through it.