How to use the expected cost plus margin approach

When a SaaS company never sells onboarding or implementation on its own, there is no observable price to use as its standalone selling price. The expected cost plus margin approach fills that gap: forecast what it costs to deliver the service and add a margin you can support. This post covers when to use it, which costs to include, how to set the margin, and a worked $63,000.00 bundle, so the estimate holds up when a reviewer re-performs it.

What is the expected cost plus margin approach?

It is one of the three SSP estimation methods in ASC 606-10-32-34: forecast the expected cost of satisfying a performance obligation, then add an appropriate margin. The result is the price you would expect to charge if you sold that item on its own. See the glossary definition.

The other two methods are the adjusted market assessment, which starts from market prices, and the residual approach, which is only allowed when an SSP is highly variable or uncertain. The standard asks you to maximise observable inputs and apply the chosen method consistently to similar situations (ASC 606-10-32-33).

When should you use it?

Use expected cost plus margin when there is no reliable observable standalone price and the cost of delivering the obligation can be estimated, which is typical for services delivered by your own people: implementation, onboarding, training and premium support. It is a weak fit for software subscriptions, whose cost to serve is low and says little about price.

If you do have standalone sales of an item, use them. An observable price beats an estimate.

Which costs go into the estimate?

Include the costs you expect to incur to satisfy the obligation: direct labour hours times a loaded hourly cost, third-party costs such as subcontractors or tools bought for the engagement, and a reasonable share of overhead that relates to delivery. Base the hours on actual delivery data where you have it, not on the hours quoted to the customer.

A cost build that a reviewer can follow usually shows:

1. Hours by role, from time-tracking on similar past projects (for example, the median of the last 20 onboardings).
2. Loaded cost per hour by role: salary, benefits and payroll taxes, divided by available hours.
3. Direct third-party costs, if any.
4. Delivery overhead allocated on a stated basis.
5. The date and the data period the build is based on.

Leave out costs that do not relate to delivery, such as sales commissions, and keep the build consistent across contracts.

How do you set and support the margin?

Set the margin from evidence of what the market would pay: the margin you earn on similar services that you do sell on their own, margins of competitors or service partners who sell comparable work, or pricing studies. Be explicit about whether it is a markup on cost or a margin on price, because the two give different SSPs.

The difference matters. On a cost of $5,700.00:

• A 40% margin on price gives SSP = $5,700.00 ÷ (1 − 0.40) = $9,500.00.
• A 40% markup on cost gives SSP = $5,700.00 × 1.40 = $7,980.00.

Write down which one your policy uses and apply it the same way every time. If the evidence supports a range rather than a point, document the range and how you choose within it; see SSP range.

How does it work on a $63,000 contract?

Take a 12-month contract priced at $63,000.00: a platform subscription with an observable SSP of $60,000.00, plus onboarding delivered in month 2. Onboarding is never sold alone, so its SSP comes from cost plus margin: 60 hours × $95.00 loaded cost = $5,700.00, at a 40% margin on price, giving $9,500.00. Total SSPs are $69,500.00, so the $6,500.00 discount is spread pro rata.

The subscription's exact share is $63,000 × 60,000 ÷ 69,500 = $54,388.489…, rounded half-up to $54,388.49. Onboarding, the last line, takes the remainder, $8,611.51, so the allocation ties to $63,000.00.

The subscription recognises $4,532.37 for 11 months and $4,532.42 in month 12, so the final month absorbs $0.05 and deferred revenue ends at $0.00. Onboarding is recognised in month 2, when it is completed, not when it is invoiced. 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 do auditors ask about cost-plus SSPs?

Auditors usually ask where the hours came from, how the loaded rate was built, why the margin is reasonable, whether the same method was applied to similar contracts, and when the estimate was last refreshed. A cost build tied to time-tracking data and a margin backed by external or internal evidence answers most of these questions before they are asked.

Typical requests:

• The hours data and the projects it came from.
• Payroll support for the loaded cost.
• The source of the margin and whether it is on price or on cost.
• Evidence the method is applied consistently, and the review date.
• A sensitivity check: does a reasonable change in margin move the allocation materially?

For a broader list of review points, see what SSP allocation mistakes auditors flag.

How does Soluqube help with cost-plus SSP allocation?

Soluqube takes the SSPs you have confirmed, including a cost-plus estimate, and does the allocation and schedule. It allocates the contract price by relative SSP in integer arithmetic, rounds to the cent with a named line taking the residual, builds a schedule whose final period absorbs the remainder, and exports the result with a SHA-256 hash so a reviewer can re-check it.

• You set the SSP; Soluqube does the arithmetic. It does not estimate costs or margins for you. The SSP basis is recorded in the workbook so the reviewer sees where each figure came from.
• Clause evidence: each obligation carries the contract page and verbatim excerpt; uploaded PDFs with a text layer show the cited line highlighted. Extracted terms are heuristic and need your confirmation.
• Deterministic: the same inputs produce the same allocation, schedule and hash.
• Scope: ASC 606, and Ind AS 115 with 18% GST kept out of the transaction price on INR contracts. Contract modifications are flagged for manual review, not accounted for.

To see it on your own bundles, send three contracts through the design partner programme for a free 3-contract workpaper. Founding prices for the first 10 customers are on pricing.