Reading time: about 15 minutes. How to design and operate commission plans that only pay reps once the customer has paid you, without breaking trust, gaming the plan, or losing your audit trail.
Most commission plans assume bookings are good as cash. The deal closes, the rep gets paid, and finance trues up the books later. For a lot of businesses that assumption holds. For everyone selling on net-60 terms, into long collection cycles, with services-heavy revenue, or with a meaningful refund rate, it does not. Paying commissions on bookings that the customer never actually pays creates an expense the company carries indefinitely and a clawback conversation no one wants to have. Pay-when-you-get-paid plans solve this by tying the timing of the rep’s commission to the timing of the customer’s payment.
This is a structural design problem more than a software problem. The plan needs to handle two competing timelines: one for bookings (which sets the commission rate via attainment) and one for collections (which triggers actual payout). The mechanics are not obvious. This article walks through the model, the data architecture, the rep-statement design, the common pitfalls, and the configuration pattern Sales Cookie uses to implement it.
The two-timeline problem
The defining feature of a pay-when-you-get-paid plan is that two clocks are running at the same time. One clock advances when a deal is booked: the rep’s attainment moves, accelerators trip, and a commission rate is determined for that specific deal. The other clock advances when the customer’s invoice is paid: that is when the rep’s commission actually becomes due. Most failures in this category come from collapsing these two clocks into one and trying to handle everything at payment time.
Why both clocks have to be preserved separately:
- Attainment is bookings-driven. A rep who closes a $100K deal in January and crosses their quota that month earns the accelerator on that deal even if the customer pays in March. The accelerator is established by January’s bookings, not March’s cash.
- The rate must be remembered. If you wait until March and recompute attainment using only paid invoices, you have changed the plan. The rate the rep was promised at close has to be locked at the moment of close.
- Payments arrive incrementally. A single invoice can be paid in two or three installments. Each installment should release a proportional commission against the previously-established rate. Treating each payment as a separate attainment event would scramble the math.
- Invoice amounts diverge from booking amounts. Rebates, discounts, credits, and taxes mean the paid amount almost never matches the deal amount to the dollar. The rep is paid on the actual cash collected, not on the original booking.
The clean formula that comes out of this:
Commission = (Deal’s Attainment-Based Payout Rate) × (Invoice Paid Amount)
That formula needs two pieces of data: a rate, which was determined in January when the deal closed, and a paid amount, which arrives in March when the customer pays. Pay-when-you-get-paid plans live or die on whether the system can preserve the rate from January and apply it correctly to the March cash event.
Booking-based attainment, payment-based release
Consider a rep with a $200K quarterly quota and a plan that pays 10 percent up to quota, 12 percent above. In January they close three deals: A for $40K, B for $50K, and C for $130K. Deals A and B come in below quota and are tagged at 10 percent. Deal C straddles the quota line, the relevant portion is tagged at the 12 percent accelerator rate. None of these have been paid yet. None will pay this month.
In February the customer for Deal A pays $40K in full. The system looks up Deal A’s stored rate of 10 percent and releases a $4,000 commission. In March the customer for Deal C pays $60K of the $130K. The system looks up Deal C’s stored rate of 12 percent and releases $7,200, leaving $70K of paid amount and roughly $8,400 of commission still to be released as additional invoices clear. Deal B’s customer goes silent; no commission ever releases for it.
| Event | Deal | Booking | Stored rate | Paid in period | Commission released |
|---|---|---|---|---|---|
| Jan close | A | $40,000 | 10% | $0 | $0 |
| Jan close | B | $50,000 | 10% | $0 | $0 |
| Jan close | C | $130,000 | 12% (accelerator) | $0 | $0 |
| Feb collection | A | n/a | 10% (recalled) | $40,000 | $4,000 |
| Mar collection | C (partial) | n/a | 12% (recalled) | $60,000 | $7,200 |
| Never paid | B | n/a | 10% (locked, unused) | $0 | $0 |
Two things to notice. First, the rate Deal C got in January is the rate it gets when payment arrives in March, even if quota and accelerators look totally different by then. Second, Deal B sits indefinitely in a “could have earned” state. The rep can see it. Finance does not pay it. If the customer eventually pays, the commission releases; if they do not, the deal eventually expires.
The data architecture: two plans, two systems
Implementing pay-when-paid in production requires two distinct commission plans operating against two distinct data sources. The first plan is an estimated commission plan that consumes deal data from the CRM (typically opportunity records with a “Closed Date” effective field) and produces a commission rate per deal per payee. The second is a due commission plan that consumes invoice or payment records from the billing system (typically with a “Payment Date” effective field) and produces actual released commission amounts by looking up the previously-stored rate from the estimated plan.
| Configuration item | Estimated plan | Due plan |
|---|---|---|
| Data source | CRM (opportunities) | Billing system (invoices or payments) |
| Effective date | Closed Date | Payment Date |
| Eligibility filter | Closed Date set; records from CRM | Payment Date set; optionally balance = 0; records from billing |
| Attainment | Full tiered/accelerator structure | Single flat attainment level (rate is inherited) |
| Reward marking | Check the “estimated” box on rewards | Default release behavior |
| Crediting | Standard owner/territory crediting | Custom crediting rule: lookup payees from estimated plan by deal ID |
| Dependency | None | Depend on estimated plan (set in Calculations tab, advanced options) |
The critical link between the two plans is the deal ID embedded inside the invoice or payment record. Without it, you cannot tie a March payment back to a January opportunity, and the system has no way to look up the rate that was established for that deal. Sales Cookie’s two-systems recipe calls this out explicitly: there has to be some type of unique ID within each invoice that refers to a CRM record. In practice this usually means adding an “opportunity ID” custom field to the invoice schema in the billing system, populated either at invoice creation or via an integration.
Why a custom field rather than fuzzy matching on customer name or amount: customers buy more than once, amounts diverge from bookings, and dates rarely align cleanly. The only reliable join key is an explicit ID carried from CRM into billing. Anything else produces silent mis-credits that surface as commission disputes weeks later.
What reps need to see on their statement
The biggest mistake teams make when rolling out pay-when-paid is hiding the bookings side from the rep. The rep closed the deal in January; they want to see that they earned something, even if the cash has not arrived yet. Surfacing nothing until the customer pays makes the rep feel punished for sales-cycle dynamics they do not control, and it kills the motivation effect of accelerators.
The right statement design shows four things on every cycle:
- Could earn. The estimated commission, by deal, at the rate that was locked at close.
- Got paid. The actual commission released so far against each deal as invoices have cleared.
- Awaiting payment. The list of deals where commission has been earned but not released; what is the company waiting on, and from whom.
- Balance. The difference between cumulative estimated commission and cumulative released commission, capped at deals that have not yet expired.
Sales Cookie exposes this via the Withheld Commission Balance option on the plan’s Calculations tab. When enabled, the rep dashboard displays a “withheld commissions” section that shows, per deal where the commission has not yet been paid in full, the actual paid commission against the original estimated commission, and the running balance. Per the Sales Cookie KB on withheld commissions, the labels can be renamed (for example “Est. Commission” can become “Earned Commission” and “Withheld Commissions” can become “Deals Awaiting Payment”) so the rep-facing language matches your culture rather than the engine’s internal vocabulary.
The gotchas that quietly break the plan
| Failure mode | Why it breaks the plan | Mitigation |
|---|---|---|
| No deal ID on invoice | Lookup from due plan back to estimated plan fails; payments cannot be matched. | Add a CRM opportunity ID custom field on invoices; populate at creation or via integration. |
| Incremental payments | A single invoice paid in three installments triple-counts as bookings if mis-handled. | Sync payment records rather than invoices when payments arrive partial; effective date is each payment. |
| Bookings gaming | Reps can pump bookings that they know will never collect to drive accelerator rates on other deals. | Cap or filter bookings used for attainment to high-probability stages; reconcile periodically. |
| Stale withheld balance | Deals that will never be paid stay on the withheld list forever, inflating the apparent liability. | Set an explicit expiration in days; or manually zero the estimated commission on dead deals. |
| Mid-period rate change | If the plan is restructured mid-year, the stored rates from before the change still apply to payments arriving after. | Decide explicitly whether plan changes are retroactive; if not, snapshot rates and run new plan versions in parallel. |
| Multi-currency mismatch | FX rate at booking can differ materially from FX rate at payment; rep can be over- or under-paid. | Lock the booking-time FX; or use an explicit policy on which rate applies to released commission. |
Alternatives worth knowing
Pay-when-paid is one design point. Two adjacent designs are worth a mention because they sometimes fit better:
Pay on close with clawback. Pay the commission at deal close as usual, but reverse it if the customer never pays. Mechanically simpler because everything runs against the bookings timeline; the clawback is applied as negative attainment in the period the refund or write-off lands. Works well when collection rates are high and the few non-payments are tolerable to claw back. The downside: reps dislike clawbacks, and the cash has already left the company before it comes back.
Pay on payment, attain on payment. Use the payment date for both attainment and commission release. This collapses the two timelines into one and avoids the storage-and-lookup machinery, but it disconnects the rep’s incentive from the close moment. Some teams use this for renewals or for subscription billing where attainment-on-payment is the cleaner signal anyway. Most teams that sell new business find the rate-locked-at-close pattern motivates reps better.
Pre-launch checklist
- Deal ID is present on every invoice (or every payment record) and populated reliably
- Two plans configured: estimated plan and due plan, with the due plan depending on the estimated plan
- Effective date set to Closed Date on estimated plan; Payment Date on due plan
- Custom crediting rule on due plan looks up payees from the estimated plan via the deal ID
- Withheld Commission Balance enabled on the due plan; expiration in days set to a defensible window (90, 180, or 365)
- Statement labels chosen and reviewed with sales leadership (“Earned Commission”, “Deals Awaiting Payment”, “Balance”)
- Policy documented on what happens if a deal is voided after some commission has released
- Booking-gaming control in place (stage filter, manager approval gate, or post-close reconciliation cadence)
- FX policy documented for multi-currency deals
- Audit log review confirmed with finance: rate stored at close, rate applied at payment, both timestamped and traceable
Bottom line
Pay-when-you-get-paid is the right plan structure for any business where the gap between booking and collection is wide enough to matter and the cost of paying commissions on deals that fall through is meaningful. It is not the right plan for high-velocity, low-risk transactional businesses where collection is essentially guaranteed and the operational overhead would outweigh the protection. When it does fit, the implementation is well-understood: two plans, two effective dates, a stored rate per deal, a stable join key between CRM and billing, and a rep statement that surfaces both timelines honestly so the rep is never confused about why a commission has not been released yet.
See a working pay-when-paid configuration in Sales Cookie. Our team will walk you through the two-plan setup, the deal-ID handoff between CRM and billing, and the rep statement format that has saved customers from the most common disputes. Book a personalized demo with your own data. Pair this article with our retroactive data and true-ups guide, our crediting engine deep dive, and our why-automate ROI breakdown.
Sources: Sales Cookie – How to pay commissions only when you get paid; Sales Cookie – Withheld commissions for reps; Sales Cookie – Pay-when-paid recipe (2 systems); FASB ASC 606 revenue recognition.
Sales Commissions Explained 