How Do You Recognise Revenue for Standalone Selling Price (SSP)?

For accountants managing complex revenue recognition scenarios under ASC 606/IFRS 15, accurately allocating transaction prices to performance obligations based on standalone selling prices (SSP) is often one of the most demanding tasks. In this blog, I will dive into how SSP impacts rev rec in multi-element arrangements and highlight key considerations for navigating these complexities.

What is standalone selling price (SSP)?

Under ASC 606/IFRS 15, transaction price is the total amount of consideration (money or value) an entity expects to receive for transferring goods or services to a customer. It’s typically specified in the contract.

When a contract includes multiple products or services (a bundle), you cannot recognize the full transaction price against just one item. Instead, you must allocate it across the different performance obligations based on their individual value — this is where Standalone Selling Price (SSP) comes in.

SSP is the price at which a company would sell a good or service separately to a customer. Think of it as the fair value of each individual product or service in the bundle. You use relative SSP to split the overall transaction price proportionally, based on the standalone value of each item.

In short:

• Transaction Price = Total contract value.
  
• SSP = Value of each product/service if sold individually.
  
• Revenue allocation = Splitting the transaction price between products based on their SSP.

If you have a bundle, you bifurcate revenue by the standalone value of each product. 

How does allocation of transaction prices based on SSP work?

Scenario:

A company sells a bundle of products/services that includes:

1. A Software License (delivered at the start)
2. 12 months of Technical Support (delivered over time)
3. A Setup Service (completed at the start).

The bundle price is $10,000, but each element has its own standalone selling price (SSP):

• Software License: $7,000
• Technical Support: $2,000
• Setup Service: $1,500

Step 1: Calculate total SSP

The total SSP for the bundle is calculated as:

Total SSP = 7,000 + 2,000 + 1,500 = 10,500

Step 2: Calculate allocation percentage

Each item's allocation percentage is:
Allocation Percentage = SSP of Item/Total SSP​

• Software License: 7,000 / 10,500=66.67%
• Technical Support: 2,000 / 10,500=19.05%
• Setup Service: 1,500 / 10,500=14.29%

Step 3: Allocate transaction price ($10,000)

Allocate the transaction price ($10,000) based on the percentages:

• Software License: 10,000×66.67%=6,66710,000×66.67%=6,667
• Technical Support: 10,000×19.05%=1,90510,000×19.05%=1,905
• Setup Service: 10,000×14.29%=1,42810,000×14.29%=1,428

Step 4: Final allocation

The $10,000 transaction price is allocated as follows:

1. Software License: $6,667 (recognized at the start)
2. Technical Support: $1,905 (recognized over 12 months)
3. Setup Service: $1,428 (recognized at the start)

This ensures that the total $10,000 is allocated accurately across the different components.

How does allocation of discounts based on SSP work?

At the end of a reporting cycle, accountants need to show which products generated how much revenue. If customers have been given discounts on bundles, those discounts must be split across products based on their Standalone Selling Prices (SSP). This helps allocate revenue accurately and lets businesses assess true profitability.

When a customer receives a discount for buying a bundle of goods or services, the discount should typically be allocated proportionately to all performance obligations based on SSP — unless there’s clear evidence that the discount applies only to specific products.

For example:
A retailer sells a chair, a couch, and a table for $5,400 as a bundle. Normally, the standalone prices are:

• Chair: $2,000
  
• Couch: $3,000
  
• Table: $1,000
  

The total standalone price would be $6,000, so the customer is getting a $600 discount ($6,000 - $5,400).

How much revenue will be recognised and how to allocate it?

The retailer has observable evidence that the $600 discount applies only to the chair and couch. These two items are regularly sold together for $4,400 (after a $600 discount). The table is usually sold separately for $1,000, with no discount.

Thus, the retailer allocates the $5,400 transaction price like this:

• Chair and Couch (bundle): $4,400
  
• Table: $1,000

What if the retailer sold all three as a bundle?

If the retailer regularly sold the chair and couch together for $4,400 (with the $600 discount) and the table is normally sold at $1,000 without discounts, the allocation remains based on that split.

How should the retailer allocate the transaction price to the products?

However, if the table and couch were also regularly discounted when sold together, it would no longer be clear which items the discount applied to. In that case, the discount would have to be allocated proportionately across all three products based on their SSP.

Conclusion: From this example, the key takeaway is:

• The retailer grouped products based on clear sales patterns — the chair and couch could be bundled together, while the table stood alone.
  
• Discounts should only be specifically allocated when observable evidence supports it. Otherwise, they must be spread across all products proportionally.

Why is variable pricing excluded from SSP-based allocation?

Under ASC 606/IFRS 15, variable consideration (like usage-based pricing) is excluded from the SSP-based allocation process because the final amount is not fixed or known at the time of contract inception.

When you allocate a transaction price based on Standalone Selling Prices (SSP), you need stable, known prices to split the revenue correctly among performance obligations. But with usage-based billing — such as fees that depend on future usage, performance, or outcomes — the exact amount is uncertain.

The standard says that an entity can allocate the entire variable amount to a specific performance obligation if both of these conditions are met:

1. The variable payment relates specifically to one performance obligation or a distinct good/service.
   
2. Allocating the entire variable amount to that obligation is consistent with the overall objective of fairly allocating the total transaction price.

For usage-based or outcome-based products (like a cloud storage service billed per GB used), the variable revenue is tied directly to the service delivered. It makes sense to allocate that revenue only to that specific service, not spread it across other products based on SSP. Since the actual final price is unknown upfront, including it in SSP allocation would distort revenue recognition.

Methods to Identify SSP

In my experience, there are multiple methods for identifying the SSP of a product. Some of the commonly used ones are:

1. Similar market value approach

This approach involves looking at your company's own products or services that are similar to the product being sold and using their selling prices as a benchmark. Adjustments are made if there are differences in features, functionality, or customer segments. The idea is to rely on internal pricing evidence rather than external market data.

For example, suppose your company sells a new type of software license that isn’t sold on a standalone basis yet. However, you already sell other software licenses individually. You would examine the standalone prices of these similar products. If the new license includes more advanced features or serves a different customer segment, you would adjust the price upwards or downwards accordingly.

2. Fair market value approach 

This method involves looking at the prices at which products or services are sold in the market, and adjusting for differences that may exist between the product being sold and those available in the market. The idea is to find the most reliable market prices and make necessary adjustments based on factors such as geographic location, customer base, or distribution channels.

For example, let’s say your company sells software licenses, and there are similar software licenses sold by competitors. You’ll first examine the prices at which these competitors are selling their licenses. However, if your software has certain additional features or benefits that the competitors do not offer, you might adjust the price upwards to reflect the additional value. Conversely, if your product is less feature-rich or positioned for a different market segment, you might adjust the price downwards.

3. Expected cost plus a margin

It involves determining the cost of providing the good or service and then adding a reasonable margin to arrive at the SSP. The margin added reflects the company's expected profit for providing the product or service.

Here's how it works:

• Expected Cost: The company first estimates all the direct and indirect costs involved in producing and delivering the product. This might include manufacturing costs, labor, marketing, and distribution expenses.
  
• Margin: After calculating the costs, a standard margin is applied based on historical profit margins or industry standards.
  

For example, if it costs $100 to produce a piece of software and the company wants to earn a 30% margin, the SSP for that product would be calculated as:

💡SSP = Cost + (Cost × Margin) = 100 + (100 × 30%) = 100 + 30 = 130

This approach is particularly useful when a company has no direct market data to rely on, or when its product is unique and doesn’t have a direct market counterpart.

4. Residual approach

This approach is used when the price of a product or service is not directly observable, or when it is difficult to determine the standalone selling price. Essentially, the company will subtract the prices of known items (those whose SSPs are easily determinable) from the total transaction price, and allocate the remaining value to the product or service whose price is not directly observable.

For example, imagine a contract where a company sells a bundle of two products. One product's price is easily determined based on market research (let's say $2,000). The total contract price is $6,000, but the price of the second product is not directly observable. Using the residual approach, the company would subtract the known price from the total contract price:

💡Residual Price = Total Contract Price - Known Price = 6,000 - 2,000 = 4,000

In this case, the SSP for the second product would be considered $4,000, allocated to that specific product.

Each of these methods has its own application depending on the scenario and the data available.

How does Zenskar automate revenue recognition for SSP?

➡️Upload customer contracts directly into Zenskar. 

➡️Payment terms, services, products, transaction prices, and product-level pricing are pulled directly from contracts using our AI contract ingestion feature — no manual re-entry required.

➡️Contracts feed automatically into the revenue recognition system, ensuring full traceability from contract to cash.

➡️Zenskar enables you to create bundles consisting of multiple products, with a specific pricing model assigned to each product within the bundle. 

➡️For each product, its Standalone Selling Price (SSP) is determined independently, based on its pricing model.

➡️Once the SSP for each product is established, Performance Obligation creation is applied to each individual product. 

➡️The total transaction price (or bundle price) is then automatically allocated across POBs based on their relative SSPs.

➡️Revenue is recognized in strict compliance with ASC 606/IFRS 15, ensuring each product’s contribution to the bundle is accurately captured.

Want a demonstration of how Zenskar automates rev rec? Reach out and schedule time for a personalized walkthrough or take an interactive product tour to see Zenskar in action.