Vesting Schedules Are a State Machine, Not a Formula

ESOP management sounds like the easiest module in our whole compliance suite until you actually sit down to encode a vesting schedule. On paper it's "25% per year over four years." In practice it's a small state machine with more edge cases than the spec ever mentions, and getting it wrong doesn't surface as a crash — it surfaces months later as a number on someone's exit paperwork that's quietly wrong.

The happy path is not the hard part

A standard four-year grant with a one-year cliff and monthly vesting after that is genuinely simple to model — nobody gets that wrong. The problem is that real cap tables are full of grants that don't follow the standard shape: mid-cycle grants issued on a random date, refresher grants stacked on top of an existing unvested balance, and board-approved exceptions that override the standard schedule for a specific person. Every one of those needs the same engine to produce a correct answer, which means the schedule can't be a fixed formula — it has to be data: a sequence of vesting events with their own dates and quantities, computed once at grant time and then treated as the source of truth.

Partial months and rounding are where the real bugs live

Monthly vesting over a period that doesn't divide evenly into whole shares is the single most common source of quiet errors. Vest 1,000 options over 48 months and you're vesting 20.833 shares a month — round down every month and the employee is short a handful of shares by the end; round up and you've over-issued. The correct approach isn't to round each monthly tranche independently, it's to compute cumulative vested shares as of each date and take the difference from the previous cumulative total, so any rounding error self-corrects by the final tranche instead of compounding across 48 separate roundings. It's a small computation, but getting the order of operations wrong here is the difference between a cap table that reconciles and one that doesn't, and nobody notices until an audit or an exit forces the reconciliation.

Acceleration clauses turn a timeline into a graph

Standard time-based vesting is a straight line. Acceleration clauses — full acceleration on an acquisition, partial acceleration on termination-without-cause, double-trigger acceleration requiring both a change of control and a subsequent termination — aren't modifications to that line, they're entirely separate paths through the same grant that can fire at any point and immediately supersede whatever the time-based schedule would have said. Modeling this cleanly means treating "vested as of date X" as a function that has to check for a triggered acceleration event before falling back to the standard schedule, rather than trying to bend the standard schedule itself to account for every possible trigger in advance.

Forfeiture has to know what "as of" actually means

When someone leaves the company, the system needs to freeze their vested count at the exact moment of termination and forfeit everything unvested — which sounds trivial until you ask what "exact moment" means for someone who resigns effective end of month versus someone terminated immediately. Get the effective date wrong by even a few days on a monthly vesting schedule and you've either handed someone shares they weren't entitled to or clawed back shares they'd already earned. This is one of the clearest cases where the audit-trail principles from an earlier post directly apply: the forfeiture calculation needs to be reconstructible from the exact termination date and the grant's event history, not from a value someone typed into a form during offboarding.

Buyback pricing is a business decision wearing a math costume

The actual computation — vested shares times strike price, or times a formula valuation — is the easy part. The hard part is that buyback terms often change over a company's life (a board resolution updates the formula, a new financing round changes the reference valuation), and the system has to apply the buyback terms that were in effect at grant time or termination time, whichever the plan document specifies, not whatever the current terms happen to be. That's a data-modeling problem that looks exactly like the state-over-category lesson from modeling UPSI: buyback terms are a timeline too, not a current value.

Why this is worth getting right

None of these edge cases are exotic — cliffs, rounding, acceleration, forfeiture timing, and historical pricing all show up in any real ESOP plan sooner or later. What makes ESOP software hard isn't the arithmetic, it's that every one of those cases produces a number that ends up on legal paperwork, and there's no forgiving margin for "close enough." The spec says 25% per year. The actual product is getting every one of these quieter cases to agree with what a lawyer would compute by hand.