Loading…
Loading…
An employee moves from engineering to product in month seven. The allocation is the specific thing that breaks a spreadsheet, and here is why.
Take one grant. 100,000 options, fair value $4.50, total compensation cost $450,000, vesting over 48 months. Monthly expense is $9,375, which divides cleanly and will keep dividing cleanly for four years.
The holder is in engineering. In month seven they move to product.
Nothing about the total changes. The grant is the same grant, the vesting is the same vesting, and the twelve-month expense is still $112,500. What changes is where six months of it lands.
Year 1 expense $112,500
Engineering, months 1 to 6 $56,250
Product, months 7 to 12 $56,250
--------
Allocation ties to year 1 $112,500
That is not a hard calculation. It is a hard thing to keep correct, and the difference between those two statements is the whole subject.
A workbook that allocates equity expense almost always holds the department as an attribute of the person. One row per grant, a department column, a lookup that fills it from an HR export.
That structure has no place to put "engineering until June, product from July". It can hold one value. So it holds the current one, and when somebody re-runs a prior period the allocation silently changes to match today's org chart rather than the one that existed at the time.
Nobody notices, because the total is right. The total is always right. Only the split moves, and the split is the thing nobody reconciles because reconciling it means comparing against something you did not keep.
The fix is not complicated, it is just structural. Assignment becomes a record with a start and an end rather than a field on a person:
person 4471 engineering 2025-01-01 to 2026-06-30
person 4471 product 2026-07-01 to open
Expense for a period then asks which assignment was live in that period, rather than which assignment is live now. Prior periods stop moving, because the data they read stops moving.
This is the same shape as the policy-versioning problem in capitalization and the same shape as lease modification versioning. In all three the failure is identical: current-state data being used to answer a historical question.
Once assignment is effective-dated, three things that were previously painful become ordinary.
Mid-period moves. A move on the 15th splits the month if your policy splits it, or falls on one side if your policy is simpler. Either way, the rule is applied by the system rather than decided by whoever is running the close.
Reorganisations. A department is renamed, merged, or split. The historical assignment still points at what existed then, and reporting can map old to new without rewriting what was posted.
Cost-centre allocation within a department. The same mechanism handles a finer split, if you need one, without a second workbook.
Departmental equity expense is rarely material enough on its own to justify a project. It becomes worth solving for a different reason: it is one of several places where the same structural mistake produces a number that cannot be reproduced.
If you fix effective dating for equity, you have built the pattern that also fixes it for allocation in capitalization, for policy versions in revenue, and for measurement versions in leases. The specific saving is small. The pattern is the point.
Not sure where your process sits?
Seven questions on how grant data reaches your ledger, and what it costs you each close.