Standalone selling price (SSP) is the price at which a company would sell a promised good or service separately to a customer (ASC 606-10-32-32). When a contract includes multiple performance obligations, the transaction price is allocated to each based on relative SSP (ASC 606-10-32-28). When observable prices don't exist, companies estimate using one of three methods: adjusted market assessment, expected cost plus a margin, or residual. The residual approach is permitted only when SSP is highly variable or uncertain as defined by ASC 606-10-32-34 — not simply when estimation is inconvenient.
Key references: Allocation: ASC 606-10-32-28 through 32-30 · Estimation methods: ASC 606-10-32-31 through 32-35 · Discount allocation: ASC 606-10-32-36 through 32-38
SSP allocation sounds mechanical. You figure out what each deliverable would sell for on its own, divide up the contract price proportionally, and move on. In practice, the complications arrive fast: you can't observe SSP for most enterprise products, you have three estimation methods but not equal freedom to use them, and there's a discount allocation rule that's easy to miss until an auditor raises it. The standard is more prescriptive here than in most areas of ASC 606. Companies still take shortcuts: using the residual approach when conditions don't support it, applying SSP estimates that haven't been updated in years, and allocating discounts in ways that shift revenue timing they didn't intend.
The Three Estimation Methods — and Why They're Not Interchangeable
When you can observe SSP directly — because you regularly sell the product separately at a consistent price — use it. That's the cleanest case and doesn't require an estimation method at all. The judgment begins when you can't observe it directly, which describes most enterprise software and services.
The standard identifies three estimation approaches. The adjusted market assessment approach looks at what comparable goods or services sell for in the market, then adjusts for your costs and margins — most useful when observable competitor or market pricing exists. The expected cost plus a margin approach estimates the costs to satisfy the performance obligation and adds an appropriate profit margin; it's often the most defensible method for professional services and implementation obligations where cost data is available. Both require documented assumptions but neither has conditions on when they can be used.
The residual approach is different. It calculates SSP as the total contract price minus the sum of observable SSPs of every other performance obligation — what's left over is the residual SSP. ASC 606-10-32-34 permits it only when SSP is (a) highly variable — the same product sells for a broad range of amounts across customers — or (b) uncertain — no established price exists and the product has never been sold on a standalone basis. Both conditions have real meaning. "We find SSP hard to estimate" doesn't satisfy either one.
The residual approach is not a convenience method. A common error: companies apply residual to a new product at launch because they lack historical pricing data. But a published price list is relevant evidence that SSP may be neither highly variable nor uncertain — though the broader facts and circumstances still govern. What matters is whether prices are genuinely variable across customers, not just that each deal is negotiated individually. If the pricing range is meaningfully bounded, residual isn't the right tool.
How Discounts Get Allocated — The Rule Nobody Reads Twice
When the total transaction price is less than the sum of the SSPs of all performance obligations, there's a discount. The default rule under ASC 606-10-32-36 is that you allocate that discount proportionately to every performance obligation in the contract. Not to the obligation you think the customer discounted. Not to the line item where the rep applied it in the CRM. To all of them, pro-rata.
There is an exception, but the bar is real. Under ASC 606-10-32-37, you can allocate a discount to one or more (but not all) performance obligations only if all three of the following are true: (1) you regularly sell each of those performance obligations separately and have observable SSPs for each; (2) you also regularly sell a bundle of some (but not all) of those performance obligations together at an observable bundle price; and (3) the discount implied by allocating to just those obligations is substantially the same as the discount embedded in that observable bundle price. All three must be satisfied simultaneously.
Discount allocation directly affects revenue timing. On a contract that bundles a software license (recognized at point in time) with multi-year support (recognized ratably), whether the discount lands on the license or the support determines how much revenue is front-loaded. The difference can be material, and the choice requires documentation.
Where the pro-rata default surprises people. The intuition most finance teams bring to discount allocation is deal-level: the customer negotiated the discount on the implementation fee, so it belongs there. ASC 606 doesn't care about negotiation history — it cares about observable pricing. If you can't meet all three criteria for the exception, the discount spreads across everything. This catches teams off guard on multi-element SaaS contracts where the discount structure is well-understood internally but not observable in the way the standard requires.
Setting SSP When Your Pricing Isn't Standardized
SSP doesn't have to be a single point estimate — a range can be valid when selling prices vary across customers, as long as the range is meaningfully bounded. For SaaS companies with tiered pricing, defining SSP bands by customer segment (SMB, mid-market, enterprise) and applying the appropriate band is a practical, auditor-friendly approach.
This is consistent in spirit with the portfolio method in ASC 606-10-10-4, which allows revenue recognition guidance to be applied to a portfolio of contracts with similar characteristics. The portfolio method is a separate practical expedient — not an SSP rule — but it reflects the same underlying logic: contracts with similar economics can be grouped and analyzed consistently rather than each being treated as entirely unique.
Heavily negotiated enterprise contracts — where deal economics genuinely vary by a factor of five or more across customers — are the legitimate candidates for the residual approach. But the analysis is still required before defaulting to it: document that pricing is genuinely variable across customers, not just that contracts are individually negotiated.
When Your Price List Changes — What Happens to Existing Contracts
SSP is established at contract inception and locked for that contract. New contracts after a price change use updated SSPs; existing contracts don't.
The locked allocation gets re-opened only when a contract modification occurs. How SSP is applied at that point depends on how the modification is classified under ASC 606-10-25-12. A modification accounted for as a separate contract — because it adds distinct goods or services at their standalone selling price — allocates to the new obligations at current SSPs and leaves the original contract untouched. A modification that is not accounted for as a separate contract resets the remaining performance obligations, with current SSPs applied either on a prospective basis (if remaining obligations are distinct from goods or services already transferred) or through a cumulative catch-up adjustment (if they're not).
Teams that don't track modification type carefully end up applying the wrong SSP vintage — either holding stale SSPs on obligations that should have been reset, or resetting allocations that should have been left alone.
What Your System Needs to Handle
SSP allocation at scale requires storing the SSP assumption at the contract level at inception — not derived at period close from a current rate card. This matters because the allocation determines how transaction price flows to each performance obligation, and that allocation needs to be stable and traceable for the life of the contract. If SSP is recalculated from a current price list each period rather than held at the inception value, you'll inadvertently reopen allocations on existing contracts every time pricing changes.
When SSP estimates are updated, they apply to new contracts only. If billing and recognition run on separate systems, SSP updates have a way of getting applied inconsistently — new-contract SSPs bleeding into existing contracts, or stale SSPs persisting on new ones. The system design question is whether SSP is a first-class field that gets set once and tracked through the contract lifecycle, or a calculation that gets re-run at close.
Frequently Asked Questions
What is standalone selling price under ASC 606?
SSP is the price at which an entity would sell a promised good or service separately to a customer (ASC 606-10-32-32). It doesn't have to equal list price — it's the estimated standalone price, which must be estimated when direct observation isn't possible.
When can you use the residual approach for SSP?
Only when SSP is highly variable (the same product sells for a broad range of amounts) or uncertain (no established price, never sold standalone), per ASC 606-10-32-34. A published price list is relevant evidence that may weigh against residual, but it doesn't automatically settle the question — the full facts and circumstances still govern.
How are discounts allocated across performance obligations?
Proportionately across all POs by default (ASC 606-10-32-36). Allocating a discount to fewer than all POs requires meeting all three criteria in ASC 606-10-32-37 simultaneously: observable SSPs for each PO, an observable bundle price for the relevant subset, and a discount substantially equal to what the exception would allocate.
Does a price change affect existing contract allocations?
No. SSP is locked at contract inception for existing contracts. New contracts use updated SSPs. Contract modifications are the exception — depending on how the modification is classified, remaining performance obligations may be reallocated using current SSPs.
Can a range of prices be used as SSP?
Yes, when selling prices vary across customers. The range needs to be meaningfully bounded. SaaS companies often segment SSP by customer tier and apply the relevant band per contract.
SSP Allocation Is a Systems Problem as Much as an Accounting One
Getting SSP right at contract inception is the accounting judgment. Keeping it right — consistently applied across contracts, stable through the recognition period, updated for new contracts when estimates change — requires a billing and revenue recognition system that treats SSP as a first-class data element, not a spreadsheet calculation done at period close.
