Recipe - How To Handle Re-Calculations When You've Already Released Rewards
This article applies if:
To fix this, you have three options.
Option 1 - Start new calculation (side-by-side) and release it
Start a new calculation for the same time period
- Note that it shows a deduction for what was already been paid
- Release rewards for this calculation
Your payees will then have 2 statements for the same period:
- The original one
- Another one with the "delta" payout
Option 2 - Start new calculation (side-by-side) & port adjustments to original calculation
Start a new calculation for the same time period
- Note that it shows a deduction for what was already been paid
- Open this new calculation and export payouts
- Make note of the deltas for each payee
- Delete this new calculation
- Edit the original calculation
Add manual rewards for each payee matching the deltas
- To add manual rewards, go to the Rewards tab of the calculation, and click on "+ Manual Reward"
Your payee will then have their original statement corrected, with manual rewards indicating adjustments made to the original statement.
Option 3 - Re-run the original calculation and release it
- Go to your original calculation
- Re-run the calculation (choose to delete the current calculation)
- Release rewards for this calculation
Your payee will then have their original statement replaced with newly calculated payouts. Before doing this however, read our "Playing It Safe" recommendation below.
Playing It Safe
Method 3 looks natural. However, it can be risky. For example, suppose that, after re-calculation, you realized that transaction data has been incorrectly altered. You've already deleted the original calculation, so you're in a bad situation. Therefore, we recommend first running a calculation side-by-side to examine deltas. If deltas look correct, delete your side-by-side calculation, and then re-run your original calculation (with delete).
Frequent Data Changes?
If it's quite common for past data to change, your plan may require a different configuration! For example, it might be useful to adopt a strategy where commissions are always re-calculated YTD, and deductions applied based on what has been paid so far YTD. This way, if past data changes (dates or amounts), the re-calculation will catch this, because we'll constantly be re-evaluating what should have been paid YTD.
Related Articles
Recipe - How To Store Per-Calculation Values
This article describes a recipe to store per-calculation values. Typically, you want to store a value a/ for a given calculation and b/ for a given user or team. For example, you could calculate each user's average credited revenue and store this. ...
Recipe - How To Setup A Monthly Plan With QTD Attainment
Advanced Setup This is an advanced setup because there are two different ways you can setup plans with QTD attainment but frequent payouts (ex: monthly). This article applies if you want to setup a plan whose attainment is QTD, but pays commissions ...
Recipe - How To Setup A Monthly Plan With YTD Attainment
Advanced Setup This is an advanced setup because there are two different ways you can setup plans with YTD attainment but frequent payouts (ex: monthly). This article applies if you want to setup a plan whose attainment is YTD, but pays commissions ...
Recipe - How To Efficiently Setup A New Plan
This article describes a recipe to efficiently create plans based on common patterns. Those patterns work for 75% of plans. This article is intended to be a compact reference and provide general guidelines. Initialize Plan The goal here is to quickly ...
Should I Use Per-Transaction Rewards?
When adding certain types of rewards, you can specify whether rewards should be calculated per-transaction. The short answer is - if it's important for reps to see a per-transaction commission amount (and rate), then you should check the checkbox, ...