Pricing & Revenue Recognition: Two Sides of a Very Valuable Coin

Determining the right pricing model for a product is never easy. Successful companies are those that think of pricing and packaging in the same way that they think about product development – their pricing is in a constant state of evolution. It’s never 100% done.

The elements that go into pricing design, the trade-offs you make, and the objectives and outcomes that your pricing and packaging decisions must meet evolves as a company grows. But, one consideration that teams responsible for pricing and packaging often overlook is how their pricing and packaging decisions are interpreted for the purposes of revenue recognition.

Look at how pricing and deal structures are interpreted differently under the new ASC 606/ IFRS 15 accounting guidelines going into effect in fiscal 2018. Microsoft, one of the very few companies that was able to adopt the standards early says the impact on its income statements and balance sheets will be material. Revenues for 2017 and 2016 are expected to increase by around $6B and assets will rise by about $9B, while liabilities will fall by about $6B and $2B, respectively.

Amazon has pointed out the impact in its July SEC filing stating that it won’t be able to account for revenues the way it usually does. The changes particularly impact “Amazon-branded electronic devices sold through retailers, which will be recognized upon sale to the retailer rather than to end customers, and the unredeemed portion of our gift cards, which we will begin to recognize over the expected customer redemption period, which is substantially within nine months, rather than waiting until gift cards expire or when the likelihood of redemption becomes remote, generally two years from the date of issuance.” At the end of 2016, Amazon’s liability for unredeemed gift cards was $2.4B.

There is a lesson here for all of us. As companies race to adopt the new revenue recognition standards, this is also a time to take a fresh look at how pricing teams and revenue teams collaborate going forward. To better understand how pricing and revenue are inextricably linked, let’s examine four common pricing concepts and their associated revenue implications: Contract Structures, Sales Price vs SSP, Bundling and Discounting, and Usage Pricing.

Different Contract Structures Have Different Revenue Impacts

There are instances where different contract structures may have different revenue impacts under the old standards vs the new standards. For example, many SaaS companies offer “ramp deals” where the annual fee paid by a customer increases in later years.

Under the old guidelines, the revenue you recognized over multiple years of a ramp period might have followed the pattern of your pricing structure, i.e. you recognized lower amounts in the early years, and higher amounts in the later years as the price ramped up. However, under the new guidelines, license fees may need to be spread evenly over the life of a contract, meaning that under certain circumstances, vendors might actually recognize more revenue earlier on.

Earlier this year according to a Financial Times article, Microsoft had indicated that this will have a material impact on them as sales of Windows 10 licenses, which are currently treated as a rateable license fee spread over a number of years and are all recognized upfront. And as noted above, Microsoft has since adopted the new standards and expects an increase in revenues for 2017 and 2016. No doubt some of this increase was a result of how certain contract structures are interpreted under the new guidelines.

Understanding the impact of different contract structures on revenue is key. In order to do this effectively, make sure you are:

• Equipped to calculate effective revenue price…at scale
• Communicating what critical data you need your sales teams or order management teams to capture
• Equipped to automate the process of evaluating how existing open contracts might have different revenue treatments under the new guidance vs the old guidance

There’s The Price You Use For Sales, And Then There’s SSP

The price at which you sell a product or service to a customer may not always be the same price that is used for revenue recognition. It’s important to understand what impact your pricing/bundling/discounting decisions may have on the calculation of Standalone Selling Price (SSP). In a number of cases, your accounting team will use SSP and not your sales price to calculate the revenue that can be recognized for a particular product or service.

Let’s look at an example: In a typical volume based pricing model, the price to be charged is based on the volume purchased. This type of a pricing model often rewards customers with built-in discounts as they purchase more volume. The more you buy, the cheaper per-unit-price you get. So, if a customer purchases between 0-50 software licenses, they might be charged a per unit price of $120/unit/year. However, if the customer purchases between 51 – 100 units, they might be charged a per unit price of $100/unit/year.

Now, this gets interesting on the revenue recognition side since SSP for this type of a pricing model could be calculated in different ways:

• A simple formula (cost plus, % off list price, etc.) OR
• Historical analysis of selling price (often stratified by region, customer type, etc. based on your selling and discount models)

And once SSP is determined, some companies might choose to assume the same SSP per unit across all volume bands in the example above while some others may choose to assume a tiered SSP for each volume band.

It’s clear that determining and applying SSP is not trivial and simply defining a list price for a product or service is only half the battle.

Tracking and understanding how consistent your established list price is compared to your typical sales price can be extremely valuable. And it’s beneficial for pricing teams and revenue teams to jointly evaluate this consistency on a regular basis to drive future pricing decisions. You can make the process easier by automating the following:

• Collection, analysis, and application of your historical data to future contracts
• Determination of pricing compliance rates and bands
• Application of a rules based formula to calculate SSP for different revenue elements in different scenarios

Bundling And Discounting Complicate Revenue Recognition

Say your company prices software at $800 per year and training at $200 per year. If you decide to bundle those two services together and sell the software at a discount for $500 while throwing training in for free, does that mean the training has no value in terms of generating revenue? The new revenue standards require companies to both estimate the SSP of each individual offering and allocate the total transaction price of the contract across each offering based on the relative SSP.

Here’s how the above example would play out:

• The SSP for the software is $800 while the SSP for training is $200.
• When you bundle Software and Training together, 80% of the bundle is allocated for software while 20% is allocated for training.
• Because the customer paid a total of $500 for that contract, the total Transaction Price is $500.
• Since the Transaction Price of this particular deal was $500, 80% of it ($400) will be allocated to revenue for software while 20% ($100) will be allocated to revenue for training.

There’s plenty of guidance on how to calculate allocations for bundled deals, but imagine implementing such advice for thousands of contracts without an automated solution. This will not only drown your revenue team but will also slow down the pace at which you can roll out any changes to pricing and bundling.

Thinking about implementing a new packaging or bundling strategy? Ask yourself:

• Do we have the ability to automate the process of systematically separating (or “exploding”) bundles into distinct elements?
• Do we have the ability to automate the process of determining and applying SSP to each element in a bundle?
• Do we have the ability to automate the process of allocating the transaction price of a deal across the different elements within a bundle?

Without these, your pricing and bundling decisions could end up creating a revenue nightmare for your finance teams.

Usage Pricing Models Need To Be Carefully Considered

The popularity and market demand for usage-based (or consumption) pricing models is on the rise. Our data shows that at least 40% of Zuora customers use some form of usage pricing model. Just as you would never implement usage pricing without considering the metering and rating aspects of billing for that usage, make sure you don’t ignore the revenue recognition implications of your usage pricing models.

When implementing a usage-based pricing model, keep in mind that there may be scenarios where revenue recognition for the usage-based service can only happen when usage occurs. This is often the case when it’s determined that the vendor’s obligation to provide service to a customer is only satisfied as and when the service is consumed.

In many instances of usage based pricing models, the transaction price to be used for revenue recognition isn’t available at the inception of the contract (since you don’t know how much usage the customer will consume yet). So your finance team may need to estimate the variable element of your obligation to the customer, and true-up each period. This is called “Variable Consideration”, and can be a fairly complex exercise, especially when dealing with large volumes of transactions.
Want to implement a usage based pricing model? Ask yourself:

• Can we automate the process of determining the variable consideration at the outset of a contract by utilizing existing data elements and applying them to common scenarios?
• Can we automate it for different types of usage based models (tiered usage, volume usage etc)?

We live in a world where a plethora of new monetization models are now possible. Now more than ever, it is critical for pricing and revenue teams to collaborate closely to connect the dots between the pricing and packaging needs of the business and the resulting impacts on revenue operations and revenue outcomes.

Revenue teams should always understand the business motivations behind different pricing or packaging models, and Pricing teams should always understand the revenue implications of their pricing and packaging decisions. Without this close alignment and collaboration, finance teams will find themselves living with the revenue nightmares resulting from creative pricing and packaging choices. Or worse yet, finance teams will begin to push back on certain pricing models because they don’t have the means to automate revenue recognition for these pricing scenarios at scale.

So, how can the two teams collaborate and contribute towards growth? Consider these simple suggestions:

• Include revenue team representatives on your Pricing Committee.
• Establish templates and processes to model deals from sales all the way through revenue.
• Ensure that revenue team representatives are involved in deal structuring or consider a materiality threshold to include revenue teams during the deal structuring process to avoid downstream issues.
• ASC 606/IFRS 15 is new to everyone – Use this opportunity to evolve the way your revenue and pricing teams work together.
• In the revenue world, it is NOT easier to ask for forgiveness rather than permission. Always strive for a solution that works for both sales/pricing and the company’s revenue recognition policies.

Learn about Zuora RevPro, our revenue-recognition automation software and how it can help your business!