India labour codes payroll compliance is per-state now

India's four labour codes came into force on 21 November 2025, replacing 29 legacy laws. The Central Rules that make them operable were notified on 8 May 2026 — 168 days later.

If you are building or buying payroll software, the gap between those two dates is not the interesting part. The interesting part is that neither of them tells you which rules actually govern a given employee. India labour codes payroll compliance is not one target. It is up to thirty-six of them, and most are still moving.

What changed in the calculation

Three provisions rewrite the arithmetic rather than the paperwork.

Basic pay is floored at 50%. The unified wage definition requires basic salary to be at least half of total compensation, with allowances confined to the remainder. The long-standing practice of holding basic low and inflating allowances — which suppressed provident fund, gratuity and bonus liability — no longer works. For a workforce structured the old way, every downstream statutory figure moves at once.

Fixed-term gratuity drops from five years to one. This is the change with the largest balance-sheet effect and the least coverage. Fixed-term employees also become entitled to ESI, EPF and bonus proportionate to tenure. If your organisation uses fixed-term contracts at any scale, a liability that previously vested rarely now vests routinely.

Overtime is at least twice the normal rate of wages. Stated plainly in the Wage Rules, and interacting with the point above: "normal rate of wages" is computed on the new definition, so a higher basic raises the overtime rate too.

None of these is hard to implement. All three are hard to implement once, because the thing they depend on is not settled.

Why your payroll system cannot simply be compliant

Labour is a concurrent subject under the Indian Constitution. The codes are national; the rules under them are not.

Which set applies turns on whether the central government is the "appropriate government" for a given establishment. Where it is not, the relevant state government's rules apply, and the assessment is establishment by establishment.

So the state of play is uneven. A tracker maintained as of 11 May 2026 put sixteen states and union territories as having notified rules across all four codes — Arunachal Pradesh, Bihar, Gujarat, Lakshadweep, Manipur, Meghalaya, Puducherry, and Dadra & Nagar Haveli and Daman & Diu among them. Several others are partway: Nagaland had notified three codes, the Andaman & Nicobar Islands two, Punjab and Sikkim one each, Rajasthan only the OSH Code. West Bengal had not published a draft at all.

Read that as an engineering requirement rather than a legal curiosity. A company with staff in six states may be operating under four different rule sets and two legacy regimes simultaneously, and the set that applies to any individual can change when their state notifies.

The mistake we keep being called in to fix

Teams encode the wage rules as logic. A function called calculateStatutoryWages that implements the fifty per cent floor, the contribution bases and the overtime multiplier, deployed once, correct on the day it shipped.

Then Karnataka notifies its rules with a different treatment of a particular allowance, and the change is a code change: a ticket, a sprint, a release, a regression risk across every other state. Do that four times a year across a dozen jurisdictions and payroll becomes the system nobody wants to touch before the 28th.

The alternative is unglamorous and obvious in hindsight. The wage definition is configuration: a versioned, dated rule set per jurisdiction, with the engine reading it rather than embedding it. Adding a state becomes a data change reviewed by whoever owns compliance, not a deployment.

What that looks like in practice

Four properties matter, and they are the same four whether you build or buy.

• Rules are dated, not current. A payroll run for March must use the rules as they stood in March, not as they stand today. Systems that hold only the current configuration cannot reproduce a historical payslip, which is exactly what an inspection asks for.
• Jurisdiction resolves per employee, not per company. The unit is the establishment, so the resolution has to happen at the level of the person and their place of work.
• Every derived figure is traceable to the rule that produced it. When somebody asks why an employee's PF contribution changed between two months, the answer should be a diff, not an investigation.
• Unknown is a state the system can hold. Where a jurisdiction has not notified, the honest position is that the rule is undetermined and legacy provisions continue — not a silent fallback to the central default, which is how you produce a confidently wrong number.

The records changed too

The Central Rules prescribe specific registers: Form I for the employee register, Form IV for wages, overtime, advances, fines and deductions, Form V for the wage slip format, and Form IX for the attendance register cum muster roll. The OSH Rules contemplate electronic wage slips and record-keeping.

Two consequences for anyone with an existing system. Your payslip template is now a prescribed format rather than a design decision. And your registers need to be generated from the same data that produced the payment, rather than assembled afterwards from exports — because the point of a prescribed register is that it reconciles.

One further wrinkle worth flagging to your advisers: the final Social Security Rules did not retain the detailed exclusions that had been proposed in the draft rules, so gratuity treatment should be read against the Codes themselves rather than against notes written during consultation.

What we did about it

We built Nomina, an enterprise payroll platform with more than thirteen core modules and five user roles, processing payroll roughly five times faster than the process it replaced.

The design decision that has aged best is the least clever one: statutory rules live in versioned configuration, not in the payroll engine. When a jurisdiction moves, somebody who understands compliance edits a rule set with an effective date and it is reviewed like any other change. No release, no regression sweep across unrelated states.

The decision we would revisit is assuming the rule sets would converge. They have not, and the tracker above suggests they will not soon. If we were starting today we would treat divergence as permanent rather than transitional, which mostly means investing earlier in the tooling to compare two jurisdictions side by side.

What this means if you are buying rather than building

Most organisations will resolve this with a vendor, not a project. Four questions separate a provider that has done the work from one that has updated its marketing.

"Show me a payslip regenerated for a payroll run from before the codes." If the system reproduces it using the rules that applied at the time, dated configuration exists. If it reproduces today's numbers against last year's payroll, it does not, and no amount of assurance changes that.

"Which states are you currently modelling separately?" A specific list is a good answer. "We follow the central rules" is an answer about a subset of establishments, whether or not the person saying it knows that.

"What happens on the day a state notifies?" Configuration change, or product release? The second means you wait behind every other customer's request.

"How do you handle a jurisdiction that has not notified?" The correct answer names legacy provisions explicitly. An answer that silently applies the central default is producing numbers it cannot justify.

When not to rebuild

If you operate in one state, employ under fifty people, and use no fixed-term contracts, this is a configuration exercise for your existing provider and a conversation with your auditor. Rebuilding payroll to handle jurisdictional variance you do not have is a way to spend a quarter badly.

The threshold where custom becomes defensible is roughly: multiple states, meaningful fixed-term or contract headcount, and an existing system that cannot express a dated rule change without a deployment. Below that, pressure your vendor. Above it, the cost of a wrong statutory figure at scale exceeds the cost of the platform.

The practical next step

Before any build decision, run one exercise. List every state your employees sit in, and against each, write down which rules currently govern and the date you last checked. Most organisations cannot complete that table, and the gaps are the actual risk — not the fifty per cent rule, which everybody has heard about, but the state that quietly notified in March while nobody was watching.

If the table is short, you have a configuration problem. If it is long and mostly blank, you have a systems problem, and we are happy to work through it with you — including in the cases where the answer is that your current provider can handle it.