How is a bundle discount allocated under ASC 606?

A bundle discount exists whenever a SaaS contract's price is lower than the total standalone selling price of everything it includes. ASC 606 spreads that discount across every performance obligation in proportion to SSP, unless observable evidence ties it to specific items. This post covers the default rule in ASC 606-10-32-36, the narrow exception in 32-37, and how to show the discount in an allocation workpaper. The worked example is a 24-month, three-obligation bundle run through the Soluqube engine, which uses integer arithmetic so the allocation ties to the contract price. If you need the steps before this one, start with how SSP allocation works in our ASC 606 SSP allocation guide. Key terms: standalone selling price, transaction price and relative SSP method.

What counts as a discount under ASC 606-10-32-36?

Under ASC 606-10-32-36, a customer receives a discount for buying a bundle when the sum of the standalone selling prices of the promised goods or services exceeds the promised consideration. In SaaS, that usually means a subscription, implementation and support priced together for less than they would cost bought separately.

The comparison is between the transaction price and total SSP, not list price. If your SSPs are list prices nobody actually pays, part of the apparent discount may simply be stale SSPs. Fix the SSP evidence first. Each item must also be a distinct performance obligation; a discount can't be allocated to something that isn't one.

How is a discount spread across obligations by default?

By default, ASC 606-10-32-36 allocates the discount proportionately to every performance obligation in the contract. Each obligation receives the transaction price multiplied by its SSP, divided by total SSP. That single formula spreads the discount pro rata, so every line is reduced by the same proportion of its SSP.

Allocated amount = Transaction price × Obligation SSP ÷ Total SSP

You don't calculate the discount separately and then subtract it. The relative formula does it in one step, and each line's discount is simply its SSP minus its allocated amount. 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 pro rata discount look like on a 24-month bundle?

Take a $96,000.00, 24-month contract starting December 2026. Its three obligations have SSPs totalling $106,300.00: a subscription, a one-off data migration and standard support. The $10,300.00 discount is spread pro rata. The allocation ties to $96,000.00, and deferred revenue reaches $0.00 in the final month.

The subscription line is $96,000 × $84,000 ÷ $106,300, which rounds to $75,860.77. Data migration is $11,288.81, and standard support takes what remains: $8,850.42.

The subscription recognises $3,160.86 × 23 months and then $3,160.99 in month 24. Support recognises $368.76 × 23 and then $368.94. Monthly amounts are rounded down and the final month absorbs the remainder (terminal-period remainder absorption). Total recognised is $96,000.00. The engine result's SHA-256 hash is 734e129170b590beb4a306a898c140ce86088fe15c996af80eed3335cba3aaa0. You can reproduce this schedule in the app, or re-perform the allocation in the SSP allocation calculator.

When can a discount go to only some obligations?

Only when all three conditions in ASC 606-10-32-37 are met: you regularly sell each distinct good or service on its own; you regularly sell a bundle of some of them at a discount; and that bundle's discount is substantially the same as the contract discount, with observable evidence showing which obligations it belongs to.

In SaaS this is rare, because few vendors sell implementation and support as a separately discounted bundle often enough to build that evidence. Wanting to load the discount onto a one-off fee so more revenue lands up front is not a reason. If the conditions are met, ASC 606-10-32-38 says to allocate the discount before using the residual approach for any obligation. The Soluqube engine and calculator apply the default pro rata rule; a targeted 32-37 allocation is a judgement you document separately.

How do you show the discount in the allocation workpaper?

Show each obligation's SSP and its basis, the transaction price, total SSP and the allocated amounts side by side, so a reviewer can see the discount and re-perform the split. State which rule applied, pro rata under 32-36 or targeted under 32-37, and the evidence behind that choice.

A reviewer re-performing the allocation should need nothing beyond the page. Include:

1. The contract price and each obligation, with its clause page and excerpt.
2. Each SSP, its estimation method and source data.
3. The discount rule applied, with 32-37 evidence if it was targeted.
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 how the rounding rule is chosen and documented, see our post on where the residual cent goes. For the opposite case, where the contract price is above total SSP, see what happens when a SaaS bundle sells above the sum of its SSPs.

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.