Pricing and revenue recognition
Revenue recognition seems like one of those dull technical topics, better left to accountants and the CFO, and not all that relevant to the business design. This is a limited way of thinking. Lack of attention to revenue recognition can damage a business. Just ask the investors in Saba Software which was delisted and sold to private equity largely as a result of revenue recognition issues in its services business.
Fear is a good reason to pay attention to revenue recognition, but there are positive aspects to this as well. Good design is aware of the constraints within which it operates. Pricing is something one designs, ‘Don’t set prices. Design pricing!.’ Revenue recognition rules are a useful framework to help you think through the design of your pricing.
Let’s take a look at the basics of revenue recognition under IFRS (International Financial Reporting Standards) which has replaced GAAP (Generally Accepted Accounting Practices). The relevant section is IFRS 15.
Here is a simple overview from the Corporate Finance Institute.
What are the conditions for Revenue Recognition?
According to the IFRS criteria, for revenue to be recognized, the following conditions must be satisfied:
Risks and rewards have been transferred from the seller to the buyer.
The seller does not have control over the goods sold.
The collection of payment from goods or services is reasonably assured.
The amount of revenue can be reasonably measured.
Costs of revenue can be reasonably measured.
Conditions (1) and (2) are referred to as Performance. Regarding performance, it occurs when the seller has done what is to be expected to be entitled to payment.
Condition (3) is referred to as Collectability. The seller must have a reasonable expectation that he or she will be paid for the performance.
Conditions (4) and (5) are referred to as Measurability. Due to the accounting guideline of the matching principle, the seller must be able to match the revenues to the expenses. Hence, both revenues and expenses should be able to be reasonably measured.
Pricing is the combination of performance and measurability. Pricing needs to be based on the performance of a service or provision of a good that has value to the buyer, and the price must be measurable in some way.
One of the critical questions is whether revenue should be recognized at a point in time or over time. This question parallels one of the key questions in pricing design. Should there be a one-time fee on performance (which covers everything from software license, to the provision of professional services, to transactional models) or should there be a fee for access to a service over time?
Subscription pricing models basically assume that revenue is collected and recognized over time. When can we do this? IFRS 15 has three criteria for when revenue should be recognized over time (from BDO ‘Does IFRS 15 change the pattern of revenue recognition?’)
How is revenue considered recognized?
The customer simultaneously receives and consumes the economic benefits provided by the vendor’s performance
Typically applies to contracts for services
The concept of control of an asset applies because services are viewed as an asset (momentarily) when they are received and used or consumed
Consider whether another vendor would need to substantially re-perform the work completed to date
Cleaning services
Transportation services
May apply for some professional services
The vendor creates or enhances an asset controlled by the customer
Typically applies when an asset (tangible or intangible) is being constructed on the customer’s premises
A building constructed on land owned by the customer
Customised software written into a customer’s existing IT infrastructure
(1) The vendor’s performance does not create an asset for which the vendor has an alternative use; and (2) The vendor has an enforceable right to payment for performance completed to date
Typically applies to construction/development of assets to customer specifications
Consider the terms of the contract and any relevant laws or regulations
Construction and real estate (developers)
Manufacturing/engineering contracts for customised products/assets
Some advertising and professional services
Software development projects hosted on the vendor’s servers while under development
The criteria that would govern most SaaS subscriptions is 3) ‘The vendor’s performance does not create an asset for which the vendor has an alternative use.’ This seems like a bit of a stretch, and one wonders if the IFRS were really designed for the world of digital assets (where copying is virtually cost free) and digital services, where many people can use what is virtually the same service simultaneously. Revenue recognition does provide a useful way to classify pricing models, and there is a straightforward mapping from one to the other. Making this mapping explicit is a useful step in pricing design and can provide some structure to conversations between the CFO and pricing leaders.
Zuora, a leading company in the subscription economy and organizer of the popular Subscribed conference, has a revenue recognition solution for subscription pricing called Revpro. This application is a good way to model out the revenue recognition implications of different subscription models.
The real challenges come up when one needs to blend different pricing models. Many modern pricing systems combine two or even all three of the different approaches. Imagine a system that requires professional services (where revenue is recognized at point of performance), complex configuration (where revenue is recognized on transfer of control) and a subscription. That describes many large enterprise systems. Making sure each revenue component can be clearly mapped to the correct revenue recognition policy is critical and needs to be considered in both the pricing design and in the contracts.
In The Strategy and Tactics of Pricing by Thomas Nagle and Georg Müller there is a classic figure showing how to choose a pricing metric (the unit in which one prices). I am tempted to add another layer here ‘optimizes revenue recognition.’
The product and delivery model should clearly align to revenue recognition.
When designing a pricing model it is critical to factor in revenue recognition and make sure that legal, finance and pricing are in alignment.
Ask, the following as you design your pricing model:
What are the revenue recognition goals? Are you trying to bring forward revenue recognition or spread it over time?
Which of the three revenue recognition principles are you applying to each aspect of your revenue model?
Does your delivery plan map to your revenue recognition model?
Are the pricing, revenue recognition and delivery model aligned in your contracts and invoices?
Revenue recognition may seem like an obscure topic, only of relevance to the CFO and legal team. It is not. It actually provides some useful ways of thinking about the design of pricing and delivery models. It is a critical lens into pricing best practices.