What SSP allocation mistakes do auditors flag?

SSP allocation is where many ASC 606 review comments start, and most of them are not about arithmetic. They are about an SSP with no evidence behind it, a service folded into the subscription, a discount placed on one line without support, or a schedule that does not end at zero. This post lists ten mistakes grouped by where they happen in Step 4, then shows a clean allocation on a $186,000.00, 36-month contract run through the Soluqube engine. The list comes from the standard's requirements, not from a survey, so use it as a checklist rather than a ranking. For how SSP allocation works end to end, see our ASC 606 SSP allocation guide. Key terms: standalone selling price, relative SSP method and performance obligation.

What counts as an SSP allocation mistake?

An SSP allocation mistake is any gap that stops a reviewer re-performing Step 4 and reaching the same numbers. It can sit in the SSP estimate, in the list of performance obligations, in the arithmetic or in the schedule. Judgement and evidence gaps usually draw the most questions; a stray rounding cent is normally below materiality.

ASC 606-10-32-28 sets the objective: allocate the transaction price in an amount that depicts the consideration the entity expects for each promised good or service. ASC 606-10-32-29 and 32-31 make relative SSP the default way to get there. Every mistake below is a place where the file stops showing how that objective was met.

Which mistakes happen when estimating SSP?

The three estimation mistakes are using a list price that every deal discounts as the SSP, recording a figure with no source behind it, and leaving SSPs unchanged for years. ASC 606-10-32-32 and 32-33 point to observable prices first, then estimates that maximise observable inputs and are applied consistently.

1. A list price nobody pays. If every customer gets a discount from list, the list price is weak evidence of what the item sells for on its own. Use prices from actual standalone sales, or an estimate under ASC 606-10-32-34. See observable price.
2. No source next to the figure. An SSP with no standalone sales data, market assessment or cost build beside it cannot be traced. Record the method and the data on the same row as the number.
3. Stale SSPs. A study run once and never refreshed drifts away from current pricing. Existing contracts are not reallocated for later SSP changes (ASC 606-10-32-43), but new contracts need current figures, and the review date belongs in the file.

Which mistakes happen when identifying obligations?

The two identification mistakes are folding a distinct service, such as onboarding or training, into the subscription, and leaving out a promise because the order form shows no price for it. Both change the allocation before any arithmetic starts, because the distinct test in ASC 606-10-25-19 decides which items get an SSP at all.

4. Merging a distinct service into the subscription. Onboarding or training that the customer can benefit from and that does not significantly modify the software usually passes ASC 606-10-25-19 and 25-21. Our post on whether SaaS training is a separate performance obligation walks through the test.
5. Ignoring a "free" promise. An item included at no charge is still a performance obligation if it is a distinct promise. It takes a share of the transaction price by relative SSP, which moves revenue out of the other lines.

Which mistakes happen in the allocation arithmetic?

The three arithmetic mistakes are pushing the whole discount onto one line without meeting ASC 606-10-32-37, using the residual approach where 32-34(c) does not allow it, and multiplying by rounded weights instead of exact ratios. Each one moves revenue between obligations, and the last can leave the allocation not tying to the contract price.

6. Discount on one line without support. ASC 606-10-32-36 spreads a discount pro rata by default. Placing it on some obligations only needs all three 32-37 criteria to be met and documented. Our post on how a bundle discount is allocated covers both cases.
7. Residual approach as a shortcut. It is limited to SSPs that are highly variable or uncertain. Where observable prices or a reasonable estimate exist, the residual result is not the allocation the standard asks for. See residual approach.
8. Rounded weights and no rounding rule. A weight shown to two decimals and then multiplied can give a different amount from the full ratio. Keep exact ratios, round the amounts, and write down which line takes the residual cent. Our post on where the rounding cent goes shows cases where it is not zero.

Which mistakes happen in the revenue schedule?

The two schedule mistakes are recognising a point-in-time item when it is invoiced or when the contract starts, instead of when control transfers, and building monthly amounts that leave a balance in deferred revenue after the last month. The first is a cutoff question under ASC 606-10-25-30; the second is a tie-out failure that a reviewer can spot quickly.

9. Point-in-time items on the wrong date. Onboarding delivered in month 2 is recognised in month 2, not on the invoice date. Keep delivery evidence, such as a sign-off, dated within the period. See point-in-time recognition.
10. A schedule that does not end at zero. Equal monthly amounts rounded to the cent rarely add up to the allocation exactly. Round each month down and let the final month absorb the remainder, so deferred revenue ends at $0.00. See terminal-period remainder absorption.

What does a clean allocation look like on a $186,000 contract?

Take a $186,000.00, 36-month contract starting November 2026 with four obligations whose SSPs total $231,000.00. The Soluqube engine spreads the $45,000.00 discount pro rata and allocates $144,935.06, $14,493.51, $21,740.26 and $4,831.17, which ties to $186,000.00. Deferred revenue ends at $0.00 in month 36.

Here is how the example avoids the mistakes above:

• Mistake 6: the discount is spread pro rata across all four obligations, because nothing in the contract supports placing it on one line.
• Mistake 8: each line except the last is rounded half-up to the cent, and admin training, the last listed obligation, absorbs the residual cent. The amounts are quoted, not the weights.
• Mistake 9: onboarding is recognised in month 2 and admin training in month 3, the months the scenario sets for delivery, not in month 1.
• Mistake 10: the subscription recognises $4,025.97 for 35 months and $4,026.11 in month 36, so the final month absorbs $0.14. Premium support recognises $603.89 for 35 months and $604.11 in month 36, absorbing $0.22.

Total recognised is $186,000.00. The engine result's SHA-256 hash is 02fc241e81f1da732a63fbb31eec1626f54228831e4389a4fc18bff6b1f3e964. This schedule is engine behaviour: the app's upload workbook gives the same allocation but puts every point-in-time item in month 1. You can re-perform the allocation in the SSP allocation calculator.

What should the SSP file hold before fieldwork?

Before fieldwork, the SSP file should let a reviewer trace every number back to a source without asking. That means the contract clause for each obligation, each SSP with its evidence, the allocation and its written rounding rule, a schedule that ends at $0.00 deferred, and a note of each judgement and who approved it.

A file built that way usually has:

1. The contract price and each obligation, with the clause page and verbatim excerpt that supports it.
2. Each SSP, its method under ASC 606-10-32-34 and the date it was last reviewed.
3. The distinct assessment for every service line, including any item sold at no charge.
4. The discount treatment, and the 32-37 analysis if the discount is not spread pro rata.
5. The allocation, the rounding rule and the monthly schedule, tied to the contract price.

Terms pulled from a contract by software, including Soluqube's heuristic extraction, still need a person to confirm them before they go into the file. The sample SSP workpaper shows the structure as a finished document.

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, a page and verbatim excerpt for each obligation, and a hashed export.

Founding prices for the first 10 customers are a free 3-contract workpaper, a $475 audit workpaper for up to 10 contracts, a $1,750 QoE deal pack and $49/month firm tool access. Details are on pricing. The engine doesn't model contract modifications, variable consideration or billing schedules yet, so treat those topics as guidance only.