Understanding what actually moves between these systems, and what doesn't, determines whether your variable comp calculation is defensible or just a guess dressed up with formula syntax.
What the OKR-HRIS Integration Actually Syncs
The standard integration is mostly one-directional: HRIS pushes employee records into OKR software. When someone joins, their profile appears in Lattice or BetterWorks within 24 hours. When they're terminated, they're deactivated. When they move departments, the reporting hierarchy updates.
Fields that typically sync:
- Employee ID (the join key that ties everything together)
- Name, email, job title
- Department and cost center code
- Manager relationship (for goal cascading)
- Employment status and effective dates
What doesn't sync: compensation data. Salary, bonus target percentage, and equity stay in the HRIS. OKR attainment rates - the number that actually drives your variable comp calculation - stay in the OKR platform.
According to Merge.dev's unified HRIS API documentation, most native HRIS-to-OKR integrations run on daily batch jobs rather than real-time webhooks. That means your OKR system can be up to 24 hours behind on org changes - fine for most purposes, but worth knowing if a reorg happens mid-comp-cycle.
Some platforms offer reverse sync. Lattice, for example, can push performance ratings back into Workday's talent management module. But those are ratings (meets expectations, exceeds expectations), not attainment percentages, and they land in Workday's talent module rather than a format payroll or finance can consume directly.
Why Your Bonus Accrual Still Breaks
A quarterly bonus accrual requires 3 numbers per employee: base salary, target bonus %, and attainment rate. The first two live in HRIS. The third lives in the OKR platform.
If your OKR-HRIS integration is clean, at least the employee roster matches between systems. You're not reconciling 2 different headcount lists before you can even start the calculation. For companies above 75 employees, that reconciliation alone used to eat 3-4 hours per comp cycle.
The formula once you've pulled the exports and joined them in Sheets:
=SUMPRODUCT(
HRIS!F2:F200, -- Base salary
HRIS!G2:G200, -- Target bonus %
OKR_Export!D2:D200 -- Q2 attainment rate from OKR platform export
)
For department-level accruals feeding your P&L:
=SUMPRODUCT(
(HRIS!C2:C200=Assumptions!$B$4) * -- Filter by department
HRIS!F2:F200 * -- Base salary
HRIS!G2:G200 * -- Target bonus %
OKR_Export!D2:D200 * -- Attainment rate
(1/4) -- Quarterly accrual factor
)
The formula works. The problem is the OKR_Export tab. Someone has to pull that export from the OKR platform, format it consistently, and drop it in the right place each quarter. If your OKR admin exports with different column headers than last quarter - it happens more than it should - the formula breaks silently and you're off on your accrual.
For a 120-person company with an average base salary of $115,000 and a 20% target variable comp rate, you're managing a $2.76M annual bonus pool. A misaligned attainment column isn't a minor inconvenience.
The Four Integration Patterns and What Finance Gets From Each
Different integration setups produce very different experiences for finance.
| Pattern | How it works | Sync frequency | Finance usability |
|---|---|---|---|
| Native integration (Workday + Lattice, BambooHR + BetterWorks) | Built-in connector configured by HR/IT | Daily batch | Clean org data; attainment still manual export |
| Middleware API (Merge.dev, Finch, Rippling) | Unified API layer normalizes fields across platforms | Configurable (15 min to daily) | Better for custom data pulls; requires IT involvement |
| SCIM provisioning | Handles user accounts only, tied to SSO | Near real-time | Identity management only - useless for comp data |
| SFTP/CSV scheduled export | Automated file drops to shared drive or email | Daily or weekly | Highest finance usability if you're already pulling CSVs |
The "native integration" option sounds ideal but finance usually sees the least benefit. HR gets clean org data in their OKR tool. Finance still exports from both systems and joins them manually.
SFTP/CSV exports are the most finance-friendly pattern, not because they're technically superior but because they produce files you can directly import into your model. If IT can configure a weekly HRIS export and a weekly OKR attainment export to the same shared drive, you've solved the practical problem.
The Last-Mile Problem Nobody Talks About
Here's the non-obvious thing: even a perfect OKR-HRIS integration doesn't close the loop for finance. The integration is HR infrastructure. It keeps two HR systems in sync. Your model is a third system and it's almost always excluded from the integration design entirely.
The actual data journey looks like this:
HRIS → OKR software (via the integration everyone is excited about) → OKR export → someone cleans it → paste into model
Those last 3 steps are entirely manual regardless of how sophisticated the HRIS-OKR integration is. The integration reduces one source of error (stale headcount in the OKR tool). It doesn't eliminate the manual export and reconciliation step that produces the number your model actually needs.
This is worth knowing when your VP of HR says "we've integrated BambooHR with 15Five, so you should have what you need for comp." You have cleaner org data. You still don't have attainment rates in your model.
Getting Attainment Data Into Your Model Without Fighting IT
Standardize the export request. Give People Ops a template with specific column names in a specific order. "Employee ID, Department, Q3 Attainment %" - not whatever the default export produces. Do this once per platform and document it. When they inevitably switch OKR vendors, you hand them the template again.
Join on Employee ID, never on name. People go by different names across systems (legal name in HRIS, preferred name in OKR platform). Employee ID is the only reliable key.
=IFERROR(
INDEX(OKR_Export!$D:$D,
MATCH(HRIS!$A2, OKR_Export!$A:$A, 0)
),
0 -- 0% attainment if no match (new hire, not yet in OKR)
)
Validate the match rate before running the accrual. Count unmatched employees after the join. If more than 5% of your headcount has no attainment match, something's wrong - usually a headcount discrepancy from the OKR sync lag, or someone who joined mid-cycle.
=COUNTIF(OKR_Joined!E2:E200, 0) / COUNTA(OKR_Joined!A2:A200)
Anything above 5% is worth a conversation with HR before the numbers go to your CFO.
Lock your Assumptions tab. Put accrual timing (monthly vs. quarterly), department rollup logic, and attainment floor/cap rules in Assumptions, not hardcoded into the formulas. When HR changes the OKR cycle from quarterly to continuous - and they will - you change one cell, not 40 formulas.
The reconciliation work here is exactly the kind of repetitive cleanup that burns an hour every comp cycle. ModelMonkey can handle it directly inside Google Sheets - you describe the join you need ("match OKR attainment to HRIS headcount on Employee ID, flag unmatched records"), and it builds and validates it, including flagging when column headers shift between exports. Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.