IFRS15 Revenue Recognition – How’s it going for you?

I remember a conversation on one of my early ERP implementations for a Scottish micro wave transmitter manufacturer that had just been bought by an American defence contractor. The US Financial Controller who was visiting said to me ‘What you have to remember Richard is that the production people are there to manufacture products, but we accountants are there to manufacture profits!’ He then went on to regale me with lots of stories of misaligned cost and revenue recognition skewing profit and enlarging bonuses.

So how are you coping with the new IFRS15 rules on revenue recognition and what’s it all about anyway?

What issue is IFRS15 addressing?

I guess the main reason for the change is the complications we introduce when we start to bundle goods and services together. We are all ok with invoicing and recognising the revenue for goods when a sales order is fully or partially despatched. We are even familiar with checking an installation process has taken place, if that is necessary, before closing the order, creating the invoice and recognising the revenue. We are also familiar with agreeing a service contract which we will bill quarterly and recognise the revenue for monthly. However, what happens when we bundle both into the same contract and muddle the pricing between service delivery and hardware?

There is plenty of information out there on the 5-stage process described in the legislation but it’s all a bit theoretical for easy understanding so let’s take an example of a mobile phone contract where the cash payment is £30 a month plus VAT for 24 months. Do we just recognise revenue of £30 a month as we collect the cash by direct debit? Not under IFRS15 we don’t. The reason is that the cost of the handset, say £400, will be recognised at the point of despatch and recognising the revenue straight line over the 24 months will seriously skew the profitability over this period causing a loss in the first months that is recouped as the contract progresses.

In this case identifying the contract is easy but what we must do is separate out the individual performance obligations of our contract with the customer, so we can recognise revenue when we have completed each obligation and determine how much of the total revenue should be recognised as each performance obligation is met.

So, in this example there are 3 performance obligations of different types:

1. The delivery of the handset so that the customer can start making calls.
2. The completion of each month’s usage of the phone for included calls, text and data.
3. Delivery of any usage each month over the included minutes, texts or data volume.

Number 3 is simple, and we can recognise the invoice amount as we bill it.

However, 1 and 2 have a bundled price but 1 has a performance obligation completion at the point of delivery whilst 2 has a partial performance obligation completion at the end of each month’s usage. But how much should we recognise as each performance obligation is met?

To do this IFRS15 says we need to establish the standalone selling prices for the individual performance obligations and use these to allocate the total amount we will bill.

So, suppose the handset has a standalone selling price of £500 and the voice, texts and data package would sell for £12.50 a month on a SIM only contract. So, we can see this gives us a total standalone selling price for the bundle of £800 and we see there is therefore a discount of £80 on the bundle price. We use the stand alone selling price values to pro-rate the revenue associated with each performance obligation. So, 500/800 = 62.5% and 300/800 = 37.5%. Then 62.5% * £720 = £450 which is how much revenue should be recognised on delivery of the handset. This will match the £400 cost of sale we recognised at the same performance obligation completion point giving a profit of £50. The remaining £270 is recognised at a rate of £11.25 as each month of the usage contract is completed. If the usage cost of provision is £5 a month then this will deliver a profit of £6.25 a month.

As can be seen this is a very different profile from recognising revenue of £30 a month and making a loss of £375 in the first month with a profit of £25 a month thereafter.

Does it affect my business?

But, you say, we don’t do bundles. Are you sure? What about implicit contracts? Do you offer a warranty on your goods? Do you offer a free support service on the software in your goods? Every business is different, but your accountants and/or auditors will be happy to help you determine if your current processes meet the new standard or not.

Having established you need to do something the question is then how? Your standard receivables accounting application won’t do it for you. Even a tier one ERP system like Oracle EBS won’t handle it. To address this Oracle has developed a cloud product called Revenue Management Cloud.

Manage the complexity with a sophisticated Cloud product

Oracle Revenue Management Cloud is a standalone application designed for two-way integration, so it will talk to your on premise or cloud ERP system even if it’s not one supplied by Oracle. This will allow you to suck in item, pricing, order, delivery, installation, contract and billing data from the ERP system, process it and send the relevant accounting journals back to the GL.

The processing is governed by a sophisticated rules-based engine that will allow you to tailor the system to your business requirements; firstly to identify the elements that make up the ‘accounting’ contracts and then to automate the associated number crunching exercise to determine the revenue recognition profile and to create the revenue recognition journals as the performance obligation events are completed.

For a business of any size there is going to be a lot of data and the worry is that your initial analysis and design may miss some elements. However, the application will identify exceptions where it can’t identify or process a contract and allow you to determine what is needed to correct the processing and fix it for this contract and any future similar contracts. It also allows you to set materiality thresholds, so we can apply the good old Pareto principle and have a manual review of the 20% of deals that deliver 80% of the revenue to ensure we have got it right. As you develop more trust in the application and your use of it you can raise these thresholds further reducing the need for manual review. Indeed, we would suggest it is a good idea to do a significant amount of testing on full prior months data and compare the results with the production system revenue, so we can prepare the board for the changes they can expect in the profitability profile over the post go live months.

So, if you have ignored this issue so far or your project to address it is bogged down get in touch with us at Claremont and we will help you get on top of the challenge.