Scheduled Changes & History
Compensation configuration in Earnest is date-scoped. Nothing is edited in place. When you change a plan's rules, a team's seasonality, a title's quota or a person's position, Earnest closes the current version and opens a new one from the date you choose.
That single design decision is why a payout from March still calculates correctly in September, and why "what plan was this rep on when that deal closed?" always has an answer.
Supersede: the primary verb
Saving a configuration change does not overwrite the old one. It:
- Closes the current version at the moment before your effective date.
- Opens a new version from your effective date onward.
- Keeps the old version intact, so past periods keep calculating against it.
Versions cannot overlap — the database enforces it — so at any given date there is exactly one answer for what the configuration was.
A change effective 1 April affects April's payouts and leaves March untouched. A change dated in the future does nothing at all until that date arrives.
Published periods are protected independently. A configuration change can never reach back into a period that already has a published payout.
Admin → Scheduled Changes
Everything scheduled but not yet in effect is listed on one page, so you can see what is about to happen to payroll before it happens.
| Change | What it covers |
|---|---|
| Plan rules | Tiers, cap, floor, base rate, ramp steps, ratio goal. |
| Team seasonality | Quarterly weightings. |
| Title quota | A title's default quota. |
| Team plan mix | The multi-plan split and its weights. |
| Team plan assignment | Which plan a team is on. |
| Position | A future hire, or a role, team or title change. |
| Position end | A scheduled end date — the supported way to stop future pay. |
| Plan mix removal | A team reverting from a mix back to a single plan. |
| Plan assignment removal | A team's plan assignment ending with no successor. |
| FTE override | A future-month ratio denominator override. |
Ends are listed as first-class entries, not just starts — otherwise the page would under-report what payroll is about to do.
Retracting a scheduled change
A mis-picked effective date needs an undo, so a change that has not yet taken effect can be cancelled. Cancelling deletes the future version and reopens its predecessor, restoring it to open-ended.
Two rules:
- Only strictly-future changes can be cancelled. A version that has already started is off limits — supersede it with a fresh change instead.
- Cancelling is recorded, not erased. The retraction is stamped with who cancelled it and when, and appears under Recently canceled. The timeline shows what was scheduled and what happened to it.
This is what makes the Simulator safe to use aggressively: you can model a change, adopt it into the plan editor, and still retract it before it goes live. See Modeling & Optimizing Plans.
The As-of audit
The second tab answers historical questions precisely. Pick an entity kind — Plan rules, Team seasonality, Title quota, Team plan mix, Team plan assignment or Position — then the specific entity, then two dates:
| Date | Question it answers |
|---|---|
| Config for date | What was in effect on that date? |
| Knowledge as of | What did we know on that date? |
Two dates rather than one, because those are genuinely different questions.
Suppose a quota change effective 1 March was entered on 20 March. Asking "what was the quota on 10 March?" gives different answers depending on when you ask:
- Config for 10 March, knowledge as of today → the corrected quota. What was true.
- Config for 10 March, knowledge as of 15 March → the old quota. What we believed at the time — and therefore what a payout run on 15 March would have used.
The second is what explains a historical payout. The first is what is correct now. Being able to ask both is what makes a published payout defensible months later: you can reproduce exactly the configuration the run actually saw.
Leaving Knowledge as of blank means "as of now".
How this shows up elsewhere
- Payouts freeze a plan snapshot at generation and record which plan version they resolved to.
- Statements show the quota derivation for the version that applied.
- Managers and reps see an upcoming changes list on their dashboard, so a quota or plan change is visible before it lands rather than as a surprise in a statement.
- Corrections replay against the frozen snapshot, not current config — which is why they stay accurate after the plan has moved on. See Corrections & Clawbacks.
Frequently asked questions
Q: I edited a plan and last month's payout didn't change. Is that a bug? No, that is the point. Plan edits schedule forward. Past periods keep their own version, and published payouts additionally keep a frozen snapshot.
Q: How do I fix a plan that was wrong for a period already paid? Not by editing the plan — that only affects the future. Post a correction against the published period. See Corrections & Clawbacks.
Q: Can I schedule a change and cancel it later? Yes, any time before its effective date. After it takes effect, supersede it with a new change.
Q: Why can't I cancel a change that already started? Because periods may already have been calculated against it. Removing it would silently rewrite those. Superseding forward keeps the history intact.
Q: How do I stop paying someone from a certain date? Schedule a position end. It appears on the Scheduled Changes page like any other future change, so payroll can see it coming.
Q: A rep changed teams mid-quarter. Which plan applies? Each period resolves against the configuration in effect for that period. A quarter spanning a change is calculated per segment, each against its own version — which is also why such a quarter cannot be auto-corrected by a single-version recompute.