How payroll and your HR system should fit together

Payroll is where HR software buying decisions most often go wrong, because the marketing language hides a genuine and important distinction. A system that "handles payroll" might mean it calculates net pay and files statutory returns in your jurisdiction, or it might mean it produces a file you import somewhere else. Those are very different products and the difference only becomes visible after you have signed.

Understanding the boundary makes the buying decision straightforward.

The two halves of payroll

Everything before the calculation is workforce data: who is employed, on what terms, at what rate, who worked which hours, what leave was taken, what allowances and deductions apply, and for shift-based staff how raw hours interpret into paid categories under the relevant rules.

The calculation and what follows is gross to net: applying tax, social contributions, pension or superannuation and statutory deductions, producing payslips, making the payments and filing returns with the revenue authority.

The first half is HR work and belongs in an HR system, because that is where the employment data lives. The second half is payroll engine work: jurisdiction-specific, heavily regulated, and changing whenever legislation changes.

Almost all the value of integration is in moving the first half to the second accurately, automatically and on time.

Why the second half is harder than it looks

Payroll engines look like arithmetic and are not. They are a continuously maintained implementation of a specific jurisdiction's tax and employment law, including the annual changes, the thresholds, the statutory reporting formats and the electronic filing protocols.

Australia has Single Touch Payroll with defined reporting obligations at each pay event. The UK has Real Time Information submissions to HMRC. Every jurisdiction has its own equivalent, its own schedule and its own penalties.

This is why credible payroll providers are specialists, and why "global payroll" from a general HR vendor usually means a patchwork of local partners with varying depth. That is not necessarily a problem, but you should know it is the architecture rather than discovering it later.

What to ask a vendor claiming to do payroll

Four questions that resolve the ambiguity quickly.

"Which jurisdictions do you calculate and file in yourselves, rather than through a partner?" The list is usually much shorter than the marketing map.

"Do you submit statutory returns directly?" Producing a file for someone else to submit is not the same as filing.

"Who is responsible if a filing is late or incorrect?" The answer tells you what they actually believe they are providing.

"How quickly are legislative changes implemented, and how do we know they have been?" Payroll compliance is a maintenance commitment, not a feature.

If the answers are vague, the product is a payroll data exporter rather than a payroll engine, and you should evaluate it as one.

The connector approach

The alternative architecture: the HR system owns the workforce data and the interpretation of hours, then passes the result to whichever payroll engine you already use.

HRM8 is built this way deliberately. It is connector-only on payroll. HRM8 owns time capture and the interpretation of pay rules into hours by category, then hands interpreted hours and gross-by-category to your payroll provider, which does gross-to-net and the statutory filing. HRM8 does not run payroll, resell payroll or file returns.

The reasoning is straightforward. Payroll is unforgiving and jurisdictionally specific, and the providers who do it well have invested years in each market. Building a shallow version of that and calling it all-in-one serves the vendor rather than the customer.

The practical consequences for a buyer:

You keep your payroll provider, and your accountant keeps working the way they do.

You do not re-key data. New starters, terminations, pay changes, hours and leave flow through from the employee record.

The interpretation problem is solved where it belongs. For shift-based and award-covered workforces, the hard part is not net pay, it is establishing correct paid hours in the first place. That is workforce data work, and it is where most underpayment originates.

Switching payroll providers does not mean switching HR systems, and vice versa.

HRM8 prices the payroll connector at US$795 per year per connection plus a US$2 per employee per month uplift. The annual fee covers the provider API, monitoring and support. Other connected systems, such as time and attendance, workforce management or accounting feeds, are US$39 per system per month plus setup. Full detail is on the pricing page.

Getting the integration right

Agree which system owns which field. The most common integration failure is two systems both believing they own the pay rate. Decide, document it, and make the other system read-only for that field.

Decide the direction of flow. Usually HR to payroll for employee and hours data, and sometimes payroll back to HR for payslip availability. Bidirectional sync on the same field is where conflicts originate.

Test with a parallel run. Run both the old and new process for a full cycle and reconcile. Every discrepancy is either a configuration error or a rule you had not written down, and both are much cheaper to find in parallel than in production.

Test the edge cases specifically: a mid-period starter, a mid-period leaver, a pay rise part way through a period, someone on unpaid leave, a termination with accrued leave payout. Standard cases work in every system. Edge cases are where integrations break.

Know who fixes a failed sync. Payroll runs to a fixed date. A sync that fails silently on the wrong day is a real problem, so there should be alerting and a named owner.

Common questions