Should OKR scores be used to determine individual bonuses?

Google's official re:Work documentation explicitly recommends against it, citing score inflation risk - employees set easier goals when attainment is tied to comp. In practice, roughly 60% of companies using OKRs still use attainment as some input to variable pay, typically as a modifier (0.7x to 1.3x) rather than a binary gate. The better framing isn't "should we tie them" but "how directly" - a company-level OKR modifier on the bonus pool creates less gaming incentive than individual OKR scores driving individual payouts.

How do I accrue bonuses mid-year when OKR scores aren't finalized yet?

Use trailing attainment as your prior-period placeholder: set the OKR modifier to last quarter's finalized average, with a sensitivity range of +/- 15% around it. Build a separate accrual flag column in your Headcount tab to track which employees have preliminary vs. final scores, and use `SUMIFS` to split your expense between confirmed and estimated. When Q4 scores finalize, the true-up flows through as a single line item rather than scattered adjustments across departments.

What's the right bonus pool funding curve when company OKR attainment drives pool size?

Most companies use a 3-5 point piecewise curve: below 0.5 attainment = 0% funded, 0.5 = 50%, 0.7 = 85%, 0.8 = 100% (target), 1.0 = 130% (cap). The exact thresholds depend on your OKR scoring calibration - if you've adopted the Google re:Work standard where 0.7 is "good," calibrate your 100% funding trigger at 0.7, not 0.8. Using an IFERROR(VLOOKUP(..., TRUE)) with a sorted lookup table handles interpolation between thresholds without nested IFs.

How do I prevent my bonus pool model from underestimating downside scenarios?

OKR attainment and revenue performance are correlated in bad years - both compress simultaneously. A model that treats them as independent inputs will understate the downside. Build a 2-variable sensitivity table in your Bonus_Accrual tab with company revenue attainment on one axis and average OKR score on the other. The bottom-left corner (say, 85% revenue, 0.65 OKR score) should show your bear case accrual. For a $4.8M target pool, that corner might be $2.9M - a 40% variance worth modeling explicitly before the board asks.

Should OKR modifiers apply to the whole bonus or just the at-risk portion?

Apply the OKR modifier only to the variable, at-risk component - not base salary or any guaranteed minimum. If a $180K director has a 20% target bonus ($36K) and the OKR modifier is 0.75, the bonus is $27K, not $36K. Total comp is $207K, not $171K. This sounds obvious but comp models frequently wire the modifier to total cash, which creates phantom salary compression in headcount cost projections. The formula in your Comp_Model tab should pull target bonus as a separate column from base salary and apply the OKR modifier exclusively to the bonus column.

OKRs and Compensation: The FP&A Modeling Problem

That's a policy choice, not necessarily a wrong one. But it creates a specific FP&A problem that almost no OKR implementation guide addresses: when OKR attainment becomes a comp modifier, your bonus pool model has a correlated distribution problem, and mid-year accruals become guesswork unless the model is built correctly.

Why Google Keeps OKRs and Comp Separate

The mechanics are simple. If employees know their OKR score drives their bonus, they set easier objectives. This is documented, predictable, and happens at nearly every company that ties the two together. In a 2023 Deloitte survey on performance management, 58% of HR leaders reported that goal-setting rigor declined after their organization linked goal attainment directly to variable pay.

Google's score scale runs 0.0 to 1.0, with 0.6-0.7 considered "good" (see our breakdown of the Google re:Work scoring methodology). The rationale for that calibration is that if 1.0 is routinely achievable, objectives weren't ambitious enough. Comp linkage flips that logic: employees anchor to 0.8 because 0.6 feels risky when it affects their paycheck.

So Google keeps them separate. That works at Google. Most FP&A teams aren't modeling Google's compensation structure.

How Companies Actually Use OKRs in Comp

In practice, the most common architecture isn't binary (hit OKRs = get bonus). It's a modifier structure:

Company OKR attainment adjusts the overall bonus pool funding, typically between 70% and 130% of target
Individual or team OKR scores modulate the individual payout within that pool
Manager discretion handles the gap between formula output and final number

A $4.8M annual bonus pool funded at 85% because the company hit 0.72 on its OKRs yields $4.08M to distribute. That delta flows straight to the P&L, and if your quarterly accrual assumed full funding, you're reversing $720K in Q4. That's a material number. It shows up in the board pack as a reconciling item, and if finance didn't model the range, it looks like a surprise.

The Modeling Challenge: Correlated Distributions

Here's the actuarial problem most models skip. OKR scores aren't independent of business performance. When the company misses revenue by 12%, OKRs tend to come in low too - not always, but often. That means:

Your bonus pool is underfunded (negative revenue variance)
Your OKR modifier is below 1.0 (poor attainment)
Both compress the accrual simultaneously

If your model treats bonus pool funding and OKR modifiers as independent inputs, you're underestimating downside scenarios by a meaningful amount. A 10% revenue miss combined with 0.65 average OKR attainment (vs. 0.80 assumed) can compress a $4.8M pool to $3.2M - a 33% swing.

The right architecture is a sensitivity table that moves both variables together, not independently.

Building the Comp Model in Sheets

A reasonable implementation uses 5 tabs: Assumptions, OKR_Tracker, Headcount, Comp_Model, and Bonus_Accrual. Here's how they wire together.

Assumptions tab holds the key inputs: target bonus pool ($4.8M), company OKR funding curve (a table mapping attainment to pool %, e.g., 0.6 → 70%, 0.8 → 100%, 1.0 → 130%), and the individual modifier range.

OKR_Tracker is where quarterly scores land, one row per objective, with columns for owner, department, Q weight, and score. The department rollup:

// Comp_Model!D4 - Engineering department avg OKR score, Q3 weighted
=SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200*
  OKR_Tracker!$F$2:$F$200
) /
SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200
)

Per-employee bonus calculation in Comp_Model pulls base salary from Headcount, the target bonus percentage from Assumptions, and the OKR modifier from OKR_Tracker:

// Comp_Model!G4 - individual bonus accrual, annual
=Headcount!$E4 *
 VLOOKUP(Headcount!$D4, Assumptions!$B$14:$C$18, 2, FALSE) *
 IFERROR(
   VLOOKUP(Headcount!$A4, OKR_Tracker!$A:$G, 7, FALSE),
   Assumptions!$C$22   // fallback to company average if individual score missing
 ) *
 VLOOKUP(Assumptions!$B$4, Assumptions!$F$3:$G$8, 2, TRUE) // company pool funding modifier

The company-level pool funding modifier uses VLOOKUP with range lookup set to TRUE because you want interpolation between attainment thresholds, not exact matches.

Bonus_Accrual then rolls this up by quarter with the appropriate timing adjustments:

// Bonus_Accrual!C6 - Q3 bonus expense, Engineering
=SUMIFS(
  Comp_Model!$G:$G,
  Headcount!$C:$C, "Engineering",
  Headcount!$H:$H, "<>" & "Termed"
) * Assumptions!$D$6 // Q3 accrual fraction (e.g. 25%)

The Score Distribution Problem

Here's what most models ignore even when they get the above right: the OKR modifier in your formula uses an average score. But the distribution of scores matters for the total payout, because bonus targets aren't uniform across the org.

If your $220K VP of Product scores 0.95 and your $85K analyst scores 0.60, the average OKR score across those two people is 0.775. But the dollar-weighted average, which is what actually drives your bonus expense, is:

= ($220K × 20% target × 0.95 + $85K × 12% target × 0.60) /
  ($220K × 20% + $85K × 12%)
= ($41,800 + $6,120) / ($44,000 + $10,200)
= $47,920 / $54,200
= 0.884

That's not 0.775. High earners with high OKR scores punch above their weight in total comp expense, and a model using simple-average attainment will understate accruals when your top performers are also your top OKR scorers.

The fix is straightforward: calculate the OKR modifier as a dollar-weighted average across the headcount, not a headcount-weighted average. But you need to build it that way from the start, because retrofitting dollar weighting into a formula that assumed head counts is a significant structural change.

As of June 2026, this is the most common error I see in OKR-linked comp models. It's also the one most likely to create a reversal in Q4 close.

Refreshing OKR Data at Quarter End

The other practical problem: OKR scores typically finalize 2-4 weeks after quarter end. Your Q3 books close in October, but final OKR scores might not land until mid-October. That creates a timing gap where you're booking an accrual based on preliminary scores that may shift.

Two approaches: (1) accrue at the prior quarter's average attainment as a placeholder, true up in the following period, or (2) build the model to flag which employee OKR scores are preliminary vs. final, and calculate a range rather than a point estimate.

If you're pulling OKR scores from a tool like Asana, Lattice, or a homegrown Sheets tracker, ModelMonkey can fetch that data into your comp model automatically at quarter close - so your accrual reflects whatever state the scores are in at close, flagged as preliminary, without manual CSV exports. Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.