This blog post explains when and how to use deductions to calculate commissions correctly when dealing with high-volume sales.

Most sales organizations don’t deal with high-frequency / high-volume sales. Tracking thousands of sales in a CRM or accounting system is never a problem. Typically, each sale is tracked individually, in chronological order. Each sale is represented by a single record or granular entry.


Each sale typically also has an effective date (ex: closed date, payment date, etc.). To calculate commissions for a given pay period, choose a start/end date. Next, make sure only those transactions within your chosen calculation period are processed. Any commission automation solution knows how to do this!


Some businesses however deal with a high volume of sales transactions. Some may have millions of transactions per day. For example, for an online ad platform, each click may represent a “sale”. For this reason, it may not be possible to track sales individually. Instead, aggregates must be used to track sales. Here is an example showing total clicks per domain, tracked monthly.


So far so good. No need to use deductions to calculate commissions, yet. We can use the same approach as traditional sales departments, and simply process aggregate transactions within the period we want to calculate commissions for. Here is what our commissions might look like for January, February, March, and April (note the start and end dates).


Here’s the problem, though. Assume we’re now in May. What happens if thousands of January clicks were found to be fraudulent? Or if there some large customer refunds were issued for January sales? We’ve already paid January commissions! How can we fix commissions? A simple fix could be to apply a negative count to May’s totals, to make up for the January refunds.

However, there are two issues with this approach:

  • Most high-volume sales systems simply don’t know how to do this. All they do is update January totals (ex: from 84,758 clicks to say 79,204 clicks) in a database. They can’t magically create another row of data with a negative count to apply to May.
  • What if a rep exceeded their quota in January and received a bonus? Perhaps this bonus shouldn’t have been paid, based on our new knowledge of January totals. Applying a negative count to May totals won’t make commissions right because the bonus will still have been paid for exceptional performance, and won’t be clawed back.

One solution is to use deductions – i.e. always calculate commissions from the same reference point, such as Jan 1st:

  • To calculate January commissions, process totals from Jan 1 to Jan 31st.
    • We don’t have anything to deduct at this point.
  • To calculate February commissions, process totals from Jan 1 to February 28.
    • Deduct previously paid January commissions.
  • To calculate March commissions, process totals from Jan 1 to March 31.
    • Deduct previously paid January AND February commissions.
  • To calculate April commissions, process totals from Jan 1 to April 30
    • Deduct previously paid January AND February AND March commissions.

We’re now able to calculate commissions correctly, even though sales totals have retroactively been revised. Essentially, we’re constantly re-evaluating total commissions due from the beginning of the year, but subtracting what we already paid you. This ensures commissions are correct. For example, the January bonus we paid you for exceptional performance may be undone by later re-evaluations of what your commission should have been.

Using Sales Cookie, selecting an overlapping time period when calculating commissions automatically triggers deductions. Sales Cookie automatically detects the overlap and adds a deduction to avoid double-payment of commissions. Even better, you can configure advanced options to specify how deductions should work. You can choose a reference date and a deduction rule. Here is what calculations may look like. Note that the start date is always January 1st (our reference date).


On rep incentive dashboards, online statements will include a negative amount for each deduction, along with an explanation:


This approach works well, but can we improve further? There is one small downside to our approach. If we were to go back in time and recalculate January commissions, we’d get a different total from what we calculated in the past because January totals have been updated. We’ve lost knowledge of what January totals were in January.

This may not be a big deal if you always “move forward” with your commission calculations, and never need to go back in time to recalculate prior statements. However, it can be a good idea to consider the following approach if your sales tracking system supports it. Instead of blindly updating January totals, consider tracking multiple copies / versions of January totals:

  • As of January 31st, the January total for was X
  • As of February 27th, the January total for was Y
  • As of March 31st, the January total for was Z
  • Etc.

This means keeping a snapshot of all totals for each period. It also mean we can go back in time and recalculate commissions (still using the deduction-based approach) for any point of time. We know – this point is a bit technical, but hopefully our explanation makes sense! Don’t worry if this was a bit confusing. This is not essential to the general approach of using deductions to deal with high-volume sales.

In Conclusion

Many high-volume sale systems don’t track sales individually. Instead, they work with aggregate data. Sometimes, this aggregate data needs to be retroactively adjusted due to refunds / returns / cancellations. Deductions ensure commission calculations remain correct. Using deductions, we constantly re-evaluate due commissions from a reference point, minus previous payments. Sales Cookie can help you automate this type of scenario. Click here for a free commission assessment!