Here at Sales Cookie, we help our customers automate their sales incentive program. Our general approach is to automate commission calculations based on how our customers want their commissions to work.

While we can automate virtually any type of sales commission program (including those with complex draws, formulas, tiers, etc.), only our customers truly understand their business, constraints, and goals.

However, at times, we run into situations where we feel that an incentive program has structural issues which create nightmarish complexity, and so recommend changes. Here is an example of how an apparently logical approach to commissions can create hidden complexity, reduce transparency, and increase risk.

Sample Incentive Program

Our customer wanted to use the following approach to pay commissions:

  • Each month (ex: Jan, Feb, March) has different revenue-based quotas such as:
    • Jan = 100K
    • Feb = 110K
    • March = 120K
  • Compensation is based on variable attainment thresholds such as:
    • 100% of quota = 5% of revenue
    • 125% of quota = 8% of revenue
    • 150+% of quota = 10% of revenue
  • Commissions are paid only when payment has been received
  • Reps should see the following on their dashboard, for each pay period:
    • Their estimated commission (including deals which haven’t been paid)
    • Their actual commissions (based only on deals which have been paid)

This seems pretty reasonable. Commissions are paid only when payment is received. This incentivizes reps to collect payment and close deals. Commissions are also based on each month’s booking. Corresponding quotas and attainment tiers reinforce sales motivation.

Now, the problem is that the customer wanted deals to be counted against the booking date (not the payment date). Suppose that a deal was booked in January, and payment was finally received in June. Our customer wanted January commissions to be re-calculated based on this fact, and a delta applied to each rep’s payroll.

Commission Structural Issues

There are some structural issues with this approach:

  • First, it requires a constant re-calculation of commissions of all previous periods
    • For example, suppose that we’re in June, and that payment was received for some deals from Jan, Feb, and March
    • To calculate commissions, we must do the following (for each rep):
      • Calculate commissions for June (current pay period)
      • Also re-calculate commissions for Jan, Feb, March
        • Since payment was received in June for those older deals
        • Using each prior month’s unique quota / attainment thresholds
  • Second, it creates a lot of complexity for payroll
    • Again, suppose that we’re in June, and that payment was received for some deals from Jan, Feb, and March
    • We must pay commissions for June
    • But we must also pay the difference between:
      • Previously paid Jan commissions, and re-assessed Jan commissions
      • Previously paid Feb commissions, and re-assessed Feb commissions
      • Previously paid March commissions, and re-assessed March commissions
  • Third, this makes it difficult for reps to understand their commission statements
    • Each month, reps will get a commission for the current month (ex: June), but also updated statements for previous months (Jan, Feb, March) because of retroactive adjustments
    • Because the plan uses tiers with variable payouts, commission amounts cannot be tied to specific deals
      • Some deals in aggregate may trigger higher revenue attainment and payout percentages
      • Therefore there is no way to attribute specific commissions to specific transactions
      • For example, receiving payment for some older Jan deals may trigger a higher attainment level, and so a larger commission delta
  • Fourth, in some US states, it’s illegal not to pay commissions which have been declared as earned. Showing “potential commissions” based on deals which haven’t been paid creates risk.

Another point is that this approach makes it virtually impossible to manually calculate commissions (ex: for auditing purposes). Indeed, each time a deal is paid, one would need to identify its original booking date, lookup its corresponding period (ex: Jan), check its associated quota and tiers, calculate the new total revenue for the rep, calculate a new total commission (based on tiers and total revenue), lookup past payouts, and then calculate a commission delta! And that’s just for one deal.

A Simple Tweak

Sales Cookie could automate the constant re-calculations of all past periods using our automated calculation re-run feature. This feature allows any calculation (ex: for Jan, Feb, March) to be automatically re-ran every day, each using the correct month’s quota and attainment thresholds.

However, payroll would still need to track what has been paid so far (for each rep and pay period), and only pay deltas. And reps would still remain confused when looking at their commission statements because payouts would remain opaque and fragmented.

There are two ways you can solve this issue:

  • Pay commissions based on the date payment was received OR
  • Pre-pay commissions with a claw back for cancellations

Option #1 – Pay Commissions Based On The Date Payment Was Received

Let’s consider this option. You are paying commissions based on the date payment was received. When a booked deal is paid, simply move its effective date to the new time period. For example, when a January deal is finally paid in June, its effective date should be updated to June – and it should be counted against June’s quota.

That’s it – we’ve eliminated:

  • The need to constantly re-calculate commissions for all previous periods
  • Confusing sales commission statements
  • Unmanageable complexity for payroll
  • Legal risk

And we haven’t lost anything:

  • Commissions are still paid only when deals are paid
    • The only difference is that the deal is counted towards the payment date’s quota (not the booking date’s quota)
  • Each month still has its own quota and attainment tiers
  • Reps can still see in their Jan statement what was booked (but wasn’t paid)

Option #2 – Pre-Pay Commissions With a Claw Back For Cancellations

Let’s consider this other option. You are now paying commissions based on bookings (ex: when contracts are signed). Now, some payments will fail to go through, and so you need some type of claw back.

If your claw back is retroactive, you haven’t solved anything. For example, if you notice in June that a January contract was canceled, you should NOT count this against January commissions. Indeed, this would put you back in a bad setup where you need to re-calculate commissions for all previous periods, and make payroll adjustments.

Instead, when a deal you already paid commissions for is canceled, apply a negative amount to the current pay period (ex: June). The cancellation will count against current quotas and penalize the rep.

In Conclusion

When it comes to commissions, apparently good ideas can create nightmarish complexity. The good news is that, often, a simple tweak is enough to streamline sales commissions and increase transparency. Visit us online to learn how you can automate your sales commission program!