Reading time: about 12 minutes. Why crediting and payment are two different decisions, how conflating them creates the worst kind of comp expense errors, and how Sales Cookie keeps them separate so audits, manager overrides, and team plans all behave correctly.

One of the most expensive mistakes a comp design makes is treating “who closed the deal” and “who gets paid for the deal” as the same field. They are not the same. Crediting answers a measurement question: which user or team should this transaction count toward for attainment, quota, and performance reporting. Payment answers a reward question: which person or persons should actually receive money as a result of that credit. In simple individual plans the two collapse into one answer because the rep who is credited is also the rep who gets paid. In any plan with overrides, team rollups, channel partners, or shared credit, the two diverge, and a comp engine that treats them as one field will either pay the wrong person, double-count attainment, or both.

This distinction also drives ASC 606 commission capitalization. The credit determines which contracts a salesperson’s compensation is associated with, which in turn drives how that compensation is amortized over the customer benefit period. If your books show a manager being paid against deals they were not credited on, the auditor will ask why, and the answer “because that is how the spreadsheet was set up” is not satisfactory. This article walks through the distinction, the four standard patterns Sales Cookie uses, and the audit and dispute consequences of getting it wrong.

The two decisions a commission engine has to make

Per the Sales Cookie crediting engine documentation, the engine “processes transactions to credit users or teams so as to measure sales performance.” Critically, the same documentation also describes a separate step: “Rewards may be assigned to credited users and team members, or to user managers or team managers, depending on the reward strategy chosen on the plan.” That second sentence is where the distinction lives. The engine does not assume that the credited party is the paid party. It models them as two independent decisions, made in sequence, on every transaction.

The crediting decision is consumed by quota attainment, leaderboards, performance reporting, and tier calculations. The payment decision is consumed by paystub generation, GL postings, and ASC 606 allocation. The two outputs are linked but not identical. A single transaction can produce one credit and zero payments (suppressed credit), one credit and one payment to a different party (override), one credit and multiple payments (team rollup), or multiple credits and multiple payments (split deals).

Why the distinction matters: four real scenarios

The cleanest way to see why crediting and payment have to be separable is to walk through four common scenarios and ask, for each: who counts it, and who gets paid. Conflating the two answers breaks at least one of these patterns.

Scenario Credited party Paid party Why they differ
Standard rep planRepSame repTrivial case, crediting and payment collapse
Manager override (individual)RepRep’s managerManager is paid on rep attainment, but the rep still owns the deal for reporting
Team rollup planTeamAll team membersTeam measures collective performance, payout distributes to every member
Channel-influenced dealDirect rep + partner repBoth, at different ratesTwo parties earn against the same deal under different plans
Suppressed deal (clawback)RepNo one (this period)Credit remains for attainment history, payment is withheld or reversed

Notice row five. The rep is still credited for the original sale because the attainment history has to reflect that the sale happened. The payment, however, is suppressed because the deal was canceled, the customer churned within the clawback window, or the underlying invoice was never paid. A system that ties payment directly to crediting either has to delete the original credit (corrupting attainment history and quota tracking) or pay the rep anyway (creating a clawback fight later). A system that separates them just changes the payment side and leaves the credit history intact.

The four Sales Cookie reward strategies

Sales Cookie formalizes the crediting-vs-payment split through what it calls reward strategies. Each plan picks one. The crediting engine produces credits, and the reward strategy determines who gets paid from those credits. The four strategies map onto the four organizational realities of how commission flows through a company.

Strategy Crediting target Payment target Typical use
Credit user, pay userIndividual repSame repStandard quota-carrying AE plans
Credit user, pay managerIndividual repRep’s user managerIndividual-attainment overrides for direct managers
Credit team, pay team membersTeamAll members of the credited teamPod plans, collective bonuses, SDR/AE shared books
Credit team, pay team managerTeamTeam managerCollective-attainment overrides, regional manager bonuses

The same transaction can be processed by any combination of these four strategies in parallel. A single new-business closed-won deal can produce an individual credit on the AE plan paying the AE, a team credit on the pod plan paying the SDR and AE pod-members, and another team credit on a regional override plan paying the regional manager. Three plans, three sets of credits, three reward distributions, all derived from one transaction, all auditable back to it.

How the separation prevents audit findings

Under ASC 606, commission paid as an incremental cost of obtaining a customer contract has to be capitalized and amortized over the period the customer benefit is recognized, unless the amortization period would be one year or less. The capitalization is done at the contract level, and the system has to be able to answer: which commission payments are tied to which contracts? If your engine fuses crediting and payment, this question becomes ambiguous when a manager is paid on a rep’s deal. Is the override capitalized against the same contract as the rep’s commission? Yes, both are incremental costs of obtaining that contract. But who is credited for the contract? Only the rep. The manager is paid because of the rep’s credit, not because of their own.

A system that records the credit on the rep and the payment on the manager (linked back to the rep’s credit, linked back to the contract) produces a clean audit trail. The auditor can pull the contract, see the rep’s credit, see the manager’s payment derived from that credit, and trace the amortization schedule for both. A system that records the manager as a co-credited party on the deal corrupts the attainment history (managers do not have quotas as ICs) and creates ambiguity about whose performance the contract reflects.

Where the conflation typically happens

Custom spreadsheets and home-grown commission tools usually start with one column: “commissionable party.” As the plan complexity grows, that column gets reused for things it was never designed for. By year two there is a tab where a manager’s name appears on rep deals to drive their override calc, and the attainment formulas on the rep tab have to filter that out. Year three the company adopts ASC 606 and finance realizes the override rows are double-counting in the capitalization schedule. The fix at that point is to rebuild the model with two columns, which is exactly what a separated crediting-vs-payment engine has from day one.

Symptom Likely root cause Sales Cookie fix
Manager attainment exceeds 100% because direct reports’ deals roll up as creditCrediting and payment fused; manager is credited for rep workCredit-user-pay-manager strategy on the override plan, manager not on rep crediting
ASC 606 amortization schedule shows duplicated cost on overlapping dealsSame contract credited twice (rep and manager) when only paid twice was intendedSingle credit on the rep, two payments linked to that credit, ASC 606 export filters by credit not payment
Leaderboards include managers, distorting rep rankingsManager credited on rep deals, leaderboards read creditsManager only paid (not credited), leaderboards stay clean
Suppressed deals (canceled, churned, unpaid invoice) disappear from rep historyCrediting is deleted along with payment when the deal goes badCredit preserved for attainment history, payment withheld or reversed independently
Channel partners and direct reps cannot both earn on same dealOne commissionable-party field cannot hold bothTwo plans, two credits, two payments, all from one transaction

Reading the audit trail

When crediting and payment are separated, every commission record has at minimum five linked facts: the transaction, the plan, the credit, the reward strategy, the payment. Sales Cookie surfaces these together in the rep’s statement and in the admin’s calculation view, so a dispute or audit query traces back through the chain rather than landing on a single conflated row. The KB-documented strategy that “rewards may be assigned to credited users and team members, or to user managers or team managers” is what creates that chain. Without it, the chain collapses into one row, which is the row everyone fights about.

Design rules for separating the two

If you are designing or rebuilding a plan, the following rules keep crediting and payment cleanly separated and prevent the audit issues described above.

  • Credit only the person whose performance the deal reflects. If a manager did not personally close, do not credit them. Pay them via a reward strategy.
  • Build override and team payouts as separate plans, not separate rows on the same plan. Each plan has its own crediting target and reward strategy.
  • Use the rep’s plan to drive attainment reporting, the manager’s plan to drive override payouts. Do not let manager payouts back-feed into rep attainment.
  • For suppressions, modify the payment, not the credit. Keep credit history immutable so attainment and forecasting stay reproducible.
  • Tie ASC 606 amortization to the credit and contract, not the payment. Multiple payments from one credit amortize against the same contract.
  • For channel deals, create two plans (direct and partner) with separate credits and separate payments. Do not co-credit on one plan.

How Sales Cookie surfaces this in the product

The plan setup wizard asks two distinct questions: (1) what should be credited, individual users or teams, and (2) what is the reward strategy, paying the credited party, paying their manager, paying team members, or paying the team manager. These questions correspond directly to the columns in the reward-strategy table earlier. The choices are stored on the plan and visible on every calculation. Reps see who was credited and how the payment was derived. Admins see the full chain when they drill into any line. Auditors can export the chain via the OData API and reconcile against contracts. Disputes get faster to resolve because the answer to “why is this on my statement” or “why is this not on my statement” is always five facts away rather than one ambiguous row.

Related reading

Sources