AUDIT

New Accounting Rules for Software CostsWhat Government IT Professionals Need to Know About GASB 51

GOVERNMENT

The Governmental Accounting Standards Board issued Statement No. 51, Accounting and Financial Reporting for Intangible Assets (GASB 51), to reduce inconsistencies in the reporting of intangible assets, including computer software, by state and local governments. A significant portion of GASB 51 addresses the financial reporting of costs associated with the development of computer software. GASB 51 is generally effective for fiscal periods ending on or after June 30, 2010.

The “development-stage approach” prescribed by GASB 51 to report software development costs will likely require the creation of new accounting policies and procedures in which the IT function will be a significant stakeholder. The increased focus on software development costs also will likely create a greater accountability for the cost efficiency of software projects. Additionally, capitalization of software development costs may impact funding sources for software projects.

Highlights

The “development-stage approach” prescribed by GASB 51 to report software development costs will likely require the creation of new accounting policies and procedures in which the IT function will be a significant stakeholder.

GASB 51 1

2 GASB 51

What the Statement Says

GASB 51 states that all intangible assets within its scope should be classified as capital assets for financial reporting purposes. In the context of GASB 51, an intangible asset is described as an asset that possesses the following characteristics:

• Lack of physical substance

• Nonfinancial nature

• Initial useful life extending beyond a single reporting period

Computer software is expected to be the most prevalent intangible asset across state and local governments. For many governments, computer software also will be the most significant intangible asset reported. Accordingly, GASB 51 contains guidance that specifically addresses the recognition of costs associated with internally generated computer software, which is described as software that is either:

• Developed in-house by the government’s own personnel or by a contractor on behalf of the government

• Commercially available software that is purchased or licensed by the government that requires more than minimal incremental effort before being put into operation.

GASB 51 prescribes a “development-stage approach” for reporting the costs associated with developing internally generated computer software. Governments will be required to classify the activities involved in developing software into one of the following three stages:

• Preliminary Project Stage. Activities in this stage will generally include the conceptual formulation

and evaluation of alternatives for the software project, the determi-nation of the existence of needed technology, and the final selection of alternatives for the development of the software.

• Application development stage. Activities in this stage will generally include the design of the chosen path, including software config-uration and software interfaces, coding, installation to hardware, and testing, including the parallel processing phase.

• Post-implementation/operation stage. Activities in this stage include user application training and system maintenance.

Under the recognition guidance in GASB 51, costs associated with activities of the preliminary project stage should be expensed as incurred. Once preliminary project stage activities are completed and management has authorized and committed to funding the software project, costs associated with activities of the application development stage should be capitalized until the software is in place and operational. Costs associated with activities of the post-implementation/operation stage should be expensed as incurred.

Why Is the Statement Relevant to IT Professionals?

Most governments will have to develop new accounting policies and procedures to effectively apply the internally generated computer software guidance in GASB 51. These policies and procedures likely will address areas including the classi-fication of software development activities into the three development

stages noted above, the identification and accumulation of costs associated with those activities, the thresholds for capitalizing the costs of software projects, and the useful lives of software assets. We expect IT professionals to be key participants in the development of these policies and procedures because of their expertise and because they will have significant responsibility for the effective application of the policies and procedures.

The increased focus on accumulating and distinguishing the nature of costs associated with software projects for financial reporting purposes will also likely result in a greater level of account-ability for the cost effectiveness and efficiency of such projects on the part of IT professionals. The cost accumu-lation or job costing system necessary to effectively apply the development-stage approach prescribed in GASB 51 likely will require more detailed time and expense reporting by IT professionals and external contractors. Such reporting may face a high degree of scrutiny from the government’s financial reporting function as it will form the basis for reporting the value of the capital asset associated with the software.

Reporting costs associated with developing computer software as capital assets also may impact the sources of funding for such projects. For many governments, bond funds can only be used to finance projects that result in capital assets. This limited the ability to use bond funds for software projects when the related costs were expensed in the financial statements. With software reported as a capital asset, bond funds may become available to finance a portion of the cost of software development projects.

On the other hand, the Federal Department of Health and Human Services, Division of Cost Allocation has

sent a letter to state financial reporting and IT divisions stating that it is not acceptable to charge federal programs for software costs as they are incurred when those costs are required to be capitalized. Instead, federal programs should only be charged for amortization of these capitalized costs once the software programs are implemented and in use by federal programs. This likely will defer federal reimbursement of the costs associated with eligible software projects.

Frequently Asked Questions

When must the new requirements for internally generated computer software be applied? GASB 51 is generally effective for fiscal periods ending on or after June 30, 2010. However, effective implementation of the internally generated computer software requirements would be facilitated by having the necessary policies and procedures for development activity classification and cost accumulation in place by the beginning of the 2010 fiscal year. This way, development costs can be accounted for contemporaneously as incurred as opposed to retrospectively at the end of the fiscal year.

Must the internally generated computer software requirements be applied to software developed prior to implemen-tation of GASB 51? No. Retroactive reporting of internally generated computer software is not required, but is permitted to the extent that the development-stage approach can be applied to determine the cost of the software asset. Other means to determine or estimate the cost of existing software should not be used to retroactively report the software asset.

Does GASB 51 apply to software that is not internally generated? Yes. However, specific recognition guidance for such

software was not considered necessary. The cost of purchasing or licensing non-internally generated computer software should be capitalized upon acquisition, similar to how capital assets generally are reported.

Are Web sites considered internally generated computer software? Web sites are considered computer software and should be considered internally generated if they meet the description discussed previously.

What are examples of specific activities of the preliminary project stage? Preliminary project stage activities include those activities that contribute to the determination of a final approach for the software project. Examples of these activities are determining the performance requirements for the software, for example, through a user needs analysis; determining the systems requirements for the software and that the technology needed to achieve performance requirements exists; exploring alternative means of achieving the specified performance requirements; selecting a vendor if commercially available software is to be acquired; and selecting a consultant to assist in the development or installation of the software.

In what development stage should data conversion activities be classified? If data conversion is considered to be necessary to make the computer software operational, then such activities should be classified as application development stage activities. Otherwise, data conversion activities should be considered post-implemen-tation/operation stage activities.

How should the costs associated with the modification of existing computer software be reported? The costs of modifying existing computer software should be reported using the development-stage approach if the

modification results in an increase in the functionality or efficiency of the software, or in an extension of the useful life of the software. Otherwise, the modification should be considered maintenance (post-implementation/operation stage activity) and the associated costs expensed as incurred.

Should business process reengineering activities be considered in applying the development-stage approach for internally generated computer software? No. Although business process reengineering activities may occur as a result of the development of computer software or may be part of a broad project that also involves the development of computer software, these activities should not be considered part of the process to develop the software. Generally, costs associated with business process reengineering activities, for example, performing a current state assessment or restructuring the workforce, should be expensed as incurred.

Are training costs capitalizable as part of a software asset? Generally, no. User training is specifically noted as one of the activities of the post-implementation/operation stage, and therefore, the costs of such training would be expensed as incurred. The training of employees involved with developing the software also should be expensed as incurred.

Can indirect costs, for example, overhead charges, allocated to a software development project be capitalized as part of the software asset or may only direct costs of development be capitalized? Neither GASB 51, nor GASB’s authoritative guidance for capital assets, specify whether indirect costs may be capitalized as part of the software asset. Allocation of indirect costs to a software development project is dependent on the policies of the government. are allocated, the principles

GASB 51 3

4 GASB 51

The increased focus on accumulating and

distinguishing the nature of costs associated

with software projects for financial

reporting purposes also will likely result in

a greater level of accountability for the cost

effectiveness and efficiency of such projects

on the part of IT professionals.

If indirect costs of the development-stage approach should be applied to determine whether such costs should be capitalized as part of the software asset or expensed as incurred.

If an activity that is normally part of the post-implementation/operation stage, for example, user training, occurs chronolog-ically during the application development stage, should the cost of that activity be capitalized as part of the software asset? No. The nature of the activity in the context of the development stages, not the timing of its occurrence, should be considered in determining the appropriate reporting of the associated costs. However, capitalization of application development-stage activity costs may not begin until preliminary project stage activities are completed and management has authorized and committed to funding the project.

How should the development-stage approach be applied to the development of an ERP system with multiple modules developed on individual timetables and becoming operational at different times? In this circumstance, the development-stage approach should be applied to each module of the system, as opposed to being applied to the system as a whole.

For more information, contact:

Manolet G. DayritPrincipal, IT Advisory

345 Park AvenueNew York, NY 10154-0102Tel 1 212 872 3854mdayrit@kpmg.com

us.kpmg.com

The information contained herein is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act upon such information without appropriate professional advice after a thorough examination of the particular situation.

© 2009 KPMG LLP, a U.S. limited liability partnership and a member firm of the KPMG network of independent member firms affiliated with KPMG International, a Swiss cooperative. All rights reserved. Printed in the U.S.A. 44854NYO