The payout happened in the March commission run (that's when it was calculated and paid).
The deal's close date now shows February (because it was edited/backdated after the fact).
So there's a disconnect between when the money was actually paid (March) and what period the deal currently says it belongs to (February).
#Sales Cloud #Revenue Management System #Revenue Cloud #Salesforce Revenue Cloud
This is a known pain point in Spiff/ICM the tool is calculating off a live field (
Close Date) instead of a locked, point-in-time snapshot. The fix isn't really "how do I stop deals from being backdated" it's "stop letting a mutable CRM field drive an immutable financial record."Root cause: Spiff's plan logic is likely referencing Opportunity.CloseDate (or a similarly live-synced field) to bucket the deal into a payout period. When that field changes after calculation/payout, any report or re-run that re-evaluates the deal picks up the new value, creating a mismatch between "period paid" and "period the deal now says it belongs to."
How to actually fix it a few layered options, roughly in order of how I'd sequence them:
- Snapshot the period at calculation time, don't derive it live. Add a dedicated field something like Commission_Period__c on the commission/statement record (or in Spiff's own statement object) that's set once when the statement runs and never recalculated from CloseDate again. Spiff does support adding effective dates on plans/logic and locking historical statements, so this should be a config change in Spiff's plan design rather than custom Apex — check that "lock historical statements" setting is actually turned on for closed periods.
- Separate "Close Date" (sales-facing, editable) from "Commission Effective Date" (finance-facing, locked once a statement is generated). Reps and deal desk need to edit Close Date for pipeline/forecast reasons that's normal. The commission engine should never read that same field for historical periods once paid.
- Treat post-payout edits as a reconciliation event, not a silent recalculation. If a close date changes after a statement already paid against it, that should trigger a clawback/adjustment workflow (a new adjustment line in the next period), not a retroactive rewrite of March's numbers. This is standard ASC 606-adjacent practice Spiff's audit-ready expense reporting is built around exactly this kind of compliant, locked-period model.
- On the Salesforce side, if Opportunity edits are what's causing this, consider a validation rule or Flow that blocks/flags Close Date changes on Opportunities that already have a Commission_Statement__c (or equivalent) linked and Closed/Locked at minimum, notify Finance/RevOps rather than letting it happen silently.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
