A three-year SaaS deal that bundles a platform subscription with an implementation service is one of the most common Step 4 allocations a revenue team performs. This worked example takes a $126,000 contract, allocates it by relative standalone selling price (SSP) under ASC 606-10-32-28 to 32-41, and lays out the 36-month schedule. Every figure below comes from a run of the Soluqube engine, so you can re-perform it line by line.
What is the contract in this example?
The customer signs a $126,000 contract for 36 months starting November 2026. It contains two performance obligations: a platform subscription recognised ratably, with an SSP of $132,000, and an implementation service recognised at a point in time in month 1, with an SSP of $18,000. Total SSP is $150,000.
The stated price is $24,000 below the sum of the standalone selling prices. Nothing in the facts suggests the discount relates to only one obligation, so under ASC 606-10-32-36 to 32-38 it is spread proportionately across both. For whether implementation is distinct from the subscription in the first place, see ASC 606-10-25-19 to 25-22; this example assumes it is.
How is the $126,000 allocated by relative SSP?
Each obligation receives the transaction price multiplied by its SSP over total SSP. The platform subscription gets $126,000 × 132,000 / 150,000, which is $110,880.00. Implementation gets $126,000 × 18,000 / 150,000, which is $15,120.00. The two allocations sum to $126,000.00, so the allocation ties to the transaction price.
Transaction price: $126,000.00
| Obligation | SSP | Share | Allocated |
|---|---|---|---|
| Platform subscription | $132,000 | 132,000 / 150,000 | $110,880.00 |
| Implementation | $18,000 | 18,000 / 150,000 | $15,120.00 |
| Total | $150,000 | $126,000.00 |
The shares are written as SSP over total SSP on purpose. Rounded percentages hide the cents; the ratio lets a reviewer re-perform the multiplication exactly. For the method itself, see the relative SSP method and standalone selling price glossary entries.
What does the 36-month revenue schedule look like?
November 2026 recognises $18,200.00: the full $15,120.00 implementation allocation plus the first $3,080.00 of platform revenue. Every following month recognises $3,080.00 of platform revenue through October 2029. The unrecognised balance falls from $107,800.00 after month 1 to $0.00 after month 36, and total revenue is $126,000.00.
| Month | Platform | Implementation | Revenue | Deferred |
|---|---|---|---|---|
| Nov 2026 | $3,080.00 | $15,120.00 | $18,200.00 | $107,800.00 |
| Dec 2026 | $3,080.00 | — | $3,080.00 | $104,720.00 |
| Jan 2027 | $3,080.00 | — | $3,080.00 | $101,640.00 |
| ... | $3,080.00 every month | |||
| Aug 2029 | $3,080.00 | — | $3,080.00 | $6,160.00 |
| Sep 2029 | $3,080.00 | — | $3,080.00 | $3,080.00 |
| Oct 2029 | $3,080.00 | — | $3,080.00 | $0.00 |
| Total | $126,000.00 |
"Deferred" here is the transaction price not yet recognised. Whether it sits on the balance sheet as a contract liability depends on billing and payment, which ASC 606-10-45-1 to 45-4 govern and this example does not model.
Why is there no remainder month in this schedule?
Because $110,880 divided by 36 is exactly $3,080, the subscription spreads into 36 equal whole-cent months and nothing is left over. The last month does not need to absorb a remainder. That is a property of these particular numbers, not of the method, and most real contracts will not divide this cleanly.
Compare the residual-cent worked example. There, the relative-SSP allocations end in repeating decimals, one obligation absorbs the rounding residual, and the ratable schedule gives the final month the leftover cents so the balance still reaches $0.00. A written policy should cover both cases, even when a given contract only exercises one of them.
What does this example not cover?
This example is deliberately narrow. The engine applies one contract term to every obligation, recognises point-in-time obligations in month 1 with no delivery-date input, and spreads ratable obligations in equal monthly amounts with no daily proration. It has no billing or contract-asset modelling, no usage-based or variable consideration, and no contract modification accounting.
If your implementation goes live in month 4, or the subscription starts mid-month, the timing in the schedule above will differ from yours. The allocation step itself does not change.
How can you re-perform it on your own contracts?
Run your own subscription and implementation bundle through the SSP allocation calculator to see the allocation and the monthly schedule. Or send us your three hardest contracts for a free 3-contract workpaper: the relative-SSP allocation, the schedule that ties to the cent, and a hashed export you can re-run.
Is the $24,000 discount allocated only to implementation?▼
Not in this example. ASC 606-10-32-36 to 32-38 require a discount to be allocated proportionately unless observable evidence shows it relates entirely to one or more, but not all, obligations. With no such evidence here, both obligations share it in proportion to their SSPs.
Why is implementation recognised in month 1?▼
The example treats implementation as a distinct service satisfied at a point in time, and the engine places point-in-time obligations in month 1. In practice, timing follows when control transfers, which is a judgement for the entity and its auditor.
Does every SaaS schedule need a final-month remainder?▼
No. A remainder month is only needed when the allocated amount does not divide evenly into whole cents across the term. Here $110,880 / 36 = $3,080 exactly, so every month is equal.