How to Integrate Payroll with Your HRIS: A Technical Guide
7/8/2026
Payroll and HRIS integrations fail in a characteristic way: they work correctly for months, then break silently. Nobody notices because the payroll still runs — it simply runs on data that stopped updating.
That failure mode determines everything about how an integration should be designed. The technical work of moving fields between systems is straightforward. The discipline that makes it reliable is deciding what owns what, and detecting when the flow stops.
Decide System of Record First
Before any technical design, settle which system owns each field. Every integration problem that is not a connectivity problem is an ownership ambiguity.
A workable default allocation:
HRIS owns: employee identity and demographics, job title and department, reporting relationships, employment status and dates, work location, compensation rate and effective date, benefit elections, and leave balances where leave is administered there.
Payroll owns: tax withholding elections, deduction amounts and arrears, garnishment orders and balances, year-to-date figures, payment method and bank details, and pay statement history.
Timekeeping owns: hours, approvals, and schedule data.
Two rules that prevent most trouble:
One writer per field. If both systems can change an employee's pay rate, they will disagree, and the last write wins arbitrarily. Make the non-owning system read-only for that field, enforced technically rather than by policy.
Bank details should be payroll-owned and manually verified. Do not accept bank changes through an integration that does not include verification, and never through one that accepts an emailed request upstream. This is the payroll diversion attack path. See our payroll data security guide.
What Actually Flows
HRIS to payroll:
- New hires, with work location and start date
- Terminations, with the separation date and reason category
- Rate changes, with effective dates
- Status changes — full-time to part-time, exempt to non-exempt, transfers
- Work state and location changes
- Benefit elections and contribution amounts
- Leave status
Payroll to HRIS:
- Actual earnings and taxes, for reporting
- Accrual balances, where payroll calculates them
- Deduction confirmations
Payroll outbound to others:
- Retirement deferrals and loan repayments to the recordkeeper
- Benefit contributions to carriers
- Garnishment remittances
- General ledger entries to finance
- New hire reports to state registries
Note that several of those outbound flows carry compliance deadlines. Retirement deferral transmission in particular is a fiduciary matter — deferrals are plan assets, and holding them longer than administratively feasible is a prohibited transaction under ERISA rather than a late payment. See our 401(k) plan administration guide.
Integration Patterns
File-based batch. A scheduled export and import, typically daily or per cycle. Simple, well-understood, and easy to audit because the file is inspectable. Weaknesses: latency, and it fails silently — a job that stops running produces no error anyone sees.
API-based, scheduled. Cleaner than files, with better error handling. Still batch in effect.
API-based, event-driven. A change in the HRIS immediately pushes to payroll. Best latency, most complex, and requires careful handling of ordering and retries — a rate change arriving before the hire record creates an orphan.
Middleware or an integration platform. Sits between systems, handling transformation, error handling, and monitoring. Adds cost and another component to maintain, and is usually worth it when more than two or three systems must exchange data.
Manual export and import. Legitimate at low volume. Its weakness is not the labor — it is that nobody notices when a step is skipped.
For most organizations, file-based or scheduled-API batch with real monitoring beats event-driven without monitoring. The monitoring matters more than the pattern.
The Failure Modes
Each of these has caused a payroll error at a real employer.
The job stopped and nobody knew. The single most common failure. Payroll continues to run on stale data — new hires missing, terminations still being paid, rate changes not applied. Detected weeks later by an employee complaint.
Effective dates ignored. A rate change effective the 15th applied to the whole period, or applied from the transmission date rather than the effective date. Produces under- or overpayment, and for a non-exempt employee also affects the regular rate and therefore overtime.
Terminations that did not transmit. The employee continues to be paid. Beyond the overpayment — which is difficult to recover, since most states require fresh written authorization — this also consumes the COBRA notification window, which runs from the qualifying event. See our COBRA administration guide.
State changes treated as address changes. A move across a state line is a compliance event requiring withholding registration, unemployment account, new hire reporting, and paid leave enrollment — not a mailing update. An integration that syncs address without flagging the state change hides it. See our multi-state payroll tax guide.
Duplicate records. A rehire created as a new employee rather than matched to the existing record. Splits year-to-date figures, restarting wage bases and deferral limits and producing over-withholding plus two Forms W-2.
Benefit elections without deduction mapping. The election arrives, the deduction code is created by copying an existing one, and it inherits the wrong tax-base flags. This is the most consequential integration error, because it produces a Form W-2 that will not reconcile. See our pre-tax vs. post-tax deductions guide.
Partial transmission. Half a file processed, no error raised.
Silent field truncation. A name or address longer than the target field, quietly cut. Surfaces at year-end as a Social Security Administration name mismatch.
Testing Before Production
Test the exceptions, not the straightforward cases.
- A new hire with a mid-period start date
- A termination with a mid-period separation date
- A rehire — confirm it matches the existing record
- A rate change with a retroactive effective date
- A rate change with a future effective date
- An employee changing work state
- An employee changing from non-exempt to exempt, and the reverse
- A benefit election change, confirming the deduction maps to all four tax bases correctly
- An employee with a garnishment, confirming the integration does not disturb it
- A name containing a hyphen, apostrophe, or suffix
- An address at the maximum field length
- A deliberately malformed record — confirm it errors visibly rather than passing silently
That last test is the one most often skipped and most valuable. An integration that fails loudly is manageable. One that fails quietly is the problem.
Monitoring Is the Deliverable
An integration without monitoring is not finished. Minimum:
Success and failure alerts on every run, including a no-data alert. A job that runs and transfers zero records is the silent failure — it succeeded technically and moved nothing.
Record counts compared between source and target each run.
An error queue that a named person reviews, with a defined response time. An error log nobody reads is not monitoring.
A reconciliation report: active employees in the HRIS versus active employees in payroll. Run it monthly. This single comparison catches missed hires, missed terminations, and duplicate records — the three highest-impact failures.
Alerting to a person, not a shared mailbox nobody watches.
Documentation and Change Control
Document the field map — every field, its owner, direction of flow, transformation applied, and target. When something is wrong, this is what makes it diagnosable.
Document the schedule and what depends on it.
Treat either system's upgrade as an integration risk. A version change on either side can alter field definitions, formats, or API behavior. Test the integration after any upgrade on either system, not just after changes to the integration itself.
Name an owner. Integrations decay because they belong to nobody — the person who built it has moved on, and nobody else understands it well enough to notice it stopped.
See our Best Practices For Payroll Policies And Procedures session and The Payroll Operations Procedures Manual.
Retrofitting Monitoring Onto an Existing Integration
Most payroll professionals inherit an integration rather than build one, typically with no documentation and no monitoring. Adding both without a project budget is achievable in a few steps.
Step 1: Reconcile the two systems once, manually. Export active employees from the HRIS and from payroll and compare them. This immediately tells you whether the integration is currently working, and the discrepancies are your first findings — missed hires, terminations still active, and duplicate records.
Step 2: Make that comparison monthly. It requires no vendor involvement and no development. This one recurring comparison catches the three highest-impact failures and is the single most valuable thing you can add.
Step 3: Find out whether anyone is alerted on failure. Ask who receives the notification and confirm that the address is monitored. A surprising number of integrations alert to a mailbox belonging to someone who has left.
Step 4: Ask specifically about a no-data alert. A job that runs and moves zero records has failed silently. If the current monitoring only reports errors, a stopped source produces a successful run with nothing in it — the exact failure mode that goes undetected for weeks.
Step 5: Reconstruct the field map from observation. Change one field in the HRIS, run the integration, and see what arrives in payroll. Tedious for a wide integration, and it produces the documentation nobody wrote. Prioritize the fields that matter: rate, effective date, work state, exempt status, and termination date.
Step 6: Test the exceptions listed above against the live integration in a controlled way — a future-dated rate change, a work state change, a rehire. You will find at least one behavior nobody documented.
Step 7: Name yourself or someone else as owner, in writing. Integrations decay because they belong to nobody.
None of this requires a vendor engagement, and steps 1 and 2 alone materially reduce your exposure.
Frequently Asked Questions
What should flow from an HRIS to payroll?
New hires with work location and start date, terminations with separation date, rate changes with effective dates, status changes including exempt classification and work state, benefit elections with contribution amounts, and leave status. Payroll should retain ownership of tax elections, deduction amounts and arrears, garnishment orders, year-to-date figures, and bank details — with bank changes manually verified rather than accepted through an integration.
What is the most common payroll integration failure?
The job stops running and nobody notices. Payroll continues to process on stale data — new hires missing, terminated employees still being paid, rate changes unapplied — and the problem surfaces weeks later through an employee complaint. This is why a no-data alert matters as much as a failure alert: a job that runs successfully and transfers zero records has failed silently.
How do you decide which system owns a field?
Assign one writer per field and enforce it technically rather than by policy. If both systems can change an employee's pay rate, they will eventually disagree and the last write wins arbitrarily. Make the non-owning system read-only for that field. Ownership ambiguity, rather than connectivity, is the source of nearly every non-technical integration problem.
Why is a termination that fails to transmit so serious?
Because it causes three problems at once. The employee continues to be paid, creating an overpayment that is difficult to recover since most states require fresh written authorization for recovery. Benefit deductions continue incorrectly. And the COBRA notification window — which runs from the qualifying event rather than from when payroll learns of it — is consumed before anyone can act, with notice-failure penalties accruing per day per qualified beneficiary.
What should be tested before an integration goes live?
The exceptions rather than the routine cases: mid-period starts and terminations, a rehire matching an existing record, retroactive and future-dated rate changes, a work state change, exempt status changes in both directions, a benefit election confirming the deduction maps correctly to all four tax bases, an employee with a garnishment, names with hyphens and suffixes, maximum-length addresses, and a deliberately malformed record to confirm it errors visibly rather than passing silently.
What monitoring does a payroll integration need?
Success and failure alerts on every run plus a no-data alert; record counts compared between source and target; an error queue reviewed by a named person within a defined time; and a monthly reconciliation comparing active employees in the HRIS against active employees in payroll. That last comparison alone catches missed hires, missed terminations, and duplicate records — the three highest-impact failures.
Going Deeper
Integrations decay silently and break after upgrades on either side. Document the field map and its ownership, name an owner, alert on no-data as well as on failure, and test the integration after any version change on either system.
