A 600-employee manufacturer connected its time clock system to a new HRIS in March and considered the project finished. In July, payroll ran and 14 employees were paid at rates they had not earned since a January adjustment, four terminated employees still had active badge records, and one rehire appeared twice in the time system with hours split across both records. Nothing had failed loudly. The nightly sync had been running green the whole time, moving the fields it was configured to move and silently ignoring the ones nobody had mapped.

That is the ordinary shape of a broken integration. It does not throw errors, it drifts, and the drift surfaces in payroll where it is most expensive to explain. A time tracking HRIS integration is not a connector you switch on, it is a set of decisions about which system owns which field and what happens when a person’s situation changes mid-cycle. This covers those decisions, the difference between sign-on and provisioning, and the specific failure points that show up first.

Which System Owns the Employee Record?

The HRIS does, and the integration should be one-directional for everything the HRIS controls. Deciding this explicitly, in writing, before configuration is the single step that prevents most downstream mess, because the alternative is two systems that both think they are authoritative and a monthly argument about which number is right.

A clean ownership split usually looks like this. The HRIS owns identity, employment status, job, department, cost center, pay rate, FLSA classification, manager, and hire and termination dates. The time system owns schedules, punches, accrual balances where it calculates them, approvals, and the timecard itself. Payroll receives from both and originates nothing.

The friction cases are worth naming in advance:

• Accruals, which some organizations run in the HRIS and some in the time system, and which must run in exactly one place
• Schedules, which occasionally live in a workforce management module inside the HRIS and will collide with the time system if both are active
• Manager assignment, since the HRIS manager may not be the person who approves timecards on a shop floor, which means the time system needs an approver field separate from the HR reporting line
• Cost center, where the HRIS holds the employee’s home department but hours may be charged to several

Write the ownership map as a document and keep it with the integration configuration. When something breaks a year later, that document is what tells the next person whether a field was supposed to be overwritten.

What Employee Sync Should Transfer, Field by Field

More than most default configurations move, and the ones left out are the ones that cause the July surprise.

The fields a time system genuinely needs from the HRIS:

• A stable employee identifier that never changes, used as the join key
• Legal name and preferred name, plus display name if the clock shows one
• Employment status with effective date: active, on leave, terminated, suspended
• Hire date, rehire date, and termination date
• Job title, job code, department, cost center, and location
• FLSA classification, because exempt and non-exempt employees are treated differently for overtime
• Pay type and pay rate, where the time system calculates premiums or shows estimated pay
• Manager and, separately, timecard approver
• Union or bargaining unit where applicable, since contract rules often drive rounding, premiums and break rules
• Scheduled or standard hours, which drive benefits eligibility calculations and variance reporting

The join key deserves emphasis. Use the HRIS employee ID, never email address and never name. Email changes on marriage and on domain migrations, names change, and a sync keyed on either will eventually create a duplicate or update the wrong person. If your clock hardware needs a badge number, keep that as a separate attribute mapped to the employee ID rather than using it as the key, because badges get reissued.

Effective dating is the other half. A pay rate change entered on the 20th with an effective date of the 1st has to reach the time system as a dated change, not as a current value, or the retroactive period calculates at the wrong rate. Systems that only sync current values cannot handle this, and the workaround is manual adjustment every time, which is exactly the thing the integration was bought to eliminate.

SSO, SCIM, and Why They Are Not the Same Thing

These get conflated constantly and they solve different problems. Single sign-on, typically over SAML 2.0 or OpenID Connect, handles authentication. It answers whether the person at the keyboard is who they claim to be, and it lets them in without a separate password. Provisioning, typically over SCIM 2.0, handles account lifecycle. It answers whether an account should exist at all and what it should contain.

An organization with SSO but no provisioning has employees who can log in with their corporate credentials and accounts that nobody creates or removes on time. An organization with provisioning but no SSO has accurate account records and a separate password for everyone to forget.

Just-in-time provisioning sits between them, creating an account on first SSO login from the attributes in the authentication assertion. It is better than nothing and it has a specific weakness: it only creates and updates on login, so it never removes anyone and it never updates someone who has not logged in. For a time system where hourly staff punch at a shared clock rather than logging into a web app, just-in-time provisioning barely functions at all.

What to configure, in order of priority:

• SCIM provisioning from the identity provider or HRIS for create, update, and deactivate, so accounts follow employment status
• SSO for anyone who logs into the application, meaning managers, administrators, and salaried staff
• Clock or kiosk authentication separately, since badge, PIN, or biometric at a shared device is not an SSO flow and should not be forced into one
• Deprovisioning tested explicitly, because an orphaned account with timecard access is a security finding and a payroll risk at once

One caution on SSO and hourly workers. If a non-exempt employee cannot reach their timecard because of an authentication problem, they still worked those hours and you still owe them. Keep a documented fallback path that does not depend on the identity provider being up.

What Breaks First: Terminations, Rehires, and Mid-Cycle Changes

Terminations break first, and they break in two directions. A termination that syncs too fast locks the employee out of a timecard that has not been approved yet, leaving unapproved hours in a closed period. A termination that syncs too slowly leaves an active record that can still punch, and in a facility with badge access that is a physical security problem rather than a data problem.

The fix is a two-stage model. On termination, immediately revoke the ability to punch and to authenticate, while keeping the record active for timecard completion and approval through the end of the pay period, then deactivate. Final pay timing is governed by state law and several states require payment very quickly after an involuntary termination, which means the final timecard has to be closable the same day. Build that path and test it rather than discovering it during someone’s last shift.

Rehires are the second failure. If your HRIS issues a new employee ID on rehire, the time system gets a second record for the same human and year-to-date figures, accrual history and benefits eligibility hours fragment across both. If the HRIS reuses the original ID, the time system may reject the create as a duplicate or silently reactivate a record carrying stale schedule and department data. Decide which pattern your HRIS uses, configure the time system to match, and test a rehire in the sandbox before the first real one.

Mid-cycle changes are the quiet one. A transfer between departments on a Wednesday, a promotion from non-exempt to exempt mid-week, a pay rate change effective last Monday, a move from full-time to part-time. Each of these needs to apply from its effective date, not from the sync date, and an exempt status change mid-week raises a real wage and hour question about how that week’s overtime is handled. Have payroll and employment counsel establish the rule once and encode it.

Leaves of absence belong in this group too. A person on an approved leave is not terminated and should not be deactivated, but they also should not be generating missed-punch exceptions every day for twelve weeks. The status needs to flow through with enough fidelity that the time system suppresses attendance exceptions while keeping the record intact.

API, File Transfer, or Middleware?

Three integration patterns, each appropriate in different situations, and the right choice depends more on your IT capacity than on which is technically superior.

A direct API integration between the two systems, where one vendor has built and maintains a connector for the other, is the best outcome when it exists. Real-time or near-real-time updates, field mapping handled in a configuration screen, and support from a vendor who owns the connection. Ask specifically whether the connector handles effective-dated changes, deactivation, and rehire, because many prebuilt connectors handle creates and updates well and the lifecycle edges poorly.

Scheduled file transfer, usually a delimited file dropped on an SFTP server nightly, remains extremely common and works fine for organizations whose data does not change hourly. It is predictable, auditable, and easy to reprocess. The requirements are a defined file specification, encryption in transit and ideally at rest, a failure alert when a file does not arrive, and a rule for whether the file is a full snapshot or a change-only delta. Full snapshots are safer because they self-correct drift; deltas are faster and accumulate errors.

Middleware or an integration platform sits in the middle and is worth it when you have more than two systems to connect or when the transformation logic is complex. It also adds a vendor, a cost, and a place for the integration to be broken by someone who does not work in HR or IT.

Whichever pattern you use, insist on idempotency, meaning that processing the same record twice produces the same result rather than a duplicate. Reruns happen, and an integration that cannot tolerate one will eventually double someone’s record on a day when the first run half-failed.

Testing the Integration Before It Touches Payroll

Parallel run, two full pay cycles minimum, with the old process still running and the outputs compared line by line. Organizations that skip this because the sandbox tests passed are the ones who find the problems in a live payroll.

The test cases that matter, each run deliberately rather than hoped for:

• A new hire mid-pay-period, including someone who starts on the last day of the period
• A termination mid-period with unapproved hours outstanding
• A rehire of someone previously terminated
• A retroactive pay rate change with an effective date in a closed period
• A department or cost center transfer mid-week
• A non-exempt to exempt classification change
• An employee on leave for a full pay period
• A name change
• A manager change where timecard approvals are pending with the old manager
• The same file or payload processed twice

Compare total hours, total by department, total by pay code, and headcount between the two systems at the end of each test cycle. Totals matching at the top while individual records differ is common and is why the comparison has to go below the summary.

Also test the failure path. Stop the sync for a day and confirm someone finds out. An integration without alerting is an integration you will discover is broken when a manager calls about a missing employee.

The Reconciliation Habit That Catches Drift Early

Three checks, monthly, taking under thirty minutes once they are set up.

Headcount reconciliation. Active employees in the HRIS against active records in the time system, with the variance list reviewed rather than just the count. A count that matches can still hide two errors that cancel out.

Pay rate spot check. Pull twenty employees at random, or every employee who had a rate change that month, and compare the rate in both systems with its effective date. This is the check that would have caught the January adjustment in the opening example in February rather than July.

Status integrity. Terminated in the HRIS but active in the time system, and the reverse. Also anyone who punched after their termination date, which should be an exception report rather than a discovery.

Build these as saved reports rather than ad hoc queries, assign them to a named person, and put them on a recurring task with a date. An unowned reconciliation does not happen, and a time tracking HRIS integration that nobody reconciles will be wrong within a year regardless of how carefully it was built, because the systems keep changing underneath it through upgrades, new fields, and org restructures that nobody thinks to mention to the integration owner.

One last note worth putting in the project plan. The HRIS sync and the payroll export are two different integrations with two different failure profiles, and treating them as one project is how organizations end up with clean employee data and a payroll file that still needs manual correction every cycle. Scope them separately, test them separately, and reconcile them separately.

Classification changes, final pay timing, and overtime treatment on mid-week status changes all carry wage and hour consequences that vary by state. Have employment counsel or your payroll provider confirm the rules for your jurisdictions before configuring them.