HRMS and Payroll Software Cost: The Year the Definition of Wages Changed

Leave and attendance is a calendar. Onboarding is a form. Both are quoted at length in every HRMS proposal you will read, and neither is why payroll builds fail.

Payroll fails on one question: what counts as wages. On 21 November 2025 India brought all four Labour Codes into force, rationalising 29 existing laws, and the Code on Wages replaced a scatter of different definitions with a single one used for minimum wages, bonus, gratuity and provident fund alike. Attached to it is a cap: where the allowances you have excluded from wages exceed 50% of total remuneration, the excess is deemed to be wages anyway.

Read that as an engineering statement and the consequence is immediate. The wage base is a computed value, not a stored one. It depends on the whole remuneration structure, it is evaluated per employee per period, and a payroll system that keeps a basic_salary column and multiplies by 12% cannot produce a correct number. Restructuring a salary from 30% basic to 50% basic raises the provident fund base by 66.7%, and that is the same employee on the same cost to company.

It gets worse, in a way that is genuinely useful to know before you commission anything. As of today the market does not agree on what the EPF wage ceiling currently is. A Ministry notification dated 29 May 2026 is cited for ₹15,000 a month. Later sources report a rise to ₹25,000 from 17 September 2026. Both are published by people who do payroll for a living.

If the practitioners disagree about a parameter, your software cannot hard-code it. That single observation is worth more than any feature list, and it is the thing none of the agency blogs quoting ₹6 lakh to ₹45 lakh for an HRMS will tell you.

Three questions set what you pay. How many statutory regimes does the engine serve? Can every rate, ceiling and threshold carry an effective date? And does a historical payslip regenerate at the rules that applied when it was issued? Everything else (leave, attendance, onboarding, an org chart) is well-trodden work.

What the 50% rule actually does to the data model

The old approach stored the salary structure as fixed components and computed statutory deductions from named ones. Basic times a percentage, done. That model cannot express the new definition, because the new definition is circular in a way code has to resolve: what counts as wages depends on what proportion the exclusions represent, and the exclusions are defined relative to total remuneration.

So the engine has to evaluate, not look up. For each employee, for each pay period, it computes total remuneration, sums the excluded allowances, tests them against the 50% threshold, and where they exceed it, moves the excess into the wage base before any contribution is calculated. That is a rules evaluation with an ordering, and the order matters because the result of one step is the input to the next.

The reading of the rule is itself contested, which is a requirement rather than a footnote. Commentators divide on whether the 50% test is a cap on exclusions or a mandate that basic pay be roughly half of cost to company. They divide again on whether the employer's own provident fund contribution counts toward the 50%. A system built on one reading, hard-coded, has to be rewritten when the Ministry clarifies or a court decides. A system where the test is configuration survives both.

Gratuity moved with it. Anything outside the wage definition under the Code on Social Security does not count toward gratuity, so the same computed base drives a liability that accrues over years rather than months, and a change to the definition reaches backwards into an accrual you have already reported.

Rates, ceilings and thresholds are data with dates on them

Provident fund runs at 12% from the employee and 12% from the employer, with the employer share split between pension at 8.33% and provident fund at 3.67%. Employees' State Insurance runs at 3.25% employer and 0.75% employee, on a coverage threshold of ₹21,000 a month, or ₹25,000 for a person with a disability.

Every one of those numbers has changed at some point and will change again. The pension split is quoted from material published before the 2026 schemes and may not survive them. The provident fund ceiling is, as above, currently reported two different ways.

So store them as a table of values with effective-from and effective-to dates, never as constants, and make the payroll run resolve them by period rather than by current value. The test for whether you have built this correctly is simple and worth writing into your acceptance criteria: regenerate a payslip from eighteen months ago and confirm it reproduces exactly, to the rupee, including the rates that applied then.

Systems that fail that test fail it silently. Nobody regenerates old payslips until an employee disputes a gratuity figure, an auditor samples a year, or an employee leaves and the full-and-final settlement has to reconstruct the whole employment. By then the system has been quietly producing numbers that cannot be defended for however long it has been running.

This is also what makes multi-country payroll expensive, and why you should not buy it before you need it. Each country is a separate set of dated parameter tables, filing formats and deadlines, maintained forever. One country done properly beats three done approximately.

The filing layer is the recurring cost nobody quotes

Computing a deduction is the easy half. Reporting it in the format a government system will accept, by its deadline, is the half that never ends.

Provident fund wants an electronic challan return. Employees' State Insurance wants its own contribution file. Tax deducted at source wants quarterly returns with their own schema and a correction mechanism for when you get it wrong. Professional tax varies by state, with its own slabs, its own forms and its own dates. Labour welfare fund is another, in the states that have one.

These formats change on a government's schedule, not yours. A payroll product carries a permanent obligation to track and implement format changes, and that obligation does not shrink as the product matures. It is the single clearest argument for buying payroll rather than building it, and any honest vendor will tell you so.

Where building wins is when payroll is a component of a product you are selling, not a function you are running. If your platform pays gig workers, manages contractors, or runs payroll as a feature for your own customers, you are building a payroll engine whether you wanted to or not, and the dated-parameter architecture above is the whole game.

Full and final settlement is the system's hardest test

When someone leaves, payroll has to reconstruct their entire employment in one run, and everything weak in the architecture surfaces at once.

The settlement has to compute gratuity across years, at the wage definition that applied in each of them, which is precisely the dated-parameter problem and precisely where the November 2025 change bites. An employee who joined in 2021 and leaves in 2027 has service under two different definitions of the word their gratuity is calculated from.

It has to recover what the employee owes. Notice period shortfall, unreturned assets, a salary advance, an education bond, excess leave taken against a balance that had not accrued. Each is a deduction with its own rules and its own ceiling, and several are legally capped.

It has to settle leave encashment at the right rate, which is the wage definition again rather than gross pay, and it has to decide what happens to a balance that the policy says lapses but the statute says accrues.

It produces a document the employee will scrutinise more closely than any payslip, often with a lawyer, usually after the relationship has soured. A settlement that cannot show its working is a dispute.

Build settlement against a real leaver's data before launch, not after. It is the single best test of whether the engine is correct, because it exercises accruals, dated rates, recoveries and regeneration in one pass. Teams that defer it to phase two usually discover the parameter tables were wrong all along.

Attendance is where payroll meets reality, badly

Attendance looks like the simplest module and generates the most defects, because it is where a clean data model meets how people actually work.

The hard cases are not edge cases. A shift that crosses midnight belongs to which day. A night shift that crosses a month boundary belongs to which pay period. An employee who clocks in at a client site, on a phone, with no signal. A biometric device that was offline for four hours and uploads its records afterwards, out of order. A correction applied to a day that has already been paid.

That last one is the expensive one. Once a period is paid, an attendance correction cannot simply change the record, because the payslip derived from it has been issued and the statutory filings have been submitted. The correct behaviour is an adjustment in the next period with an audit trail back to the original, and teams that discover this after launch rebuild the module.

Overtime belongs here and is now statutory. The Labour Codes provide for double wages for overtime, which makes the attendance record a direct input to a legally defined payment rather than an internal metric. The precision of your clock-in data is now a compliance question.

Design the period close explicitly. There must be a moment where a period locks, after which nothing changes retrospectively and everything flows forward as an adjustment. Products without a defined close are the ones where last month's numbers quietly differ depending on when you ask.

Multi-entity and contractors break the simple model

Most companies that need an HRMS are not one legal entity paying one kind of worker, and the quote you receive almost always assumes they are.

An employee can move between entities mid-year. Their service for gratuity may or may not carry across depending on how the transfer was structured, their provident fund account follows them, and their tax computation has to combine both employments. A system that models employment as a single row per person cannot represent this.

Contractors are not employees and are not nothing. They sit outside provident fund and ESI, inside tax deducted at source under a different section at a different rate, and often inside your attendance and access systems. Modelling them as employees with flags set to false produces wrong statutory filings; modelling them as entirely separate produces two systems nobody reconciles.

Gig and platform workers are now defined in statute. The Code on Social Security defines gig and platform work for the first time and extends social security to categories previously outside formal labour regulation. If your product pays this category, the obligations are new, still settling, and worth a direct legal question rather than an assumption.

Decide the worker-type model before anything else is built. It is a schema decision with the same permanence as the parameter tables, and retrofitting a second worker type into a payroll engine means revisiting every calculation in it.

What is ordinary, and should cost ordinary money

Most of an HRMS is well-understood and should be priced near the floor of our published band of $40 to $100 an hour by role, blending to $60 to $70 for a mixed team.

Employee records, org chart, document storage, leave types and balances, approval workflows, expense claims, an employee self-service app, manager dashboards and a reporting layer are all routine. They are also where most of the screens are, which is why feature-count-based quotes mislead so badly on this product: the screens are cheap and the engine is not.

The two places to put senior time are the statutory engine described above and the permissions model. Human resources data is the most sensitive data a company holds about its own people, and the access rules are genuinely intricate: a manager sees their team's leave but not their salary, a finance user sees aggregate cost but not performance notes, an employee sees their own everything, and HR sees most things but every view is logged.

Build the audit log before you need it. Who viewed whose salary, and when, is a question that gets asked exactly once, usually under unpleasant circumstances, and it cannot be answered retrospectively.

The reports finance asks for, and the one they ask for last

Employees want payslips. Finance wants something else entirely, and it is usually scoped after launch.

The cost-to-company reconciliation is the report that matters. Finance needs payroll cost by cost centre, by department, by project, matching to the journal that posts to the general ledger, and it needs the total to tie exactly to what left the bank. A payroll product that cannot produce a balanced journal creates monthly manual work forever.

Accruals are a second model, not a report on the first. Gratuity, leave encashment and bonus accrue continuously and are paid occasionally, so the liability has to be computed and posted every period even though no money moves. Teams that treat accrual as a view over payment data get it wrong in both directions.

Statutory registers are their own obligation. The Codes require registers of wages, attendance and leave in prescribed forms, and "we can export a spreadsheet" is not the same thing as a register in the prescribed form.

The report they ask for last is the audit trail, and by then it either exists or it does not. Who changed a salary, who approved it, who viewed it, when, and what the value was before. It costs almost nothing as a design decision at the start and cannot be reconstructed afterwards.

How we would sequence it

The parameter tables come first, with dates on everything, before a single calculation is written. This is a schema decision and it takes days, and it is the only part of this product that cannot be corrected cheaply once payslips have been issued against it.

The wage-base evaluator second, with the 50% test as configuration rather than code, and with the contested readings implemented as switchable options rather than as a bet on which interpretation wins.

The period close third. Lock, adjust forward, never edit backwards. Everything downstream depends on this being decided rather than emerging.

Filing formats fourth, one regime at a time, each with a sample file validated against the government system before it is called done. "The report generates" is not the acceptance criterion. "The portal accepted it" is.

Then the screens, which is the opposite of the order most people want and the reason most payroll products have beautiful interfaces over engines that cannot regenerate last year.

We do not put a fixed total on a build like this before a discovery that establishes how many statutory regimes are in scope, whether payroll is a function you run or a product you sell, and how far back regeneration has to work. Those three answers change the engineering by a multiple. What we will tell you free is that if you only need payroll for your own staff in one country, you should almost certainly buy it.