The structure that catches teams out
PF is centralised: one establishment code per legal entity, regardless of how many states the entity operates in. ESIC is decentralised: sub-codes per state. Most multi-state employers know this in the abstract and forget it in practice when they expand into a new state.
The result: ESIC contributions get filed under the wrong sub-code, the employee's contribution history fragments, and at withdrawal the employee discovers the gap years after the fact.
The new-state expansion checklist
Five steps before the first salary lands in a new state: register for the state's ESIC sub-code, register for professional tax in that state, confirm whether labour-welfare-fund applies, update the bank-file format if the state mandates a specific layout, and add the state to the rate-engine.
Our payroll engine automates four of the five; the ESIC sub-code registration is still manual at the regulatory portal.
Cross-state edge cases
Employee transfers from Tamil Nadu to Karnataka mid-year. The PF code stays the same (centralised). The ESIC sub-code changes (decentralised). The professional tax slab changes (state-specific). The TDS computation pins the year-to-date for the regime the employee picked at the start.
Three changes from one transfer. Manual handling drops at least one. Multi-entity payroll covers the structural piece; this post is the operational supplement.
What to monitor monthly
Three numbers. ESIC challan acceptance rate per sub-code (should be one hundred per cent). PF challan match against the previous month (variance flags drift). PT submission timeliness per state (each state has its own window).
If any of the three drops, the issue compounds. Catching it in the cycle it happened is much cheaper than catching it in the quarterly audit.