How BlueOneHR Calculates PF, ESI, PT and TDS
If you run payroll for an Indian company, you already know the uncomfortable truth about statutory deductions: the rules do not sit still. Provident Fund contribution rates, ESI wage ceilings, Professional Tax slabs, TDS regimes, all of these change on a schedule set by the government, not by your finance calendar. A payroll process that gets this right in January can quietly get it wrong in July if nobody updated the numbers.
This is the specific problem statutory payroll computation exists to solve, and it is worth understanding how a system actually does it, rather than taking “we handle compliance” as a black box.
What “statutory computation” actually means
For an Indian employer, four deductions come up on almost every payslip:
- EPF (Employees’ Provident Fund) and its related components, EPS (Employees’ Pension Scheme) and EDLI (Employees’ Deposit Linked Insurance)
- ESIC (Employees’ State Insurance), for employees under the applicable wage ceiling
- Professional Tax (PT), a state-level tax with its own slab and due-date rules in each state that levies it
- TDS (Tax Deducted at Source) on salary, under whichever income tax regime the employee has opted into
Each of these has its own rate, its own wage base, its own ceiling, and its own effective date for when a rate change actually applies. Getting any one of them wrong is rarely a single mistake. It is usually a chain: a stale rate table produces a wrong deduction, which produces a wrong payslip, which produces a wrong statutory return, which produces a mismatch someone has to explain later.
BlueOneHR computes EPF, EPS, EDLI, ESIC, Professional Tax and TDS from versioned, effective-dated rules that cite the underlying Act (P-003). “Versioned and effective-dated” is the operative phrase: instead of one rate hardcoded into the payroll logic, each rule carries the date range it applies to, so a change in the law does not require guessing which payslips it touches. A payslip generated for March uses the rules that were in force in March, even if you run that payroll late, and even if the rate has since changed.
Why “cites the Act” matters more than it sounds
It is easy to write a payroll formula that produces a number that looks right. It is a different thing to be able to point at where that number came from. When a statutory rule in the system cites the Act it is drawn from, two practical things follow.
First, when a rate or a threshold does change, whoever maintains the system knows exactly what changed and why, instead of reverse-engineering a formula from old payslips. Second, when a statutory authority or an auditor asks “why was this employee’s PF calculated this way,” the answer is not “the software did it,” it is a traceable rule with a source.
This matters more than it might seem for a company that is scaling past the point where a founder or a single HR person can hold every rate in their head. The 20-employee mark, where PF registration typically becomes mandatory, is also roughly the point where manual tracking of six or seven overlapping statutory schedules stops being realistic.
The part that is easy to skip: reconciliation
Computing a deduction correctly is only half the job. The other half is making sure the number that left the payslip actually matches the number that gets remitted and filed, and that neither number quietly drifts from what the books say.
BlueOneHR’s payroll register is reconciled against the general ledger, and statutory liability is checked against what was actually filed and paid (P-006). In practice this means the platform is not just calculating a PF deduction once and forgetting about it. It is holding three numbers in view at the same time: what the payslip deducted, what the ledger recorded, and what was actually paid to the statutory authority. When those three numbers agree, that is a boring, unremarkable payroll cycle, which is exactly what a payroll cycle should be. When they do not agree, that is precisely the kind of gap that is expensive to discover six months later during an audit, and cheap to catch the month it happens.
What this does not mean
It is worth being precise about the boundary here, because overclaiming compliance software is a common and costly mistake. A versioned, effective-dated rule engine that computes deductions correctly is not the same thing as a system that files your returns for you, and it is not the same thing as legal or tax advice. Rate changes still originate from the government, not from the software; a payroll engine’s job is to apply the current rule correctly and keep an auditable record of which rule applied when, not to interpret ambiguous law on your behalf.
If your current process for tracking PF, ESI, PT and TDS rates involves a shared spreadsheet, an HR generalist’s memory, or “we will check that when it comes up,” the risk is not that you are doing it wrong today. It is that the rules move and your process does not move with them automatically.
Where to look next
If you want to see how this plays out on an actual payroll run, including how the register lines up against the ledger, the compliance page is the right starting point. If you are already convinced and want to see it against your own employee data, the platform is available on a 30-day free trial of the whole product, no card required to start (C-002).
Claims cited: P-003 (versioned, effective-dated statutory computation for EPF/EPS/EDLI/ESIC/PT/TDS, citing the Act), P-006
(payroll register reconciled against the general ledger, statutory liability checked against filed and paid), C-002 (30-day free
trial, no card to start). Source: docs/GTM_CLAIMS.md, sections A and B, verified 2026-09-21.