How does SSP allocation work under ASC 606? A complete guide

Searching "ASC 606 SSP" usually means one of two things: you need to know what a standalone selling price is, or you have a bundled contract and an auditor asking how you split it. This guide covers both. It explains what SSP means, the three estimation methods in ASC 606-10-32-33 to 32-35, how relative SSP allocation works under 32-28 to 32-31, and how discounts, premiums, ranges and rounding fit in. Every worked number below was produced by the Soluqube engine using integer arithmetic, and every allocation ties to the contract price. For the terms, see the standalone selling price and relative SSP method glossary entries. To try your own figures, use the SSP allocation calculator.

What does SSP mean in accounting?

SSP means standalone selling price: the price at which an entity would sell a promised good or service separately to a similar customer. In ASC 606 and IFRS 15, SSP is the basis for Step 4 of the five-step model. A bundled contract price is split across its performance obligations in proportion to their SSPs.

SSP is set at contract inception and is not updated for later price changes. It applies to the transaction price, which is fixed in Step 3. If you resell third-party software, decide first whether you report gross or net; our principal vs agent worked example covers that test.

How do you estimate SSP under ASC 606?

When SSP isn't directly observable, ASC 606-10-32-33 requires an estimate that uses as many observable inputs as possible. Paragraph 32-34 names three suitable methods: adjusted market assessment, expected cost plus a margin, and the residual approach. Under 32-35, you can combine methods, for example applying the residual approach to only one obligation.

• Adjusted market assessment. Start from what the market would pay, using competitor pricing for similar products, then adjust for your costs and margins.
• Expected cost plus a margin. Forecast the cost of providing the item, then add an appropriate margin. This works well for implementation and professional services.
• Residual approach. SSP is the total transaction price minus the observable SSPs of the other obligations. It is allowed only in narrow cases, covered below.

When do you use an observable price instead of an estimate?

Use an observable price whenever one exists. ASC 606-10-32-32 calls the price of a good or service sold separately in similar circumstances to similar customers the best evidence of SSP. A list price counts only if items actually sell near it. If deals routinely close below list, use the actual prices instead.

In SaaS, renewal-only support and standalone training days often have observable prices; a subscription sold only in bundles usually needs an estimate. One contract can mix both. Document which is which, and keep the data each one rests on.

How does relative SSP allocation work?

Under ASC 606-10-32-28 to 32-31, each performance obligation receives the transaction price multiplied by its SSP, divided by the total SSP of all obligations in the contract. The allocated amounts always add up to the transaction price, so any gap between the price and the total SSP is spread across every obligation in proportion.

The formula for each line is:

Allocated amount = Transaction price × Obligation SSP ÷ Total SSP

The results rarely come out in whole cents, so you need a fixed rounding rule. The engine rounds every obligation except the last half-up to the cent, and the last obligation takes the residual.

What does a full SSP allocation look like on a SaaS contract?

Take a $138,000, 36-month SaaS contract starting December 2026. It has three obligations with a total SSP of $159,000.00: a subscription, a premium support tier (24x7, 1-hour SLA) and onboarding. The $21,000.00 discount is spread pro rata. The allocated amounts tie to $138,000.00, and deferred revenue ends at $0.00.

The subscription line is $138,000 × $120,000 ÷ $159,000, which is $104,150.94 after rounding. Premium support is $26,037.74. Onboarding takes what's left: $7,811.32.

Here is the monthly schedule:

The subscription recognises $2,893.08 × 35 months and then $2,893.14 in month 36. Support recognises $723.27 × 35 and then $723.29. In each case the final month absorbs the rounding remainder. The engine result's SHA-256 hash is 527ca94f9afa96bae0f16aa3c70377d9918b970299299d6321fd41128a67e853. You can reproduce this exact schedule in the app, or re-perform the allocation in the calculator. For a two-obligation version, see subscription plus implementation. The sample SSP workpaper shows the output format.

How are discounts and premiums allocated?

Under ASC 606-10-32-36 to 32-38, a discount is spread across all obligations in proportion to SSP. It goes to specific obligations only when observable evidence shows that it relates to them. When the contract price is above total SSP, the same relative formula spreads the premium pro rata.

Here is a premium case from the engine. A $66,000.00 contract has a total SSP of $64,500.00, so the price is $1,500.00 above SSP:

A premium should also make you look again at your SSPs. A price consistently above total SSP can mean an SSP is understated, or that an obligation is missing from the list.

For step-by-step versions, see how a bundle discount and a bundle premium are allocated, how the standalone selling price formula is rounded so it ties, and whether SaaS training is a separate performance obligation.

When is the residual approach allowed?

ASC 606-10-32-34(c) allows the residual approach only when an item's selling price is highly variable, or uncertain because it is new or has never been sold separately. Even then, the other obligations need observable SSPs. A residual that comes out at zero or near zero is a warning sign, not a valid result.

The residual approach estimates SSP; it doesn't replace relative allocation. Consider any discount under 32-37 before you arrive at the residual. See the residual approach entry for the steps.

How do SSP ranges work?

ASC 606 doesn't define SSP ranges, but many SaaS companies use one: a band around the midpoint of their standalone sales prices. Prices inside the band are accepted as SSP. A price outside it is adjusted to the nearest point in the band, or to the midpoint, under a written policy.

A range saves re-estimating SSP for every deal, but recalculate it periodically and keep the sales data behind it. See the SSP range entry. In public filings, few SaaS companies name their SSP method.

Where does the rounding cent go?

Relative allocation rarely produces whole cents. If you round every line on its own, the total can end up a cent above or below the contract price. A written rule fixes this by naming one obligation to absorb the residual cent. The engine assigns it to the last-listed obligation, so the allocation ties exactly.

The same applies over time. Monthly amounts are rounded down, and the final month absorbs the remainder. That is why the subscription in the main example ends at $2,893.14 rather than $2,893.08. The amounts involved are far below materiality. The point is that a reviewer can re-perform the allocation and get the same result. Our residual-cent post compares the alternative rules.

When is revenue ratable and when is it point in time?

Revenue is ratable when the customer receives and uses the benefit as you perform, as with a subscription or a support tier that is available every day. Under ASC 606-10-25-27, that is recognition over time. Distinct onboarding or training is usually recognised at a point in time, when it is delivered.

Allocation and timing are separate steps. Step 4 decides how much each obligation gets, and Step 5 decides when it is recognised. In the main example, onboarding's $7,811.32 is all recognised in month 1, while the two ratable lines spread over 36 months. Multi-year deals whose price ramps up raise their own timing questions; see multi-year ramp pricing.

What changes under Ind AS 115 and 18% GST?

Ind AS 115 uses the same relative SSP allocation as ASC 606. For an Indian SaaS contract, 18% GST is collected on behalf of the government, so it is not part of the transaction price. You take it out before allocating and book it as an output GST liability on the invoice.

Here is an engine run on an INR contract. The transaction price is ₹24,00,000.00 net of GST, the total SSP is ₹27,50,000.00, and it starts in April 2027:

₹4,32,000 output GST kept out of revenue, booked as a liability on the invoice. The gross invoice is ₹28,32,000.00. The subscription recognises ₹80,000.00 a month, and support recognises ₹10,909.09 a month for 23 months, then ₹10,909.11. US contracts carry no GST. See the Ind AS 115 GST example.

What do auditors look for on SSP?

Auditors look for four things. Each SSP should have a documented basis. Observable data should be used wherever it exists. Methods should be applied consistently across similar contracts. And the allocation and schedule should be recalculable from the inputs. They also test whether the contract data feeding the calculation is complete and accurate, and who approved each judgement.

Expect a reviewer to recompute a sample of contracts. Numbers nobody can re-run draw more questions, which is why finance teams reject black-box AI for this work. Diligence teams follow the same pattern: see how QoE teams test SSP allocation.

What should an SSP documentation checklist include?

For each contract, a usable SSP file has seven parts: the signed contract and order forms; a list of performance obligations with the clause page and excerpt for each; the SSP method and source data for each obligation; the allocation; the residual-cent rule; a schedule that ties to the price; and the Controller's sign-off.

1. Contract inventory: date, counterparty, currency, transaction price.
2. Performance obligations, each with its clause page and a verbatim excerpt.
3. The SSP method for each line, with the price list version or sales data behind it.
4. The allocation, showing that it ties to the transaction price.
5. The written residual-cent rule.
6. A schedule ending at $0.00 deferred.
7. Sign-off, export version and SHA-256 hash.

For teams preparing this for a client, see how an outsourced team documents SSP allocation. If you are choosing a tool to hold this evidence, our comparisons of Maxio vs NetSuite ARM and Chargebee RevRec vs Maxio set out how each vendor describes SSP allocation, from its own pages; Maxio alternatives compares six options side by side.

How can you test this on your own contracts?

Send us three of your hardest contracts through the design partner programme, and you get a free 3-contract workpaper. You confirm the obligations and stated prices. We send back the relative SSP allocation, a schedule that ties to the cent, page-and-excerpt clause evidence for each obligation, and a hashed export your auditor can re-run.

Founding prices for the first 10 customers are on the pricing page. In the app, uploaded text-layer PDFs also show a highlight on the cited line; built-in samples use an approximate overlay. The engine doesn't model contract modifications, variable consideration or billing schedules yet. Treat those topics as guidance only.