What if a SaaS bundle sells above the sum of its SSPs?

Most bundled SaaS contracts sell below the total standalone selling price of what they include. Some sell above it, because a customer pays for a dedicated success manager, a fast start or simply a strong negotiating position on your side. ASC 606 has no separate rule for that premium: the relative SSP method allocates the whole transaction price, so the premium is spread pro rata. This post explains why, what a premium may say about your SSPs, and what the memo should record. The worked example is a 12-month, three-obligation bundle run through the Soluqube engine, which uses integer arithmetic so the allocation ties to the contract price. For the full method, start with how SSP allocation works in our ASC 606 SSP allocation guide. Key terms: standalone selling price, transaction price and relative SSP method.

Can the transaction price exceed the total SSP?

Yes. Nothing in ASC 606 requires the transaction price to be at or below the sum of standalone selling prices. SSP is an estimate of what each item would sell for on its own, and a negotiated bundle can land above that total. The standard then allocates the full transaction price, premium included.

The discount rules in ASC 606-10-32-36 to 32-38 deal only with prices below total SSP. There is no mirror-image "premium" paragraph. So the general rule in 32-29 applies: allocate the transaction price to each performance obligation in proportion to its SSP. The premium is not a separate line, a gain or an extra obligation. It is part of the price.

How does relative SSP allocate a premium?

The same formula that spreads a discount spreads a premium. Each obligation receives the transaction price multiplied by its SSP, divided by total SSP. Because the price is above total SSP, every allocated amount comes out above its SSP, and each line carries the same proportion of the premium.

Allocated amount = Transaction price × Obligation SSP ÷ Total SSP

You don't compute the premium first and then add it. The relative formula does it in one step, and each line's premium is its allocated amount minus its SSP. The results rarely land on whole cents, so you need a written rounding rule. The engine rounds every obligation except the last half-up to the cent, and the last-listed obligation absorbs the residual cent.

What does a premium look like on a 12-month SaaS bundle?

Take a $66,000.00, 12-month contract starting January 2027. Its three obligations have SSPs totalling $64,500.00: a subscription, a dedicated customer success manager and a one-off implementation. The $1,500.00 premium is spread pro rata. The allocation ties to $66,000.00, and deferred revenue reaches $0.00 in month 12.

The subscription line is $66,000 × $48,000 ÷ $64,500, which rounds to $49,116.28. The dedicated CSM is $9,209.30, and implementation takes what remains: $7,674.42.

The subscription recognises $4,093.02 × 11 months and then $4,093.06 in month 12. The CSM recognises $767.44 × 11 and then $767.46. Monthly amounts are rounded down and the final month absorbs the remainder (terminal-period remainder absorption). Total recognised is $66,000.00. The engine result's SHA-256 hash is b17819f44f249771fd41b7da41fc82a0fdd6026eee0f35914dc876c1545b1605. You can reproduce this schedule in the app, or re-perform the allocation in the SSP allocation calculator.

Is a premium a sign that the SSPs are stale?

Often, yes. If customers regularly pay more for the bundle than your SSPs add up to, at least one SSP is probably understated, usually the one priced from an old list or a cost-plus estimate. A premium can also mean a promise is missing from the obligation list. Check both before you allocate.

A one-off premium on a single negotiated deal is plausible. A pattern is evidence. Compare the contract with recent standalone sales and with your SSP range, if you set one. If the dedicated CSM is regularly sold alone for more than its SSP, update that estimate using an observable price. Also read the contract for anything you haven't listed as a distinct good or service, such as a separate training session or an extra environment. Allocating a premium across the wrong list of obligations moves revenue between periods.

What should the memo say?

The memo should state that the transaction price exceeds total SSP, give both figures, and explain why the premium is plausible for this deal. It should confirm that the SSPs and the obligation list were reviewed, and that the premium was spread pro rata under 32-29 with a written residual-cent rule.

A reviewer should be able to re-perform the allocation from the page alone. Include:

1. The contract price and each obligation, with its clause page and excerpt.
2. Each SSP, its estimation method and source data.
3. Why the price is above total SSP, and what was checked.
4. The allocation and the written residual-cent rule.
5. A schedule that ends at $0.00 deferred, plus the export hash.

The sample SSP workpaper shows this layout. For a simpler two-obligation case with the same method, see our subscription and implementation SSP example. For the more common case, where the price is below total SSP, see how a bundle discount is allocated under ASC 606.

How can you test this on your own contracts?

Send us three of your hardest bundled 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, clause evidence for each obligation, and a hashed export.

Founding prices for the first 10 customers are available on pricing. The engine doesn't model contract modifications, variable consideration or billing schedules yet, so treat those topics as guidance only.