Here at Sales Cookie, we help our customers automate their commissions. Some of our clients calculate commissions based on bookings, but pay commissions only when they receive payment from their customers.

This is NOT a trivial setup because the underlying commission structure must take into account two competing timelines:

  • One timeline establishes potential commissions based on bookings
    • Ex: as reps close more deals, their commission rate change because of accelerators, quota retirement, etc.
  • One timeline establishes due commissions based on collections / payment
    • Ex: when payment is received for a deal, a corresponding earned commission amount should be issued to the rep

This approach can make rep statements more complex. For example, consider the example below. Deal A was closed in January, but only paid much later in June. Deal C was both closed and paid in January.


What should your rep’s January and June commission statements show? Will your reps be able to understand what’s happening given the two event timelines? Will they be able to track unpaid deals and verify that their commission statements are correct?

Part 1 – Attainment

First, we must assign a commision amount to each eligible deal. Let’s say that our commission structure follows a simple pattern (shown below). Once quotas have been retired, a commission accelerator kicks in. Commissions accelerate to 12% of revenue in lieu of the baseline 10%.

Below, three deals were closed in January. Deals A & B should be paid at the 10% level. Deal C however should be paid at the 12% level. This is based on total attainment for January. Deal C crossed a quota threshold, and so qualified for an accelerated 12%.


For our commission structure to work, we must remember the commission rate for each deal based on attainment. The goal is to establish commission rates which will then be applied (much) later when we receive payments. Here is what we need to remember:

  • Deal A = pay at 10% (based on January attainment)
  • Deal B = pay at 10% (based on January attainment)
  • Deal C = pay at 12% (based on January attainment)

Note: in practice, things tend to be a bit more complex. For example, a blended tier may need to be applied to deal C because it crossed 2 tiers.

Part 2 – Payment

A naive approach is to think of payment events as simple release triggers. From this naive point of view, paying an invoice is enough to trigger payment of the deal’s established commission amount in full.

In reality however, things are often more complex:

  • Deals may be paid incrementally (in portions)
    • Ex: there were 2 staggered payments for a large deal
  • Invoiced amounts may be different from deal amounts
    • Due to rebates, discounts, credits, taxes, etc.

Therefore, each paid invoice should NOT act as a simple trigger which pays the original deal’s full commission. Instead, we should lookup the commision payout rate previously established for the deal, and apply this commission rate to the invoice’s paid amount. This solves the issues listed above where payment is received incrementally, or doesn’t quite match the original deal’s amount.

So here is the formula we want to use: [Commission] = [Deal’s Attainment-Based Payout %] * [Invoice Paid Amount]


Matching Payments To Deals

To implement the “pay commissions when we get paid” strategy, we often must work with two systems:

  • A CRM system (ex: SalesForce) which shows when each deal was closed
    • We use CRM deals to calculate booking-based attainment, and establish a commission rate for each deal
  • A billing system (ex: QuickBooks) which records payments by customers
    • We use paid invoices to lookup a previously established commission rate, and apply it to the invoice’s amount


Now, if you can use one system for deal tracking and payment tracking, hats off to you! For example, if invoices get created immediate as CRM deals get closed, no need to involve your CRM system in commissions. You could track bookings based on open invoices, and collections based on invoice payments, so commissions only need 1 system.

Things get more complicated if you receive payments incrementally. In this case, we have no choice but to deal with 2 systems – one tracking deals and one tracking payments. We also need a way to correlate payments to deals, as this is required to perform lookups across systems. This ideally should be using unique identifiers.

For example, it’s reasonable to have a deal ID within each paid invoice. It’s NOT reasonable to try to fuzzy-match things based on customer names, amounts, or dates. Often those will be slightly or very different – for example:

  • Customer is “Blue Sky LLC” in SalesForce
    • But customer is “BlueSky” in QuickBooks
  • Amount is $1000 in SalesForce
    • But amount is $500 in QuickBooks due to a rebate

We highly recommend recording the deal ID (ex: SFDC opportunity ID) in your invoice workflow so that the matching process can be robust and fully automated. This will also eliminate the risk of incorrect payment-to-deal matches.

Rep Owed Balances

Consider the following scenario:

  • Deal A worth $100 in commission was closed in January, and has NOT been paid yet
  • Deal B worth $100 in commission was closed in January, and was paid in February

Some organization have a concept of “owed commission balance” which records how much money would be paid to reps should all their pending deals get paid. In our example above, the January owed balance would be $200, while the June owed balance would be $100. Unfortunately, there are a few issues with this approach:

  • In reality, some deals will never be paid, so rep owed balances will increase without bound. Of course, you could periodically remove old deals so that their owed balance doesn’t get out of control, but this is more admin work for you and it’s confusing.
  • Rep balances don’t help your reps because it’s just an aggregate. How useful is it to know that you are “owed” another $5000 across 13 deals from January, February, March, etc.?
  • In some jurisdictions, it’s risky to declare commissions as owed. You might be liable to pay those balances should a lawsuit arise in certain US states.

So how can we make it work? The solution is to provide clear visibility on all withheld deals to your reps, and to expire older deals which will never be paid.

Our Approach at Sales Cookie

At Sales Cookie, we use a flexible approach:

  • We create a commission plan which calculates estimated commissions based on deal attainment. Sales Cookie remembers the estimated payout and commission rate for each deal and each payee.
  • We then create another commission plan which calculates earned commissions based on paid invoices. Sales Cookie provides a function which automatically determines the estimated commission rate for each deal and payee.
  • We show all transactions whose earned payout is less than the actual payout while allowing you to expire old deals which will never be paid.

Here is the magic function to lookup previously estimated commissions. It performs a lookup by payee and deal ID to determine the estimated commission rate. The commission rate can then be applied to the invoice’s amount. This works well if you receive payment incrementally for the same deal, for example.


In terms of reporting, reps can now see how much money they could earn on each deal, and how much they got paid on each deal.

credits (1)

Reps can also see which deals are awaiting payment, as well as their balance:


Here is the corresponding plan configuration:


What To Watch For

Here are some of things to watch for when using a “pay when we get paid” model.

First, your are increasing complexity. We know that you are trying to make things look exciting to your reps and show them how much money they could earn as soon as they close a deal. However, you are also making their commission statements more fragmented and more complex by delaying payment of commissions. You must also ensure that deal IDs are available in payment records to ensure correct matching of payments to deals – this may not be trivial.

Second, your reps could game the system. For example, if they close a lot of deals which will NEVER be paid, they might start getting commision accelerators based on artificially inflated bookings. Now you’re paying commissions at a higher rate, even though many deals which contributed to acceleration will never be paid. This would NOT be a problem if both attainment and payment were based on collection dates (i.e. paid invoices). In other words, if payment is never received, you granted higher attainment which will never be offset.

Therefore, consider the following two alternative approaches:

  • Pay commissions upfront (i.e. as deals close), and claw back commissions if you don’t receive payment from customers
    • This also makes it possible to apply negative attainment to the next period
  • Use payment dates as a way to establish both attainment-based payout rates and issuance of commissions
    • This effectively ensures you only work with one timeline (not two)

In Conclusion

In this blog post, we described how you can calculate and pay commissions when you get paid. This increases complexity, but using proper tracking and the correct model, we can ensure success. Sales Cookie provides advanced capabilities to automate this type of complex commission structure. There are still some tradeoffs you should be aware of when choosing this model, however. Please visit us online to learn more!