Skip to main content
This guide explains how Core8 records calculation snapshots, overrides, and history, so you can explain changes and reconcile results.

​
When to use this

  • You need to explain a commission outcome and show the inputs used.
  • You want to audit changes (overrides, plan edits, recalculations).
  • You need to answer “what changed since last review?”

​
1) Plan selection (which plan applied)

When a deal is calculated, Core8 records which plan was selected for the deal (and why). This prevents “mystery changes” when multiple plans exist. If a plan is not selected, selection debug data can explain common rejection reasons like:
  • assignment inactive
  • plan inactive
  • selection date outside plan effective/end date window
  • missing required anchor date

​
2) Calculation snapshot (inputs and outputs)

Core8 stores a calculation snapshot per deal and period so you can review:
  • inputs (effective variables used at calculation time)
  • outputs (base amount, commission amount, quota credit, runtime variables)
Use the deal’s calculation transparency view to understand what the calculator produced and which plan version was used.

​
3) Manual edits (overrides)

If a user changes a deal value (for example amount/date/type), Core8 records an override so you can distinguish:
  • what was imported (baseline/source values)
  • what was manually changed (user edits)
Core8 also tracks manual changes to deal totals (for example, if a manager overrides a computed value) so you can see what changed and who changed it.

​
Where to audit in the UI

  • Start with Deal calculation transparency to see:
    • which plan was selected (and which candidates were rejected)
    • the anchor/selection dates used
    • gate metadata (invoice/payment) and why a deal is “waiting”
    • calculator inputs and outputs
  • Use the deal details page to review source vs override values.

​
Evidence checklist (when something looks wrong)

When escalating a mismatch, collect:
  • Deal URL + expected outcome (from CRM/contract)
  • Selected plan name + effective/end dates
  • Selection mode + selection date; anchor mode + anchor date
  • Eligibility gate mode (none/invoice/payment) and which evidence is missing
  • The key variables that drive the plan (amounts, deal type, dates, currency)

​
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.