Skip to main content
This guide explains when a deal is considered in period, how Core8 selects a plan, and why the selected plan can differ from payout timing.
  • Deal relevance mode (anchor mode): which deal date Core8 uses as the timing anchor (for example closed‑won, invoice, payment).
  • Anchor date: the actual derived date Core8 uses for timing and period grouping.
  • Selection date: the date Core8 uses to decide which plan applies (must fall within the plan’s window).
  • Effective date: the first selection date that makes a plan eligible.

​
When to use this

  • You need to understand why a deal landed in a specific period.
  • You need to understand which plan was selected and why.
  • You’re debugging timing rules vs assignment behavior.
At a high level, plan selection is based on:
  1. the deal’s selection date (derived from deal dates + plan settings)
  2. the plan’s effective date and optional end date
  3. whether the participant has an active assignment to that plan

​
Deal relevance mode (anchor mode)

Plans define a deal relevance mode (the key date used for timing semantics and period grouping). In the UI this appears as Deal relevance mode (sometimes called “anchor mode” in documentation). Common relevance modes include:
  • Closed-won date
  • Contract signature date
  • Subscription start date
  • Invoice date
  • Payment received date
  • PO signature date
If a plan does not explicitly set a deal relevance mode, Core8 defaults to payment received date.

​
Selection date vs anchor date

Core8 uses two related dates:
  • Selection date: used to decide which plan is eligible (selection date must fall within the plan’s effective window).
  • Anchor date: used to compute commission timing and period grouping for calculations.
By default, Core8 uses the anchor date as the selection date.

​
Plan selection mode (optional)

Plans can optionally set a separate plan selection mode so that the plan is selected by one date while timing is still driven by the anchor date. Example:
  • A plan might use payment received as the anchor date (timing), but use closed‑won date as the selection date to avoid retroactive plan changes when payments arrive later.

​
Effective date vs end date

  • Effective date: the earliest selection date that can use the plan.
  • End date: the latest selection date that can use the plan (optional).
If the selection date is outside the plan window, Core8 will not choose that plan for the deal.

​
Overlapping plans

If multiple plans are eligible for the same selection date, Core8 selects the plan with the most recent effective date.

​
Common pitfalls

  • Missing selection date: if the selection mode requires a date the deal doesn’t have, the plan is rejected.
  • Missing anchor date (even if selection date exists): Core8 must be able to compute the anchor date to calculate timing; otherwise the plan is rejected.
  • Overlapping plans: if outcomes look wrong, review the plan assignment timeline and confirm which plan has the most recent effective date.
To debug selection, use the deal’s calculation transparency view (it shows eligible/rejected candidates and reasons).

​
Common gotchas

  • If a number looks “wrong,” first confirm you’re looking at the right period and right plan (selection/timing vs payout timing).
  • If two places disagree, check whether one view is showing source values and another is showing effective values (after overrides).
  • When debugging, follow the chain: Deal → Plan selection → Eligibility gates → Calculation breakdown.