Issues with Revenue Recognition Within the Software Industry

Issues With Revenue Recognition within the Software Industry The Isoft Example Financial Controller-SoftWarehouse Ltd This report has been prepared for the Board of Directors of SoftWarehouse Ltd for elucidation about the contentious issues that have given rise to the publication of the article concerning Isoft’s issues with revenue recognition. Finally, it will also assess whether or not these issues are likely to affect SoftWarehouse Ltd. TABLE OF CONTENTS Executive Summary:3 Introduction:5Part 1- Examining the Isoft Ltd example:5 PART 2 – The issues faced by software companies in relation to revenue recognition:6 Part 3- Issues raised that may impact SoftWarehouse Ltd:7 Part 4 – Future changes in revenue recognition standard:8 Conclusion:9 Reference List:10 Executive Summary: This report has been prepared for the Board of Directors of SoftWarehouse Ltd for elucidation about the contentious issues that have given rise to the publication of the article concernin g Isoft’s issues with revenue recognition.Finally, it will also assess whether or not these issues are likely to affect SoftWarehouse Ltd. In January 2006, Isoft, a Manchester based supplier of software applications for the healthcare sector, announced that its profit would be below market expectations due to a required change in its accounting policy for revenue recognition. Isoft was forced to reverse revenue of approximately ? 70m in 2005 and ? 55m in 2004 – when Deloitte found that Isoft was recognizing revenue sooner than it should have been.The underlying principle of Isoft’s historic revenue recognition policy had been that the value of the product licenses was recognised at the time of delivery, while the value of support and servicers was recognised as they were performed. Moreover, the value of licences was identifiable and separable form the implementation and support services provided. This is not aligned with what the AASB Revenue states. Consequent ly, Isoft engaged in controversial accounting practices. The company recognised revenue at the start of long-term contracts instead of recognising revenue over the life of the contract.Isoft was recognising revenues from contracts even though actual payments for some projects were due over an extended period (for example: one project it recognized revenue even though actual payments were to be paid over a two-year period). The accounting practice of recognising revenue in this method lead to an overstatement of its income, and therefore had the effect of misleading the stock market and Isoft’s overall credibility. After realigning its revenues to the current period (in 2006) to reflect a fair value of its performance, 40% was taken off its share values and the company was forced to lay off 10% of its staff.Isoft adopted a new revenue recognition policy, which more appropriately reflects the changing nature of the business as the group is involved with more complex and long-te rm product supply projects. In the new policy, licence revenues will be recognised over the same period as the implementation of revenues, which may range from a few months to a number of years from contract signature. This will increase visibility and predictability of earnings. At SoftWarehouse Ltd, our contracts with our customers involve the sale of customised software as well as its implementation and maintenance services.We recognise revenue in accordance to AASB 118. The revenue therefore, is recognised over the length of the contract. Due to the fact that our selling prices include an identifiable amount for the subsequent services, that amount is deferred and recognised as revenue over the period during which the service is performed. We recognise revenue by reference to the stage of completion of the transaction at the end of the reporting period. Therefore, I am confident that we will not encounter similar issues, which were faced by Isoft.However, due to the lack of guid ance from the IFRS and GAAP standards on revenue recognition, it is foreseeable that interpretations could become misguided or unaligned with these standards in the future. The issues raised by Isoft elucidate the importance of recording an accurate picture of its earnings. The joint project of the FASB and the IASB is trying to converge the two sets of standards and offer a single revenue recognition model that can be applied consistently to various transactions – which would address these issues of lack of guidance.Introduction: In January 2006, Isoft Ltd, a Manchester based supplier of software applications for the healthcare sector, announced that its profit would be below market expectations due to a change in its accounting policy for revenue recognition, when it announced its results for the year ended April 2006. This situation is not unusual within the software industry and reflects the issues that software companies face when it comes to accounting for revenues.As t he financial controller of SoftWarehouse Ltd, my goal is to clarify and explain the main issues faced by Isoft Ltd; the consequences of those issues on the business and finally; to determine if those practices could also impact the financial reporting within SoftWarehouse Ltd. Part 1- Examining the Isoft Ltd example: The underlying principle of Isoft Ltd’s historic revenue recognition policy had been that the value of product licences was recognised at the time of delivery, while the value of support and services was recognised as they were performed (Isoft 2006).Moreover, under this policy, the value of licences was identifiable and separable from the implementation and support services provided (Isoft 2006). AASB 118- Revenue (AASB 2010), gives some guidance on how to recognise revenue: â€Å"When the selling price of a product includes an identifiable amount for subsequent servicing, that amount is deferred and recognised as revenue over the period, which the service is p erformed. AASB (2010) illustrates that statement by giving an example which can be applied to Isoft Ltd’s situation: â€Å"When the selling price of a product includes an identifiable amount for subsequent services (for example, after sales support and product enhancement on the sale of software), that amount is deferred and recognised as revenue over the period during which the service is performed. The amount deferred is that which will cover the expected costs of the services under the agreement, together with a reasonable profit on those services. † Therefore, it seems that Isoft Ltd’s traditional policy is acceptable under AASB 118- Revenue.Isoft Ltd had to change its revenue recognition after Deloitte had found that some revenues had been recognised earlier than they should have been (Stafford 2006), which lead to an overstatement of its income and therefore had the effect of misleading the stock market (Griffiths and Bowers 2006), and thus affect Isoftâ⠂¬â„¢s credibility. When the company was obliged to realign its revenues to the current period in 2006 to reflect a fair value of its performance, its revenues got wiped out and it knocked 40% off its share values. The company also announced that at 10% of its staff would be laid off (Meyer 2006).Under Isoft Ltd’s new revenue recognition policy, licence revenues will be recognised over the same period as implementation revenues, which may range from a few months to a number of years from contract signature, and over the full duration of the contract in the case of managed services (Isoft Ltd 2006). The group stated that a change of accounting policy for revenue recognition is needed to more appropriately reflect the changing nature of the business as the group is involved with more complex and long-term product supply projects (Isoft Ltd 2006).Isoft Ltd also mentioned that its new revenue recognition policy would increase visibility and predictability of earnings (RNS 2006). PART 2 – The issues faced by software companies in relation to revenue recognition: Isoft Ltd was accused of being engaged in controversial accounting practices. The main issue with Isoft Ltd’s accounting practices is that it was recognising revenue sooner than it should have been. The company recognised revenue at the start of long-term contracts instead of recognising revenue over the life of the contract (Moulds 2006).Indeed, during the year 2004-2005, Isoft Ltd accounted in full for the revenue raised as part of long-term contracts at the time of receiving part prepayments. Analysts had found that Isoft Ltd, the main software supplier for the NHS’s ? 6. 2bn IT project, was recognising revenues from contracts even though actual payments for projects were only due over two years time (Neveling 2006). For the year ending April 2004, Isoft Ltd recognised ? 30m of payments from Accenture and CSC who were implementing the NHS’s technology overhaul (UK Parli ament 2007).One of the main issues in accounting is about revenue recognition, especially in our IT industry. As KPMG (2009) stated, IFRS does not provide any specific guidance on revenue recognition for software related transactions. The IFRS standard and the Australian GAAP standard on revenue recognition lack guidance when a transaction involves both a good and services related to that good (IASB 2008) – which is often the case for software companies. The difficulty for software companies resides in the fact that due to this vagueness, it is hard to distinguish the revenue from the software and the revenue from the services offered.As Stafford (2006) mentioned, Isoft Ltd is not the first software company to have had issues with revenue recognition. Part 3- Issues raised that may impact SoftWarehouse Ltd: At Softwarehouse Ltd, we are providing customised software to our customers in the mining industry. Our contracts with our customers involve the sale of customised softwar e as well as its implementation and maintenance services. We recognise revenue according to AASB 118, which we previously mentioned in detail in part 1.AASB (2010) adds an interesting point for guidance: â€Å"fees from the development of customised software are recognised as revenue by reference to the stage of completion of the development, including completion of services provided for post delivery service support. † The revenue is therefore, recognised over the length of the contract. Due to the fact that our selling prices include an identifiable amount for the subsequent services we deliver, that amount is deferred and recognised as revenue over the period during which the service is performed.We recognise revenue by reference to the stage of completion of the transaction at the end of the reporting period. We are confident that we will not encounter a similar situation than the one Isoft Ltd went through. However, I have to admit that the AASB is not giving clear guida nce regarding revenue recognition, which leaves us with our own interpretation. Due to this lack of guidance, it could be foreseeable that our interpretation could become misguided or unaligned with the AASB. We should always be aware that even though our policy is acceptable under the Australian GAAP, it doesn’t mean that we are protected from making mistakes.Indeed, Isoft Ltd’s traditional policy was acceptable under the Australian GAAP. However, as their contracts changed, Isoft Ltd did not update its policy, which led to misalignment. At Softwarehouse Ltd, we have to bear in mind that if the type of contracts or transactions that we offer change, then we will have to update our policy to accurately reflect our financial position. Ultimately, we must ensure that we do not recognise revenue too early and overstate our income. Part 4 – Future changes in revenue recognition standard:We are still keeping a close eye on the project regarding the new revenue recogn ition model: the Contract- based revenue recognition model. This is a joint project of the FASB and the IASB whose goal is to converge the two sets of standards (Henry & Holzmann 2009) and to offer single revenue recognition model that can be applied consistently to various transactions (IASB 2008). If adopted the proposed standard will replace existing standards AASB 118- Revenue. The core principle of this model is that an entity would recognise revenue from contracts with customers when it transfers promised goods or services to the customer.The amount of revenue recognised would be the amount of consideration promised by the customer in exchange for the transferred goods or services (RSM Bird Cameron 2011). Under this new revenue recognition model, it is stated that the â€Å"entity should recognise revenue when its net position in a contract with a customer increases as a result of satisfying a performance obligation. An entity satisfies a performance obligation when it transf ers goods and services to a customer. † (IFRS 2008). The last exposure draft (IFRS 2011) indicates â€Å"if a romised good or service is not distinct, an entity would combine that good or service with other promised goods or services until the entity identifies a bundle of goods or services that is distinct. Therefore, the entity would account for the bundle as a single performance obligation†. The revenue for that performance obligation would then be recognised over time by selecting an appropriate measure of progress towards complete satisfaction of the performance obligation (IFRS 2011). Conclusion: One of the main issues in accounting concerns revenue recognition, especially within the software/IT industry.The IFRS and the Australian GAAP standards on revenue recognition lack guidance when it comes to multiple element transactions. Due to this lack of guidance, it is foreseeable that interpretations could become misguided or unaligned with the IFRS or Australian GAA P standards. The issues raised by Isoft Ltd, elucidate the importance of recording an accurate picture of its earnings. Indeed, Isoft had to change its revenue recognition after it was exposed that some revenues had been recognised earlier than they should have been, which lead to an overstatement of its income and therefore had the effect of misleading the stock market.The joint project of the FASB and the IASB is trying to address these issues of lack of guidance. Reference List: Australian Accounting Standards Board 2010, AASB 118 Revenue. Available from: www. aasb. gov. au. [20 March 2012]. Griffiths, I & Bowers, S 2006, ‘Revealed: Isoft’s U-turn on accounts problems’, The Guardian 2 November. Available from: . [8 April 2012]. Henry, E & Holzmann, OJ 2009, ‘Contract-Based Revenue Recognition’, The Journal of Corporate Accounting & Finance, pp. 77-81. Available from: Proquest [28 March 2011].House of Commons, Committee of Public Accounts 2007, Dep artment of Health: the national programme for IT in the NHS, The Stationary Office, London. International Accounting Standards Board 2008, Discussion Paper Preliminary views on revenue recognition in contracts with customers. Available from: . [20 March 2012]. IFRS 2011, Exposure draft revenue from contracts with customers. Available from: . [5 April 2012]. KPMG 2009, Impact of IFRS on the Information Technology and Business Process Outsourcing Industries. Available from: < https://www. in. kpmg. com/securedata/ifrs_Institute/Files/IFRS_IT. df>. [ 10 April 2012]. Meyer, D 2006, ‘NHS IT timescale questioned as Isoft CEO resigns’, Zdnet 15 June. Available from: . [7 April 2012]. Moulds, J 2006, ‘Isoft directors and ex- auditors face questioning in new inquiry’, The Telegraph 26 October 2006. Available from: . [5 April 2012]. Neveling, N 2006, ‘What’s going on at Isoft’, Financial Director 31 August 2006. Available from: . [7 April 2012]. R NS 2006, Isoft Change in Accounting Policy. Available from: . [5 April 2012]. RSM Bird Cameron Chartered Accountants, 2011, Revenue Recognition- New and Revised Proposal, Available from: http://www. rsmi. com. au/rsbcwr/_assets/main/lib90034/111220_financial%20insight_revenue%20recognition%20web. pdf>. [28 March 2012]. Stafford, P 2006, ‘Revenue Recognition is Isoft’s Curse’, Financial Times 9 August. Available from: http://www. ft. com. [5 April 2012]. Uk Parliament 2007, Memorandum submitted by Ian Griffiths and Simon Bowers. Available from: . [8 April 2012].