Vendor SLA framework for time feeds — contract clauses, onboarding tests and production cutover requirements

Most time feed integrations don't fail dramatically. They fail quietly. A vendor pushes clock events an hour late during a DST change, or drops 200 punches over a long weekend because their queue backed up, and nobody notices until payroll runs and half the night crew is short four hours. By then it's not a technical problem anymore — it's an angry Slack channel and a manual reconciliation nightmare.

Reliability is mostly decided before go-live, in the contract and the onboarding phase. Once a vendor is live and pumping data into your system, your leverage is nearly gone. That's why the SLA — the actual clauses, the test matrices, the cutover conditions, the rollback obligations — matters far more than the sales demo.

This is a systems piece, not a checklist of "things to ask your vendor." The goal is to show how the contract, the onboarding tests, and the production cutover all connect, and where each one tends to break as you scale from one location to twenty.

Why time feeds break differently than other integrations

A time feed isn't like a CRM sync or a marketing webhook. If your marketing tool drops an event, you lose a data point. If your time feed drops an event, someone doesn't get paid correctly — and depending on jurisdiction, that can escalate into a wage-and-hour issue fast.

1. 1
   It's deadline-bound. Payroll cutoffs don't move. A feed that's "usually on time" is worthless if it misses the one Tuesday afternoon that matters.
2. 2
   It's cumulative and ordered. A missing clock-out changes the meaning of every event around it. You can't just backfill one record and move on.
3. 3
   It's legally significant. Time records are evidence. If a vendor mangles them and you can't reconstruct the truth, that's your liability, not theirs.

Vendors sell you on the happy path — clean punches, stable network, normal week. The SLA needs to be written around the unhappy path, because that's the only part that ever actually costs you money.

The contract layer: what a time feed vendor SLA actually needs to say

Generic SLAs talk about "99.9% uptime" and call it a day. Uptime is nearly meaningless for time feeds. A vendor can be "up" the entire pay period and still deliver garbage. What you actually need are clauses that pin down data correctness, delivery timing, and recovery behavior.

Two clauses people almost always forget:

Severity tiers keyed to payroll, not the vendor's convenience. Every vendor has a P1/P2/P3 scale, but theirs is written around their own infrastructure. You want a clause that says: any incident affecting a feed within 24 hours of a payroll cutoff is automatically top severity, regardless of how many other customers are affected. Vendors push back on this because it forces them to prioritize you during a shared outage. That resistance is exactly why it belongs in writing.

Data correctness credits, not just uptime credits. Service credits for downtime are almost worthless — a few hundred dollars off next month's bill doesn't cover the labor of re-running payroll. Tie credits to data integrity failures (dropped events, duplicated pay, missed windows) and make them meaningful enough that the vendor has a real financial incentive to prevent them.

The onboarding test matrix: prove it before you trust it

This is the phase everyone rushes, and it's the single highest-leverage part of the whole process. Onboarding is when you still have full leverage and zero production risk. If you don't force the vendor to fail in a sandbox, they'll fail in production instead.

A solid onboarding test matrix isn't a smoke test. It deliberately drives the feed into the ugly conditions that real operations produce. Think of it in three tiers.

Tier 1 — Normal operation. Confirm the boring stuff works: a full week of standard punches for a mix of employees, correct mapping of employee IDs, correct time zones, correct rounding behavior. If rounding or grace periods are handled differently by the vendor than by your policy, you find it here, not on a paycheck.

Tier 2 — Realistic mess. This is where most matrices stop too early. You need to inject:

1. 1
   Missed clock-outs and dangling open shifts
2. 2
   Duplicate punches from a double badge-tap
3. 3
   Out-of-order event delivery
4. 4
   Retroactive corrections submitted after the original period
5. 5
   A DST spring-forward and fall-back window
6. 6
   Employees who work across midnight

Tier 3 — Failure and recovery. Simulate the disasters: kill the connection mid-transmission and confirm the vendor recovers without duplicating or losing events, replay a batch and confirm idempotency holds, delay a delivery past a mock cutoff and watch how the alerting actually behaves.

One thing most teams miss: the test matrix should become an ongoing acceptance test, not a one-time gate. Vendors push updates. A change on their side six months post-launch can silently break TC-19. Re-running the critical subset of the matrix after every vendor release catches regressions before they hit a paycheck. The mechanics of connector testing and idempotency checks overlap heavily with what's covered in the payroll integration runbook on connector testing and safe cutover steps — worth aligning your matrix with that runbook so you're not maintaining two separate testing philosophies.

“

Run a critical subset of the matrix after every vendor release to catch regressions early.

Make the matrix part of your CI/acceptance process where possible so it's low-friction to re-run.

Production cutover: the part where confidence gets people burned

The moment you flip a feed to production is the moment your test environment stops protecting you. Teams consistently treat cutover like a switch — off in staging, on in production — when it should be a sequence with gates and a live fallback.

1. 1
   Freeze the scope. Cutover happens for a defined population — one location, one department — not the whole company at once. Blast radius control matters more than speed.
2. 2
   Run parallel, don't replace. For at least one full pay period, run the new vendor feed alongside your existing capture method and reconcile both. If the numbers diverge, you catch it while the old system is still authoritative.
3. 3
   Reconcile at the event level, not the summary level. Totals can match by coincidence while individual records are wrong. Compare event counts per employee per day.
4. 4
   Define the go/no-go gate in advance. Write down, before cutover, exactly what result blocks the switch. "Any employee with a variance over X minutes = no-go." Deciding this under pressure the morning of cutover never goes well.
5. 5
   Cut over during a low-risk window. Never the day before a payroll cutoff. Early in a pay period gives you room to catch and fix.
6. 6
   Keep the old capture path warm. Don't decommission anything for a full cycle after cutover.

The parallel-run period is the single most valuable safeguard in this whole process, and it's the one most often skipped to hit a launch date. A week or two of running two systems feels wasteful right up until it saves you from paying 40 people incorrectly. The timing and reliability concerns around delivery windows connect directly to the patterns in the webhook and API reliability playbook for when time events break payroll cutoffs — that's the mechanical layer underneath the cutover discipline described here.

A simple workflow diagram showing the gates and fallback helps the team run the sequence without missing a step.

Get buy-in on the gates from payroll, HR, and the vendor before the first parallel run.

Rollback obligations: assume the vendor will fail, and plan the exit

Rollback is the clause people sign without reading and regret later. The question that actually matters: if this vendor's feed corrupts a pay period, can you get back to a known-good state, and whose job is it to make that happen?

1. 1
   Point-in-time restore. The vendor must be able to re-deliver all events for a given window on demand, not just "resend today's data."
2. 2
   Deterministic replay. Re-delivering the same window twice must produce the same result. If replay creates duplicates, it isn't rollback — it's a second incident.
3. 3
   Correction lineage. When bad data has already flowed into payroll, you need to know exactly which records to reverse. The vendor should support exporting a full change history.
4. 4
   Exit rollback. If you leave the vendor, you get all historical data in a usable format, and you retain the ability to reconstruct any past period for audit or dispute.

That last point ties directly into your broader retention and recovery posture. Rollback isn't only about fixing this week — it's about being able to reconstruct a period two years from now when a wage claim lands. The recovery objectives and reconstruction requirements in the timesheet data lifecycle blueprint covering RTO/RPO and e-discovery should shape what rollback capability you demand from a vendor. If a vendor can't meet your RPO, they can't meet your compliance needs, full stop.

What breaks at scale

At one location with one feed, informal handling works. You notice problems because there aren't many of them, and one person understands the whole flow. The SLA barely matters because you can eyeball the data.

1. 1
   You stop noticing failures manually. With 15 locations, nobody's eyeballing 15 feeds. A silent drop at location 9 goes unseen until payroll. Detection has to be built into the SLA and monitored, not left to human attention.
2. 2
   Vendor incidents overlap with your cutoffs randomly. More feeds means more surface area, and eventually a vendor's maintenance window lands on top of your payroll deadline. This is why the payroll-keyed severity clause matters more the bigger you get.
3. 3
   One vendor's replay behavior becomes a company-wide risk. At scale, a non-idempotent replay doesn't affect one location — it can double-pay a whole region.
4. 4
   The onboarding matrix becomes non-negotiable. When you're adding vendors regularly, ad-hoc testing guarantees inconsistency. A standardized matrix is the only way every new feed clears the same bar.

What you handled with attention at small scale, you have to handle with contracts and automated reconciliation at large scale. The SLA framework isn't bureaucracy — it's the thing that replaces the person who used to just know when something looked off.

When a heavy SLA framework makes sense — and when it doesn't

Worth the effort when: you're running payroll across multiple locations, you rely on more than one external time data source, you operate in jurisdictions with strict wage-and-hour rules, or a single bad pay period would trigger real legal or morale fallout. If any of those are true, the contract and test rigor pays for itself the first time it catches a problem.

Overkill when: you're a single small team with one time source you fully control, low headcount, and forgiving payroll timing. Writing a 12-clause SLA for a five-person shop with one clock is process for its own sake. A solid reconciliation habit handles it just fine.

Who should be careful: fast-growing businesses that are about to cross the multi-feed threshold. The mistake is applying small-business informality right up until the week it breaks. If multi-location or multi-vendor complexity is coming in the next year, build the framework before you need it — not after the incident that proves you needed it.

A real scenario

A regional facilities-services company running around 380 field and shift staff across nine sites brought on a badge-and-mobile time feed vendor. The sales process was smooth; onboarding was rushed to hit a quarter-end launch. No parallel run, minimal failure testing.

Their first real DST fall-back weekend, the vendor's feed double-counted the repeated 1–2 AM hour for overnight staff. Because there was no event-level reconciliation, the error slipped through and roughly 60 overnight employees were overpaid an hour each. Correcting it after the fact — clawbacks, corrections, a very unhappy night crew — ate somewhere around 30–40 hours of HR and payroll time and did real damage to trust on the floor.

The fix wasn't a new vendor. It was retrofitting the framework they'd skipped: a proper onboarding matrix including DST and duplicate-punch cases, a payroll-keyed severity clause, a contractual replay and rollback obligation, and a standing two-system reconciliation for the first period after any feed change. The next DST transition passed with the discrepancy caught automatically in reconciliation, before a single incorrect check went out. Their payroll team put it simply — they stopped bracing for the transitions.

Bringing it together

The thread running through the contract, the onboarding tests, and the cutover is the same: reliability with time feeds is designed upstream, when you still hold leverage, and it's mostly about the failure paths nobody demos. The clauses that matter are the ones about correctness, delivery timing tied to your cutoffs, and rollback. The tests that matter are the ones that break things on purpose. And the cutover discipline that matters most is refusing to trust a feed until it's proven itself running in parallel against a system you already trust.

Get those three layers aligned and a vendor problem becomes a caught reconciliation variance instead of a payroll crisis. Skip them, and you'll eventually learn — the expensive way — that "usually reliable" and "reliable when it counts" are two very different things.

The thread running through the contract, the onboarding tests, and the cutover is the same: reliability with time feeds is designed upstream, when you still hold leverage, and it's mostly about the failure paths nobody demos. The clauses that matter are the ones about correctness, delivery timing tied to your cutoffs, and rollback. The tests that matter are the ones that break things on purpose. And the cutover discipline that matters most is refusing to trust a feed until it's proven itself running in parallel against a system you already trust.

Get those three layers aligned and a vendor problem becomes a caught reconciliation variance instead of a payroll crisis. Skip them, and you'll eventually learn — the expensive way — that "usually reliable" and "reliable when it counts" are two very different things.