Every CFO knows what their HR software costs, because the invoices arrive monthly and land in a budget line with a name. That number is real, auditable, and — in most mid-market companies running four or more people systems — somewhere around half of what the stack actually costs.
The other half is distributed. It sits in the hours a payroll executive spends each month matching an attendance export against a headcount list. It sits in corrections made after a pay run because a mid-month salary revision was updated in one system and not another. It sits in the engineering or vendor time that keeps a data feed alive through an API change. None of it appears under a heading called software, so none of it is ever weighed against the software decision that produced it.
This is a model for pricing that second half. It is deliberately structured so you can populate it from your own records rather than from anyone's benchmark, because — as we will explain — a usable published benchmark for most of these layers does not exist.
| Average HR modules per organisation, 2024 | 26 (Sapient Insights) |
| The same figure in 2020 | 10 |
| Payrolls containing at least one error | ~20% (EY, 2022) |
| Corrections per pay period, average org | 15 |
| Time fixing common errors, per 1,000 staff | ~29 working weeks a year |
| Usable published benchmark for integration cost | None — see below |
Sprawl is the baseline condition, not the exception
The Sapient Insights Group HR Systems Survey — a non-sponsored study now in its 28th year, drawing on nearly 10,000 HR professionals across 4,670 organisations — found that organisations were operating an average of 26 HR modules in 2024, against 10 in 2020. A separate 2025 industry survey puts the figure closer to 16 HR and recruiting applications, with 68% of them on disconnected platforms.
Those two numbers are not in conflict so much as measuring different objects: a module is a functional capability, an application is a login. Both point the same direction. If you are running five or six separate people systems and feel behind, you are not — you are typical, and the trend is towards more, not fewer.
Adjacent findings sharpen the picture. Research cited by SHRM found that more than 60% of software applications in one SaaS benchmark were inactive while still being paid for, that only 28% of HR functions had ever formally retired software they no longer use, and that 68% of respondents said decommissioning a redundant system takes at least four months. Stacks accrete. They very rarely shed.
The seven layers
A complete TCO model has seven components. The first two are on an invoice. The rest are real money that has never been counted against the systems that generate it.
| # | Layer | Visible? | How to source your own number |
|---|---|---|---|
| 1 | Subscription and licence fees | On the invoice | Sum annual contract value across every people system, including per-seat add-ons and the modules nobody uses |
| 2 | Implementation and configuration | On an invoice, once | One-off cost, amortised across the expected life of the system |
| 3 | Integration build | Partly | Middleware licences plus engineering or vendor days per connection |
| 4 | Integration maintenance | Invisible | Hours per month keeping feeds alive through API and schema changes |
| 5 | Reconciliation labour | Invisible | Hours per cycle matching records across systems before a pay run, a report, or an audit |
| 6 | Error correction | Invisible | Corrections per pay period multiplied by the loaded cost of investigating and fixing one |
| 7 | Decision latency | Unmeasurable | The cost of questions not asked because assembling the answer takes a fortnight |
Layer seven is genuinely unmeasurable and we make no attempt to price it. We mention it because it is often the layer that actually motivates a change, and it is more honest to name it as unquantified than to invent a figure for it.
Why we will not give you an integration benchmark
We looked for one. Published estimates for the cost of building a single moderately complex SaaS integration currently range from about $2,000 to over $300,000, with annual maintenance quoted variously at 10–20%, 15–25%, and 20–35% of build cost. The spread is not the problem. The provenance is.
The one layer with real research behind it
Payroll error correction is the exception. Ernst & Young surveyed 508 payroll practitioners at US organisations of 250 to 10,000 employees and found that roughly one payroll in five contains an error, that the average organisation makes 15 corrections per pay period, and that the average error costs $291 to fix — $281 in direct labour and about $10 indirect. Aggregated, the most common error categories cost around $250,000 per 1,000 employees a year and consume roughly 29 working weeks of time. About one company in six reported legal or compliance issues arising from inaccurate payroll.
Three caveats, all of which matter:
The study was commissioned by a payroll software vendor. That does not make it wrong — the methodology is disclosed and the sample is reasonable — but it does mean the framing was chosen by a party with an interest in the answer.
The aggregate figures conflict across secondary reporting. The $250,000-per-1,000-employees figure is the one in EY's own summary tables. At least one secondary source cites the same research for a figure above $900,000 per 1,000 employees. We use the lower, primary-sourced number.
It is US data from 2022. The dollar cost per error reflects US labour rates. Applying it directly to an Indian payroll team overstates the cost per correction substantially; applying an India-adjusted rate is an assumption, and we flag it as one in the worked example below.
What survives all three caveats is the structural finding, which is the useful part: errors cluster around data that has to move between systems — time punches, employees not set up in time, status changes not propagated. Those are integration failures wearing a payroll costume.
A worked example: 400 employees, five systems
A mid-market company with 400 employees runs an HRMS, a separate payroll system, an ATS, a performance tool, and a cap-table or ESOP system. Every figure below is an assumption, chosen to be plausible for an Indian mid-market company; none is a benchmark. Replace all of them.
| Layer | Assumption | Annual cost |
|---|---|---|
| Licences, five systems | Blended across core and point tools | ₹18,00,000 |
| Reconciliation labour | 6 handoffs × 8 hrs/month × ₹1,200/hr loaded | ₹6,91,200 |
| Error correction | 12 corrections/run × 12 runs × ₹6,000 each | ₹8,64,000 |
| Integration upkeep | Middleware plus vendor and internal time | ₹4,00,000 |
| Total, year one | ₹37,55,200 |
The ₹6,000 per-correction figure is EY's $291 scaled down for Indian loaded labour rates. It is an estimate, not a survey finding. The ₹1,200 hourly rate assumes a fully loaded mid-level finance or HR operations salary.
On these assumptions, the licence line is 48% of the total. The half that never gets compared during a software decision is slightly larger than the half that does.
Against a consolidated stack
Now the comparison. A single system carrying the same functions removes the integration layer entirely and compresses reconciliation, because the records are already joined. It does not remove either cost to zero, and it introduces a migration cost that the fragmented option does not carry.
| Layer | Fragmented | Consolidated |
|---|---|---|
| Licences | ₹18,00,000 | ₹14,40,000 |
| Reconciliation labour | ₹6,91,200 | ₹57,600 |
| Error correction | ₹8,64,000 | ₹4,32,000 |
| Integration upkeep | ₹4,00,000 | Nil |
| Migration, one-off | Nil | ₹6,00,000 |
| Three-year total | ₹1,12,65,600 | ₹63,88,800 |
Assumes the same headcount and no price escalation across three years, which is unrealistic in both columns and roughly cancels out. The halving of error correction is an assumption, not a measured outcome — it reflects the EY finding that errors concentrate in cross-system data movement, but no study we found isolates the effect of consolidation specifically.
What consolidation does not save
We sell a consolidated system, so this section carries more weight than the rest of the article. Anyone presenting a TCO case to a board should expect these to be raised, and should raise them first.
Migration is expensive and routinely underestimated. Historical payroll data, part-year tax positions, leave balances, in-flight requisitions and vesting schedules all have to move correctly. Migration cost scales with how bad your existing data is, which is exactly what you cannot assess until you start. The ₹6,00,000 above is a placeholder; treat a figure two to three times higher as entirely possible.
Point tools are usually better at their point. A dedicated recruiting platform will out-feature the ATS module inside a suite, and a specialist engagement tool will out-feature an embedded survey. Consolidation trades depth for coherence. If the depth is load-bearing for a particular team, that team will experience the change as a downgrade — and they will be right.
Concentration risk is real. One vendor holding hiring, HR, payroll and equity data is a single point of commercial and operational failure. Diligence on financial stability, data portability, exit terms and export formats matters more, not less, in a consolidated architecture.
Reconciliation labour rarely converts to cash. Saving 500 hours a year does not produce ₹6,00,000 unless you reduce headcount or those hours displace other work of equivalent value. Presenting freed capacity as hard savings is the fastest way to lose a CFO's confidence. Present it as capacity, and let finance decide what it is worth.
Change costs are absent from every model, including this one. Retraining, temporary productivity dips, and the parallel-run period where you pay for both stacks are real and unmodelled here.
Running this in your own organisation
Five steps, in order:
One — list every people system and its annual contract value. Include the ones procurement forgot: the survey tool, the background verification portal, the spreadsheet-with-macros somebody maintains. Expect the list to be longer than you assumed.
Two — map the handoffs, not the systems. A handoff is any point where data leaves one system and enters another, by API or by human. Count both. The human ones cost more.
Three — time one cycle honestly. Ask the person who actually does the month-end reconciliation to log their hours for one cycle. Do not estimate this from the top down; the estimate will be low by a factor of two or more.
Four — count corrections for three pay runs. Not errors that reached employees — every correction, including the ones caught before disbursement. That is your layer-six frequency.
Five — price migration before you price savings. If the migration number is unknowable, say so in the paper. A board will forgive an honest unknown far more readily than a confident figure that turns out to be wrong.
Where the architecture actually matters
The layers this model prices — reconciliation, error correction, integration upkeep — all originate from the same root cause: the same fact stored in more than one place, with a process responsible for keeping the copies in agreement. Integration does not remove that condition. It automates the agreement process and adds a component that can fail.
Helion's design bet is to remove the condition rather than manage it: hiring, HR, payroll, equity and accounting share one PostgreSQL database, so an offer accepted in the ATS and the resulting employment record and first payslip are the same data rather than three copies that must be made to match. Whether that bet is worth a migration for your organisation is exactly what the model above is for — and if the numbers do not support it, they do not support it.
Frequently asked questions
How many HR systems is too many?
There is no threshold. The question that matters is how many handoffs the systems create and how much manual effort each one consumes. Six systems with clean automated feeds can cost less to run than three joined by spreadsheets.
Should implementation cost be in TCO or treated as capex?
Include it, amortised over the realistic life of the system rather than the contract term. Excluding it makes every switch look cheaper than it is, which biases the analysis towards change.
Is the EY payroll error data applicable in India?
The frequency findings — roughly one payroll in five affected, about 15 corrections per period — are more transferable than the cost findings, which reflect US labour rates. Substitute your own loaded hourly cost and your own correction count.
Our reconciliation is done by existing staff, so it costs nothing extra. Is that fair?
It is fair as a cash argument and wrong as an economic one. Those hours have an opportunity cost even when the salary is already committed. The honest presentation is to show the hours and their notional value separately from cash savings, and let finance decide which to bank.
What is the single biggest source of error in this model?
Migration cost, by a wide margin. Every other input can be measured from records you already have. Migration is a forecast, and forecasts about data quality are usually optimistic.
All monetary figures in the worked examples are assumptions selected for illustration and are not benchmarks, survey findings, or Helion pricing. Payroll error frequency and cost data are from a 2022 Ernst & Young study of 508 US organisations of 250 to 10,000 employees, commissioned by a payroll software vendor; secondary reporting of that study's aggregate figures is inconsistent and we have used the lower, primary-sourced number. HR module counts are from the Sapient Insights Group HR Systems Survey; application counts and disconnection rates are from secondary reporting of separate industry surveys. Published integration cost figures are vendor-produced and are cited only to demonstrate their unusable spread. Helion sells a consolidated platform and therefore has a commercial interest in the conclusion of this analysis; the model is provided so you can test it against your own data. Current as at July 2026. General information, not financial advice.