If a transaction has its effective date changed to a later period, it's possible it may yield a double-commission in future calculation periods.
For example, let's say you have a plan which pays monthly commissions. A transaction's closed date was set to January. Therefore, your January calculation yielded a commission for this transaction. Later, the transaction's closed date was updated to February. Now, your February calculation yields another duplicate commission for the same transaction!
Such scenarios may be accidental (ex: someone incorrectly changed a transaction's closed date when this should never happen). Or such scenarios may be intentional (ex: it is valid for the effective date to change, and we need to re-evaluate commissions based on new "facts").
Accidental Effective Date Change
If changing the effective date is uncommon, it may be sufficient to rely on Sales Cookie's double-payment alerts. Sales Cookie will automatically alert you when we discover that multiple commissions have been paid to the same beneficiary and the same transaction over multiple calculations.
You can disable generation of alerts under Settings > Advanced > Settings:
One strategy you may employ is to prevent changes to effective dates within your data. For example, some CRM systems make it possible to lock fields (ex: closed date) based on the current state (ex: closed won). Also, you may want to consider alternative data layouts (ex: create new records instead of updating existing records - this has the benefit of preserving the entire history).
You should also avoid is duplicate and overlapping calculations as those can cause double-payment of commissions. If this happens, you will see a purple bar appear under Calculations > All Calculation. For example, if you have 2 calculations for the same plan and same time period, you will see this.
Finally, if you use plans which re-calculate the total YTD owed commission each period, and deduct what has been paid YTD, then you may be immune from some accidental date changes. Even if a record's date is changed, the total owed will be re-evaluated, and what you paid previously will be deducted (as a lump sum). However, this may not work if a record's date is moved to the next year.
Intentional Effective Date Change
If changing the effective date is intentional and valid, we must re-evaluate commission amounts and only pay the delta between a/ re-evaluated amounts b/ the amount paid so far. For this purpose, we can add a per-transaction reward formula such as the following.
In the example above, we re-evaluate the owed commission. We then lookup the commission amount paid to the current beneficiary over the same transaction. Finally, we only issue the difference. For example, if the re-evaluated owed amount is the same as the amount paid so far, the amount will be zero.
There may be some other scenarios where you simply want to simply exclude any transaction which has already paid a commission and ignore delta adjustments. This can be done using a dynamic transaction filtering formula such as the following:
In the example above, we lookup up the owner from the transaction, and resolve it to a credited user. We then lookup the commission amount paid to this credited user over the same transaction. If a commission has been paid, we filter out the transaction.
There may be other scenarios where you do want to pay a delta commission, but also reduce the amount credited for attainment purposes. For this, use a custom attainment metric and calculate credits using a similar formula. For example, you could pro-rate the credited amount.
Finally, you could consider using plans which re-calculate the total YTD owed commission each period, but deduct what has been paid YTD. Even if a record's date is changed, the total owed will be re-evaluated, and what you paid previously will be deducted (as a lump sum). However, this may not work if a record's date is moved to the next year.