The labour codes' 50% wage rule isn't a policy tweak. It's a payroll data-model rewrite.

What actually changed when the labour codes took effect on 21 November

On 21 November 2025, the Indian government notified all four labour codes into force at once: the Code on Wages, the Industrial Relations Code, the Occupational Safety, Health and Working Conditions Code, and the Code on Social Security. Together they replace 29 separate central labour statutes, several of them in force since the 1930s, with four consolidated laws covering wages, industrial disputes, workplace safety, and social security.

That notification made the codes law. It didn't make them operable. Rules are what tell an employer what to actually compute, file, and register, and those took another five and a half months to arrive: the Centre notified the final central rules for all four codes, including the Code on Wages (Central) Rules 2026 and the Social Security (Central) Rules 2026, on 8 May 2026. The gap between a code being in force and a code being usable is the detail most coverage of this story skips past, and it matters because the rules, not the Acts, set the mechanics a payroll system has to encode.

For a payroll or HRIS team, the exact date matters less than three specific mechanics buried inside the codes: how wages get defined, how fast a final settlement has to happen, and who now qualifies for gratuity. Each one forces a different kind of system change, and none of them resolves with an updated policy document.

The 50% wage rule, and why it isn't an HR decision

Section 2(y) of the Code on Wages defines "wages" narrowly: basic pay, dearness allowance, and retaining allowance where applicable. Everything else sits in a separate list of exclusions: house rent allowance, conveyance allowance, statutory bonus, the employer's own provident fund contribution, overtime pay, commission, and several other categories.

The exclusions aren't unlimited. If everything in that excluded list adds up to more than half of an employee's total remuneration, the excess gets reclassified. It stops being an exclusion and becomes wages by operation of law, for every statutory calculation that depends on the wage definition: provident fund contribution, gratuity, statutory bonus, overtime rate.

That single mechanic collides with roughly two decades of standard Indian CTC design. Most cost-to-company structures kept basic pay deliberately low, often 30 to 40 percent of total compensation, specifically because basic pay was the base on which employer PF and gratuity liabilities got calculated. Loading the rest of the package into HRA, special allowance, and LTA was a legal and entirely deliberate way to keep those liabilities down. Under Section 2(y), that same structure now fails the 50% test by design, and failing it doesn't trigger a warning. It triggers an automatic reclassification.

What that means inside a payroll system

Most payroll and HRIS platforms still model CTC as a fixed list of components with a percentage split set once, usually at the company or role level, and rarely revisited per employee. The 50% rule breaks that model, because the test isn't structural. It's arithmetic, and it has to run per employee, not per template. Two people in the same role with different HRA, because they live in different cities, or different LTA entitlements, can land on opposite sides of the 50% line under an identical CTC template.

A payroll engine built for this needs three things the old one usually didn't: a classification flag on every pay component, a running per-employee sum of the exclusion bucket against total remuneration, and a recomputation path that flows any excess back into the wage base used for PF, gratuity, and bonus the moment the cap is breached. As a data shape, that looks closer to this than to a flat percentage split:

{
  "employee_id": "E10234",
  "ctc_annual": 1800000,
  "components": [
    { "name": "basic_pay",         "category": "wage",      "amount": 540000 },
    { "name": "dearness_allowance","category": "wage",      "amount": 0 },
    { "name": "hra",               "category": "exclusion", "amount": 270000 },
    { "name": "special_allowance", "category": "exclusion", "amount": 720000 },
    { "name": "employer_pf",       "category": "exclusion", "amount": 64800 },
    { "name": "lta",               "category": "exclusion", "amount": 90000 }
  ],
  "exclusion_total": 1144800,
  "exclusion_cap": 900000,
  "excess_reclassified_as_wages": 244800
}

That last field is the one most existing systems can't produce, because it never needed to exist before. Hard-coding "PF is 12% of basic" stops being correct unless basic is recalculated against the cap first, for every employee, every time a component changes.

The two-day settlement clock doesn't cover what HR thinks it covers

Section 17(2) of the Code on Wages requires that wages payable on removal, dismissal, retrenchment, resignation, or closure of the establishment be paid within two working days of exit. That's a sharp change from the 30-to-45-day window that was standard practice at most Indian employers, and in some states the legal norm under old Shops and Establishments rules.

The two-day clock attaches to "wages" exactly as Section 2(y) defines the term: earned salary up to the last working day. It doesn't automatically extend to everything HR usually bundles into "full and final settlement." Gratuity runs on its own payment timeline under the Code on Social Security. Provident fund withdrawal is processed through EPFO's own system and schedule, separate from the employer's payroll run entirely. Leave encashment is frequently a matter of company policy rather than any statutory clock at all.

That distinction matters operationally, not just legally. An HR team that promises a departing employee "F&F in two days," meaning the entire package, is committing to something the law doesn't actually require for most of what sits inside that package. A payroll system that batches the whole settlement into one job on one deadline either over-promises to the employee, or rushes the gratuity and PF calculations to hit a target that was never the statutory requirement for those components in the first place.

Gratuity at one year, not five

Section 53 of the Code on Social Security makes fixed-term employees eligible for gratuity, on a pro-rata basis, after one year of continuous service. Under the Payment of Gratuity Act, 1972, which the Code replaces, that threshold was five years, and it applied mainly to employees treated as permanent: a status most fixed-term hires never reached, by design.

That's a quiet change with a real liability shift for any company that leans on project-based, fixed-term, or contract-to-hire staffing, a hiring pattern common across IT services firms and global capability centres. Headcount that previously generated no gratuity exposure at all now starts accruing it after twelve months, and most actuarial gratuity valuations performed before the Code took effect won't have modelled that population.

There's a genuine unsettled edge here worth naming rather than smoothing over. Some legal commentary still treats parts of the Social Security Code's gratuity mechanics as not fully operative everywhere, on the basis that the old Payment of Gratuity Act continues to apply until matching state-level notification catches up. That ambiguity is itself a symptom of the bigger structural problem with this rollout.

It isn't one compliance regime. It's whichever state you're standing in

Labour sits on the Concurrent List of the Indian Constitution, which means central legislation needs matching state rules before its procedural mechanics are fully enforceable within that state. The four labour codes are central Acts, in force nationally since November 2025, but the rules that make them operable in practice are a state-by-state rollout, and as of mid-2026 that rollout is uneven.

For a single-state employer, that's a research problem: know your state's status, comply accordingly. For a multi-state employer, which is most companies past a certain size, it's a configuration problem. A payroll system that treats "labour code compliant" as one toggle is wrong by construction, because the actual obligation differs by registered establishment location, and that map will keep changing through the rest of 2026 as more states notify.

What to change before the next pay cycle

None of this resolves with a memo. It resolves with specific changes to how a payroll or HRIS system models compensation and exits:

• Re-run every CTC template against the Section 2(y) wage and exclusion split per employee, not per role. The 50% cap bites hardest on individual outliers, such as high HRA or relocation allowances, that a role-level template won't catch.
• Split the settlement process by component and give each one its own service-level target: wages within two working days, gratuity and PF on their existing statutory timelines, leave encashment per policy, and say so explicitly to departing employees instead of quoting one number for the whole package.
• Update gratuity accrual logic to pick up fixed-term employees past twelve months of continuous service, even where the HRIS still files them separately from permanent staff.
• Build a state-by-state compliance map instead of a single flag, with a named owner responsible for updating it as more states notify final rules.
• Log how each pay component gets classified, wage or exclusion, at the point of calculation rather than at year-end. Retroactive reclassification is a present risk, and the only way to size it without guessing is to have already recorded the basis for every calculation it touches.

The codes aren't finished moving. More states will notify rules through the rest of 2026, and the Ministry of Labour and Employment has already issued two rounds of clarificatory FAQs since the central rules landed in May, a sign it expects to issue more. Building the wage and exit logic as configuration that can absorb the next clarification, rather than as a one-time migration that's now complete, is what separates a payroll system that survives this year from one that needs rebuilding again in six months.