Step 4 of ASC 606 has a quiet rule: transaction price gets allocated across performance obligations in proportion to their standalone selling prices. The rule is simple. The number that drives it, the SSP itself, is where the entire estimation methodology lives. ASC 606 gives three methods ranked by preference, plus a residual approach for the narrow case where nothing else works. The choice of method is made once per PO type and documented forever. This piece walks through the choice, the allocation math, and the drift problem that quietly invalidates the policy memo.
The three SSP methods, ranked by preference
| Rank | Method | What it does | Use when |
|---|---|---|---|
| Preferred | Adjusted market assessment | Look at the market the entity sells in and estimate what a customer would pay. Reference competitor pricing, market surveys, published rate cards. | The PO is sold by others in the market or has a clear market reference. |
| Second | Expected cost plus margin | Estimate the cost to deliver the PO and add the margin the entity would expect on a standalone sale. | Market data is limited but cost and margin are knowable. Useful for custom services or build-to-order goods. |
| Limited use | Residual approach | SSP equals transaction price minus observable SSPs of the other POs. | At least one PO has highly variable or uncertain pricing. Document why the other methods don't work. |
Most companies use a mix. Subscriptions and licenses often have observable SSPs (the published rate card). Implementation services often use cost plus margin. The rare highly variable PO uses residual. The audit question is always the same: why this method for this PO?
SSP allocation, worked end to end
A SaaS contract bundle for $250K total, with four POs allocated by SSP:
| PO | SSP source | SSP | Factor | Allocated TP |
|---|---|---|---|---|
| Subscription (12 mo) | Observable, rate card | $200,000 | × 1.0526 | $210,520 |
| Implementation | Cost plus margin | $30,000 | × 1.0526 | $31,580 |
| Training (8 sessions) | Adjusted market | $5,000 | × 1.0526 | $5,260 |
| Premium support | Observable, rate card | $2,500 | × 1.0526 | $2,640 |
| Total | Sum of SSPs = $237,500 | $237,500 | $250,000 / $237,500 | $250,000 |
The customer paid $12,500 above the sum of SSPs. That premium gets allocated to every PO proportionally by SSP weight. The recognition pattern for each PO follows the allocated transaction price, not the original SSP.
The drift problem: SSPs change, schedules don't
Contracts signed before the change keep the old SSP for allocation purposes (locked at contract inception). New contracts use the new SSP. The policy memo needs to document the reassessment trigger, the new SSP, and the effective date. Audit wants to see the version history, and will trace at least one contract from each policy era back to its allocation.
See it in motion
Cadel handling a discount override and recomputing SSP allocation
Where SSP allocation breaks
The SSP table goes stale. SSP gets set in a policy memo at fiscal year start and treated as static. List prices change, discount norms drift, cost structures shift. When the SSP table in the rev rec tool falls out of sync with the policy, every new contract allocates against stale numbers.
Discount-heavy quarters break the math. When discounted contract pricing for a PO is consistently below the SSP table, audit flags it as a Step 4 issue: either the SSP is wrong, or the discount needs to be reclassified.
Free or bundled add-ons carry zero SSP. Free goods are still performance obligations and should pull allocation. Tools that default to zero SSP for free POs silently allocate $0 to them and over-allocate to the paid POs.
Residual is used too aggressively. The residual approach is only allowed when at least one PO has highly variable pricing, but it gets used as a shortcut for "we don't know what the SSP is." Audit asks why an observable SSP wasn't the basis.
What good looks like
A clean SSP allocation has SSPs living in a versioned policy table tied to the live rate card. Allocation re-runs at contract intake using the SSP version active on the signature date. SSP changes trigger a documented reassessment, not a quiet edit to the table. Every allocation is reproducible from source.
The PO count this allocation runs against is set at contract intake, covered in detail in the revenue reconciliation explainer on tying bookings, billings, and recognized revenue together.
See how Cadel handles end-to-end revenue recognition under ASC 606, or get in touch to walk through your SSP policy memo and the gaps with your live rate card.