From January 1st, 2018 onwards, IFRS15/ ASC 606 Revenue from Contracts with Customers / revenue recognition rules need to be applied by a majority of companies worldwide.
This new rules are being jointly issued by the International Accounting Standard Board (IASB) and the US Financial Accounting Standard Boards (FABS). The expectation is that for high tech companies it will have the same level of impact as the Y2K.
Replacement of multiple revenue recognition models with a single model
High tech companies have a diverse range of product and service offerings, with many different ways of bundling them. This has led to the creation of industry-specific revenue recognition models like US GAAP: ASC 605 Revenue, FASB ASC 985 Software, IFRS: IAS 18 - Revenue, IFRIC 13 Customer Loyalty Programs in the past. Each of these models created their own revenue recognition challenges within different segments of the high tech industry.
IFRS15 will replace these various models with one singe revenue recognition model.
This requires every high tech company to evaluate what impact IFRS15 will have for them. This impact goes far beyond technical issues to cover significant understanding of the new rules, impact on operational processes including compensation and commission structures or sales methodologies and practices as described in this blog.
What will be the impact on companies in the High Tech industry?
In discussing with customers, it has become clear that the different sub-segments of High Tech might be impacted differently. Software providers and original equipment manufacturers (OEM) that are selling bundled solutions are facing major changes. While Semiconductor companies and companies that have more of an invoice driven revenue recognition seem to be less affected.
Let’s take a closer look at sales models that might face major impact in Revenue Recognition with IFRS15:
Solution Selling – High Tech companies are moving from selling products to selling solutions. This results in contracts that include different offerings such as hardware, software and services which are inter dependent and are called multi-element arrangements.
For multi-element arrangements different things need to be considered with IFRS15:
Companies will have to determine if items in a contract are distinct and therefore require separate performance obligations that need to be handled separately throughout revenue recognition
Allocation of transaction prices to different performance obligations in a contract will be based on so called standalone selling prices. This will determine the basis for distribution of the revenue. Determination of standalone selling prices is often a complex task e.g. considering variable pricing for software.
Furthermore when determining the transaction price variables considerations like contract renewals, incentives, discounts, rebates or potential returns might need to be taken into account
Software Sales – Also software companies often have contracts with multi-element arrangements and the related challenges that were described above. Today software companies might treat the development of software and delivery of maintenance services as a single revenue item.
However with IFRS15 companies that sell software licenses might need to track different performance obligations for Software and Maintenance. They might recognize revenue for software licenses immediately, while they will recognize revenue over time for maintenance.
Sales through Distributors and Resellers - Companies that sell-through distributors or resellers under current guidance often recognize revenue when the risk and rewards of the goods or services are transferred to the customer (sell-through). With IFRS15 it might change to the time when control of goods or services are transferred to the customers (sell-in).
All of these new requirements might result in:
More or in some cases fewer performance obligations
Different timing – either acceleration or delay of recognizing revenue.
More variable considerations
All of this will require significant changes to processes and systems that support revenue recognition.
Impact of business model transformation on Revenue Recognition
In parallel, the high tech industry is seeing key changes of business models this is also resulting in further revenue recognition challenges for companies.
I want to highlight two of them and their effect on revenue recognition and systems that support these.
Cloud models – software as a service - The switch from selling perpetual software licenses to a provider of cloud software is happening to many software companies, which results in a different revenue recognition model. In a cloud business with subscription models, revenue should be recognized over time rather than as a one off revenue event. This sort of business model often results in a Business to consumer challenge with a higher volume of lower value transactions which revenue departments must support.
Consumption based models – With the shift to be service providers, some high tech companies are introducing business models with consumption based pricing based on outcomes. For example a printer company many no longer sell a printer, they rather price and bill for each page printed. For these scenarios it is essential that there is a system in place, which can cope with higher volumes and uses an automated rule based revenue recognition engine.
How SAP addresses these challenges
SAP has introduced a new revenue recognition engine, SAP Revenue Accounting and Reporting (SAP RAR). This solution was developed specifically for the new standard and was developed in close collaboration with many high tech customers.
The solution decouples the sales and billing operational process from the revenue accounting. It is therefore non-disruptive to operational processing. All transactional activity e.g. orders, deliveries, invoices can be funneled into SAP RAR from any source. This could be SAP but also non-SAP systems. SAP RAR automatically determines the performance obligations and the transaction price. When the revenue is able to be recognized SAP RAR generates the compliance journal entries and posts to the G/L (acts as a sub-ledger). In addition the solution provides compliance reporting.
See the links below for further information on this solution: