Introduction

1. Computer software is a core part of the infrastructure of Australian Government entities, and its use permeates every aspect of their daily business.^[1] As at 30 June 2009, the value of Australian Government software assets was $2779 million.^[2]

2. Software is either purchased or internally developed by an entity. Purchased software is referred to as off the shelf software and is a ready built solution that an entity can buy to address a business need.^[3] Internally generated software (also referred to as internally developed software) is generally developed by the entity itself to meet specific business needs when an off the shelf option is not available, or is significantly modified for internal use. When entities develop their own software, they are able to tailor solutions to meet their specific requirements, but often at an increased cost compared to off the shelf solutions. In the government context, internally generated software is commonly built to support particular government programs and has business rules which follow government legislative and policy requirements.^[4]

3. Software has considerable costs attached which, depending on their nature, are capitalised as an asset, or expensed. It is important these costs are correctly accounted for to provide users of financial statements with accurate information on an entity's software assets and the costs of its operations. Understanding the true value of software assets better enables entities to plan future investments to replace, extend or improve their software assets, in support of strategic and operational objectives.

Accounting and reporting requirements

4. To support accountability and decision making in relation to the use of scarce resources, Australian Government entities are required to comply with Australian Accounting Standards and the Financial Management and Accountability Orders (Financial Reporting) (FMOs).^[5] Together, the Australian Accounting Standards and the FMOs establish how entities should record and present their financial position and transactions. In addition, the Department of Finance and Deregulation (Finance) has issued Accounting Guidance Note No. 2007/1 (Finance Guidance Note) on Accounting for Internally Developed Software that provides guidance on what costs should be capitalised for internally developed software intended for internal use.^[6]

5. For accounting purposes, software is generally treated as an intangible asset.^[7] The key applicable accounting standards relating to software assets are AASB 138 Intangible Assets and AASB 136 Impairment. These standards address when an asset exists and how purchased and internally generated intangible assets should be valued. In particular, AASB 138 defines intangible assets, and prescribes the recognition, measurement and disclosure requirements applicable to intangible assets. The standard imposes more stringent recognition criteria on internally generated intangible assets than for other assets that are capitalised. Under AASB 138, software costs are either:

• capitalised as an asset on the basis that the costs result in a future economic benefit to the entity and they can be measured reliably; or
• expensed in the year in which they are incurred.

6. AASB 138 divides the development of internally generated intangible assets into two stages: a research stage and a development stage. Research includes activities aimed at gaining new scientific or technical knowledge and understanding, evaluating alternatives and making selection decisions. The development stage includes activities that relate to design, construction and testing prior to the asset being available for use.^[8] All costs incurred during the research stage are expensed when they are incurred. Costs incurred during the development stage can be capitalised if they meet specific requirements set out in AASB 138, otherwise they should be expensed.^[9]

7. The Finance Guidance Note outlines the key points of AASB 138 and provides examples of costs that should be capitalised or expensed:

• capital items include staff, contractor and supplier expenses directly relating to developing or testing the asset in the development phase; and
• expense items include project governance committees, stakeholder meetings, training^[10] and developing user manuals.

8. To correctly value software assets, entities need to be satisfied there is a clear connection between costs that are capitalised and the resulting asset. Under AASB 138 the cost of a purchased asset is its purchase price plus any directly attributable cost of preparing the asset for its intended use. Similarly, for an internally generated intangible asset, the cost of the asset comprises all directly attributable costs during the development phase necessary to create, produce, and prepare the asset to be capable of operating in the manner intended by management.^[11]

9. For accountability purposes, it is important that the value of software assets recorded by entities in their financial statements continues to reflect the expected benefits to be obtained from their use. For this reason, entities need to determine the useful life of software assets, and amortise their cost over the useful life of the assets. In addition, AASB 136 prescribes the procedures an entity must apply to ensure its non-current assets are carried at no more than their recoverable amounts.^[12] AASB 136 requires that, at each reporting date, an entity assess whether there is any indication that an asset is recorded at greater than its recoverable amount and if so, to recognise an impairment loss.^[13]

Planning for software assest investments

10. Correctly valuing and amortising software assets helps entities understand future asset funding requirements. Consequently, the accounting treatment of software assets forms an input to software asset planning. More broadly, decision making on the purchase and development of software assets should take into account entities' information and communications technology (ICT) and capital management planning.

11. ICT planning establishes an entity's priorities for ICT in support of business directions. In making deliberations about software purchases and development, entities generally need to take into account the risks associated with software assets, such as technical obsolescence and changes in business requirements. Another key aspect of ICT planning is consideration of the whole-of-life cost implications of planning, acquiring, operating, maintaining and disposing of software assets.

12. An entity's capital management plan (CMP) outlines how the entity will allocate scarce capital resources over time, to meet entity priorities. Having an entity's ICT plans align with its CMP, typically improves communication between the ICT and Finance areas, thereby helping to ensure available funding is directed to key software purchases and development activities, in a timely manner.

Audit approach

13. The objective of the audit was to assess whether entities properly accounted for software assets, and adopted an integrated planning approach to inform software asset investment decisions.

14. The main focus of the audit was on whether entities accounted for software costs in accordance with relevant accounting standards and the FMOs, paying particular attention to the standard elements of an internal control framework¹⁴ and accounting practices. In addition, in the context of software asset planning, the audit considered whether entities assessed the risks associated with software assets, used life-cycle costing approaches, and aligned ICT and capital management plans, to inform decision-making on software asset investments.

15. The audit was conducted at three selected entities:

• the Australian Bureau of Statistics (ABS)—the value of the ABS' software assets was $84.2 million at 30 June 2009. This represented around 62 per cent of the ABS' non-financial assets;^[15]
• the Civil Aviation Safety Authority (CASA)—the value of CASA's software assets was $26.7 million at 30 June 2009, which represented around 56 per cent of its non-financial assets;^[16] and
• IP Australia—the value of IP Australia's software assets was $25.7 million at 30 June 2009, which represented around 50 per cent of its non financial assets.^[17]

16. The audit examined for each entity: accounting policy and guidance; governance arrangements supporting software capitalisation, and arrangements to capture and report relevant costs for a sample of 10¹⁸ internally generated software assets; software project closure processes for a sample of five software assets; and approvals to purchase five software assets.

17. The audit also assessed whether relevant recommendations contained in Audit Report No.54 2002–03, Capitalisation of Software (provided in Appendix 1: Recommendations from Audit Report No.54 2002–03) had been implemented by the audited entities.

Overall conclusion

18. Computer software is a key asset of the Australian Government and had a value in excess of $2.7 billion as at June 2009.^[19] Australian Government entities are obliged to account for software costs in accordance with relevant accounting standards and the requirements set out in the Finance Minister's Orders (FMOs). These requirements are designed to ensure users of financial statements are provided with reliable information on the value of entities' software assets and the cost of their operations. Correctly valuing software assets provides a sound basis for their management in support of effective program delivery.

19. There are a number of inherent difficulties in accounting for software. These involve meeting the definition and recognition criteria for intangible assets; measuring and attributing costs associated with software development; and determining useful life and assessing asset impairment, given the rapidly changing business and technological environment. The interpretation of the accounting standard on intangible assets (AASB 138)^[20] requires judgement in terms of what software costs should be capitalised and expensed. AASB 138 places the onus on entities to be satisfied there is a clear connection between costs that are capitalised and the resulting asset. In this light, a prudent approach should be taken to avoid over capitalising costs.^[21] For internally generated intangible assets, entities need to ensure that only costs that can be measured reliably and directly attributed to the development of software assets are capitalised.

20. In a broader planning context, it is beneficial for decision making on software asset purchases and development to have regard to risks associated with software assets, and be based on the whole-of-life costs of ownership of software assets. Aligning ICT and capital management plans also assists in ensuring that funding is directed to software assets that best achieve strategic and operational objectives.

21. Overall, each of the audited entities had properly accounted for their software assets. The entities' approaches were generally underpinned by appropriate: accounting policy and guidance; project governance arrangements supporting software capitalisation; and systems and practices that enabled the capture and reporting of relevant capital costs. Nevertheless, ABS needed to improve its approach to software asset valuation. There was also scope for entities to more effectively use software project closure processes and post implementation reviews (PIRs), in support of their approaches to software capitalisation. Finally, each of the entities had only partially adopted integrated planning for software asset investments.

22. Two or more of the entities had implemented the majority of relevant recommendations in the ANAO's 2002–03 performance audit on capitalisation of software.^[22]

23. To improve the valuation of software assets in accordance with the expected benefits to be derived from their use, and strengthen planning for software asset investments, entities should:

• ensure that only costs that meet the definition and recognition criteria for intangible assets, and can be both measured reliably and directly attributed to the development of software assets, are capitalised (see Recommendation No.1);
• establish sound software project closure processes tailored to the scale and risk profile of projects (see Recommendation No.2);
• undertake PIRs of software projects on the basis of predetermined criteria (see Recommendation No.3); and
• have regard to software asset risks and whole-of-life costs, while aligning ICT and capital management plans, to inform software asset investment decisions (see Recommendation No.4).

Key findings

Accounting for software assets (Chapter 2)

Accounting policy and guidance

24. Accounting policy and guidance at CASA and IP Australia generally reflected the relevant accountings standards. The guidance at ABS was in need of updating and could be further improved by providing more material on how to comply with the necessary requirements.

Governance arrangements supporting capitalisation of software

25. All entities had governance arrangements in place that supported appropriate approaches to the capitalisation of software, including management oversight of software purchases and development. For each entity there was either a clearly defined finance team or designated finance position (project accountant) assigned to support project managers and ensure that the treatment of software costs complied with relevant accounting standards and the FMOs.

26. The ANAO examined project approval processes for a sample of 10 internally generated and five purchased software assets in each entity.^[23] All of the software projects had appropriate initiation and approval documentation. Although, at the time of the audit, none of the entities required research and development phases to be separately identified at the project initiation stage for internally generated software assets. Not having the split between research and development clear from the inception of a project increases the risk that costs are inappropriately treated.

Capture of time and cost information

27. In each entity, an hourly or daily costing rate was applied to time recorded against software projects to calculate the cost of labour effort involved in software development. Each entity had a different approach to determining the costing rate used. CASA's and IP Australia's approaches were generally in accordance with the principles of AASB 138. For several years the ABS had inappropriately capitalised costs related to training and indirect administrative service activities which were included in the overall costing rate. These costs are excluded under AASB 138.^[24] The cumulative impact of incorrectly capitalising such costs was not significant enough to result in a material error in ABS' financial statements.^[25] ABS advised it will no longer capitalise these costs.

28. In addition, the ABS was unable to demonstrate that some of the other costs included in its costing rate (predominantly IT and administrative costs) were directly attributed to the development of software assets, as required by AASB 138. As a result, during ABS' 2009–10 financial statements process, ABS revised its attribution approach and did not capitalise these costs. The impact of this change in estimation process was recognised prospectively, commencing for the 2009–10 financial year, and resulted in an increase of $2.1 million in employee benefits expenses, and a corresponding reduction to internally generated software assets, in ABS' 2009–10 financial statements.

29. ABS' approach involved attributing a range of costs to the development of software on the basis of costs derived from its business costing model. The costing model was designed for internal costing purposes and was also used for software capitalisation, however it did not take into account all the specific requirements of AASB 138.

30. ABS' approach to capitalising costs highlights the need for entities to be aware that AASB 138 imposes tighter requirements on which costs can be capitalised than entities may apply for internal costing purposes. Where estimates are used by entities to capitalise costs (for example, the contribution of IT support costs at ABS), they should be properly supported by analysis to ensure that the costs are directly attributable to developing the asset and can be measured reliably. The ANAO considers a common sense approach should be taken. For example, on the basis of sound analysis, entities could determine costs for capitalisation purposes from the information contained in their costing models. Analysis should be subject to periodic review to ensure any assumptions used to capitalise costs remain valid.

Project closure and review

31. The ANAO examined project closure processes for a sample of five software projects in each entity. CASA had strong processes supporting project closure. In IP Australia, while documented closure procedures were sound, three of five software projects examined had costs recorded against assets after the asset was capitalised. In ABS, project closure processes did not require sign-off from a senior management committee or project board when the asset was ready for use. Acceptance of the asset as complete was based on the judgement of the project manager after the completion of user acceptance testing, regardless of value. The absence of sound software project closure processes, tailored to the scale and risk profile of projects, increases the risk that software assets are capitalised at a value that does not reflect the expected benefits to be obtained from their use, and are not amortised appropriately.

32. None of the 10 completed software projects examined for each entity had been subject to a PIR. The entities advised they only undertake PIRs for projects that encounter serious difficulties. A pragmatic approach, that would better support continuous improvement in software project management and accounting, would be to conduct PIRs on the basis of predetermined criteria, such as the significance of projects in terms of value or business need and the extent of project management issues that have arisen.

Impairment reviews

33. As part of their 2008–09 financial statements process, all of the entities assessed whether there was any indication that software assets may be impaired and, where appropriate, reduced the value of the asset.

Planning for software asset investments (Chapter 3)

34. ABS and IP Australia had not formally used software asset risk profiling to inform decision making on asset investments, although steps were being taken in this direction. In 2009, ABS undertook a review and developed a risk profile for each software asset. At the time of the audit, the risk profile was not being used to guide capital management planning processes. In 2008, CASA completed a review of its asset management framework, which incorporated asset risk profiling of all assets, and formed the basis of its CMP. IP Australia supported asset replacement decisions informally using asset criticality ratings as reflected in its business continuity plans.

35. CASA included life-cycle costing in its software asset business cases/initiation documents and reflected such costs in its annual ICT plan. ABS' and IP Australia's current policies, procedures and practices did not support the life-cycle costing of intangible assets. Both entities had updated their guidance and were in the process of implementing revised templates for new projects to provide for estimated ongoing costs, such as maintenance, as well as disposal/decommissioning costs.

36. None of the entities had formally aligned both their annual and longer term ICT plans with their CMP. Although, CASA had formal linkages between its annual ICT plan and its CMP.

Entities' responses

37. Each of the audited entities agreed with the four recommendations in this report. Entities' responses to each of the recommendations are shown in the body of the report following the relevant recommendation. Entities' general comments are provided below.

Australian Bureau of Statistics

38. The Australian Bureau of Statistics (ABS) welcomes the audit and agrees with the recommendations. The audit report provides a valuable framework to support further improvement with the management and capitalisation of software within the ABS environment. During 2009–10 the ABS undertook a number of improvements surrounding the agency's overall capital management and continues to do so. A number of corrective actions were undertaken before the audit was completed.

Civil Aviation Safety Authority

39. CASA welcomes any constructive review and external scrutiny of its processes and procedures. CASA has a sound process supporting the capitalisation of software that can be enhanced by the recommendations in the report. It is CASA's intention to apply appropriate measures to ensure the enhancements are put in place.

IP Australia

40. IP Australia agrees with the recommendations of the audit of Software Capitalisation. IP Australia is pleased that the ANAO has acknowledged the work already done by IP Australia to manage its software assets and ensure they are appropriately accounted for. The recommendations from the report will assist IP Australia to make further improvements to its processes for software asset management.

Footnotes

^[1] Computer software is a general term used to describe a computer program or collection of programs that perform a function.

^[2] Department of Finance and Deregulation, Consolidated Financial Statements For the Year Ended 30 June 2009, Note 21. Available at http://www.finance.gov.au/publications/commonwealth-consolidated-financial-statements/2009.html p 92. [Accessed July 2010.]

^[3]Examples of off-the-shelf software include accounting and human resources systems and office support packages. In some cases, for example some office support packages, entities purchase licences to operate the software.

^[4]Examples of internally generated software include social security, tax collection and healthcare systems.

^[5] Each year the Minister for Finance issues the Financial Management and Accountability Orders (Financial Reporting) (FMOs), which outline requirements and provide guidance in relation to the preparation of financial statements by Australian Government entities. The FMOs are relevant to all reporting entities covered by section 49 of the Financial Management and Accountability ACT 1997 or clause 2 of Schedule 1 to the Commonwealth Authorities and Companies Act 1997. The FMOs for reporting periods ending on or after 1 July 2009 are available at http://www.finance.gov.au/publications/finance-ministers-orders/index.html

^[6] Department of Finance and Deregulation, Accounting Guidance Note No. 2007/1 Accounting for Internally Developed Software. The aim of accounting guidance notes is to provide non-mandatory explanation and examples relating to the interpretation and application of Australian Accounting Standards and the Finance Minister's Orders by Australian Government reporting entities. The Guidance Note is available at http://www.finance.gov.au/publications/accounting-guidance-notes/index.html [Accessed July 2010.]

^[7] To be treated as an intangible asset computer software must first meet the capitalisation criteria in AASB 138 Intangible Assets which are discussed later in this report.

^[8] AASB 138 Intangible Assets paragraph 8. Available at http://www.aasb.gov.au/admin/file/content105/c9/AASB138_07-04_COMPapr07_07-07.pdf [Accessed May 2010.]

^[9] These requirements relate to: the technical feasibility of completing the intangible asset so that it will be available for use or sale and generate probable future economic benefits; and that expenditure attributable to the intangible asset during the development phase can be measured reliably. AASB 138 Intangible Assets paragraph 57 available at http://www.aasb.gov.au/admin/file/content105/c9/AASB138_07-04_COMPapr07_07-07.pdf [Accessed May 2010.]

^[10] Excluding training that is in-built into a software asset, for example, a training module.

^[11] The cost of the asset is the sum of expenditure incurred from the date when the intangible asset first meets the recognition criteria and comprises all directly attributable costs during the development phase.

^[12] An asset would be carried at more than its recoverable amount if its carrying amount exceeds the amount to be recovered through use or sale. AASB 136 states that where an asset is carried at more than its recoverable amount the asset is impaired and the entity is required to recognise an impairment loss.

^[13] Under AASB 136 paragraph 12 indicators that shall be considered, as a minimum, include the following external sources of information: unexpected significant decline in the asset's market value; significant changes with an adverse effect on the entity including changes to the market, economic or legal environment in which the entity operates; changes in market interest rates that are likely to affect the calculation of an asset's value in use; and the carrying amount of the entity's net assets is more than its market capitalisation. In addition, the following internal sources of information should be considered: obsolescence or physical damage to an asset; significant changes with an adverse effect on the entity such as assets becoming idle and plans to discontinue or restructure operations; and evidence from internal reporting that an asset's economic performance may be worse than expected. Available at http://www.aasb.gov.au/admin/file/content105/c9/AASB136_07-04_COMPjun09_07-09.pdf

^[14] The standard elements of an internal control framework are: risk assessment, control environment, control activities, communication of information and monitoring and review.

^[15] Australian Bureau of Statistics Annual Report 2008–09 pp. 202 and 233. Available at http://www.ausstats.abs.gov.au/Ausstats/subscriber.nsf/0/FB4BA2DC4D523F38CA25765D00125C48/$File/10010_2008-09.pdf

^[16] Civil Aviation Safety Authority Annual Report 2008–09, pp. 98 and 121. Available at http://www.casa.gov.au/wcmswr/_assets/main/lib91185/casa_ar_0809_financials.pdf

^[17] Department of Innovation Annual Report 2008–09, pp. 252 and 278. Available at http://www.innovation.gov.au/Section/AbouttheDepartment/Annual%20Report%20200809/resources/pdf/DIISR_ip_australiafinancial_statements.pdf

^[18] Internally developed software initiation documents were reviewed for five software assets under construction and five recently developed assets.

^[19] Department of Finance and Deregulation Consolidated Financial Statements For the Year Ended 30 June 2009, Note 21. Available at http://www.finance.gov.au/publications/commonwealth-consolidated-financial-statements/docs/CFS_2009.pdf, p. 92.[Accessed July 2010.]

^[20] Australian Government entities have been required to comply with AASB 138 for annual reporting periods commencing on or after 1 January 2005. As such, it is expected that entities would have established effective arrangements to account for software assets in line with AASB 138 Intangible Assets.

^[21] AASB Framework for the Preparation and Presentation of Financial Statements paragraph 37 states that preparers of financial statements have to contend with the uncertainties that inevitably surround many events and circumstances. Such uncertainties are recognised by the disclosure of their nature and extent and by the exercise of prudence in the preparation of the financial statements. Prudence is the inclusion of a degree of caution in the exercise of the judgements needed in making the estimates required under conditions of uncertainty, such that assets or income are not overstated and liabilities or expenses are not understated. Available at http://www.aasb.gov.au/admin/file/content105/c9/Framework_07-04nd.pdf.

^[22] Australian National Audit Office, Audit Report No.54 2002-03, Capitalisation of Software, available at http://www.anao.gov.au/uploads/documents/2002-03_Audit_Report_54.pdf

^[23] Internally developed software initiation documents were reviewed for five software assets under construction and five recently developed assets.

^[24] Training costs are not able to be capitalised as entities do not usually have sufficient control over the expected future economic benefits arising from training staff. Similarly, indirect expenditure may be incurred without acquiring or creating an asset that can be recognised under AASB 138 Intangible Assets.

^[25] A financial statement audit undertaken in accordance with Australian Accounting Standards is designed to provide reasonable assurance that a financial report taken as a whole is free from material misstatement. Reasonable assurance is a concept relating to the accumulation of the audit evidence necessary for the auditor to conclude that there are no material misstatements in the financial report taken as a whole. AASB 1031 Materiality paragraph 4 states that information is material if its omission, misstatement or non-disclosure has the potential to adversely affect: (a) decisions about the allocation of scarce resources made by users of the financial report; or (b) the discharge of accountability by the management or governing body of the entity. Available at www.aasb.gov.au/admin/file/content102/c3/AASB1031_9-95.pdf