Accounting for Software Development Costs

By Paul Munter

In Brief

Toward Capitalization of Soft Assets

Faced with the increasing importance of software, AcSEC has issued SOP 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. A previous pronouncement related to the costs of developing software, SFAS No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, only addressed the costs of software intended to be sold. An initial determination will have to be made as to which pronouncement applies in the circumstances.

SOP 98-1 requires companies to capitalize and amortize the costs associated with developing or obtaining software for internal use. Such capitalization will depend on the stage of the project and only certain specific costs are to be capitalized.

The Emerging Issues Task Force, AICPA, and SEC have also issued pronouncements relating to accounting and disclosures related to software costs, some of which address the Year 2000 Issue.

In today's competitive economic environment, a key part of a company's strategic investments is its investment in technology. Companies now expend significant sums to develop, modify, test, and implement software. Furthermore, today's accounting software is not limited to the traditional general ledger and payroll packages. Indeed, software is an integral part of the manufacturing, distribution, and sales activities of companies in a wide array of industries.

While the corporate investment in software has been significant, the accounting model has been reluctant to acknowledge that these expenditures have future benefits. Thus, many have continued to question whether investments in other than tangible items should be capitalized. The reality in today's business environment is that many tangible manufacturing and distribution systems (such as buildings, machinery, and equipment) would not function without the software needed to operate them. For the tangible assets to truly contribute to the company's operations (i.e., to create a future benefit), the software component is needed.

As a result, there have been more and more frequent calls to allow the capitalization of software development costs as an asset. The point made is that the development and implementation of software is not conceptually different from the process of creating a tangible or "hard" asset, although it is riskier and the outcome more uncertain. Additionally, it is becoming more common for companies to have well-defined development methodologies and techniques in place to help minimize this development risk and reduce the related uncertainty associated with developing software for internal use.

In an effort to provide more specific guidance on the accounting for such costs, the AICPA's Accounting Standards Executive Committee (AcSEC) issued Statement of Position (SOP) 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. SOP 98-1 requires many companies to change their accounting for the costs of developing computer software intended to be used internally.

Background

In August 1985, FASB issued SFAS No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed. While conducting its deliberations on the subject, FASB was asked by some constituents to expand the scope to include accounting for all computer software costs regardless of whether the software would be marketed externally or used internally. In particular, in March 1985, the Management Accounting Practices Committee of the National Association of Accountants prepared an Issues Paper, Accounting for Software Used Internally, which proposed that the costs of internal-use software should be capitalized in certain situations.

In the end, FASB declined to expand the scope, concluding in paragraph 26 of SFAS No. 86 that--

accounting for the costs of software used internally is not currently a significant problem and, therefore, [FASB] decided not to broaden the scope of this project nor add a project on internal-use software to its ... agenda. The [FASB] recognized that the majority of companies expense all costs of developing software for internal use, and the [FASB] was not persuaded that this current predominant practice is improper.

However, the lack of authoritative guidance has, in fact, led to an increasing diversity in accounting for internal-use software costs in the decade since the issuance of SFAS No. 86.

Indeed, as AcSEC began its project on accounting for internal-use software, it made an evaluation of current practices and found several different accounting policies in place, such as the following:

* Expense all costs

* Capitalize all costs--including internal overhead costs such as computer usage time and other overhead costs

* Capitalize the cost of purchased software and expense the cost of internally-developed software

* Capitalize operating system
software and expense application software

It is not surprising that these diverse practices caused much concern, especially among the SEC staff. Thus, in November 1994, the SEC chief accountant asked the Emerging Issues Task Force (EITF) to develop guidance for these costs. Subsequently, however, the EITF and AcSEC agreed that an SOP should be developed.

Which Standard?

Since there are now two authoritative documents that address accounting for software development costs, the first issue to consider is whether SFAS No. 86 or SOP 98-1 is applicable. In making this determination, the critical issue for companies is whether they are developing new software with an intent to market it externally or developing new software for their own internal purposes. This is critical, because the accounting follows either SFAS No. 86 or SOP 98-1 (i.e., the project is either for internal purposes or for sale; not both). In particular, SOP 98-1 states that internal-use software has the following characteristics:

* The software is acquired, internally developed, or modified solely to meet the entity's internal needs.

* During the software's development or modification, no substantive plan exists or is being developed to market the software externally.

In substance, what this first requires is that the software be designed with unique applications to the company. In many cases, however, the absence of a marketing plan may be the critical factor in determining that SOP 98-1 applies, rather than SFAS No. 86. Importantly, SOP 98-1 notes that a substantive marketing plan would include activities such as selecting a marketing channel and identifying promotional, delivery, billing, and support activities.

Recently, some consulting firms have proposed that, once a project is completed for its client, the consulting firm would then try to market the completed software and would, if successful, share revenues with the original client. SOP 98-1 observes the following:

Arrangements providing for the joint development of software for mutual internal use ... are not substantive plans to market software. ... Similarly, routine market feasibility studies are not substantive plans to market software.

As such, this type of arrangement would not constitute a marketing plan, and the provisions of SOP 98-1 would be applicable.

Another consideration regarding applicability of the standards is that companies often find that software development is intertwined with research and development projects. Since SFAS No. 2, Accounting for Research and Development Costs, requires that companies expense R&D costs as well as disclose the amount of R&D expense for the period, it is important to properly classify such software costs as part of R&D to meet the requirements of SFAS No. 2. In particular, SOP 98-1 indicates that the following software-development costs are included as R&D expenditures:

* Software acquired for use in R&D activities where the software has no alternative future use

* Software related to a particular pilot project or used exclusively in a specific R&D project

SOP 98-1

In SOP 98-1, AcSEC has developed a model fundamentally consistent with the notion that software is an important strategic or economic resource of the company. As a result, SOP 98-1 requires companies to capitalize and amortize many of the costs associated with developing or obtaining software for internal use.

For computer software intended for internal use, AcSEC specifies that there are three stages to software development and use:

* The preliminary project stage

* The application development stage

* The post-implementation/operation stage

Preliminary Project Stage. During the preliminary project stage, the company is in the process of evaluating alternatives regarding the software project. This can include activities such as assembling the evaluation team, evaluating vendors' proposals, and considering other reengineering efforts. During the preliminary project stage, the company has not yet decided on a software development strategy or selected a vendor. Not surprisingly then, all such costs incurred during this stage would be expensed as incurred. Furthermore, there is no requirement to separately classify these costs in the income statement.

Application Development Stage. Once the company has made a determination as to how the software development work will be conducted, it will enter into the application development stage. At this point, the costs incurred to develop or obtain computer software for internal use must be capitalized and accounted for as a long-lived asset. Specifically, capitalization would begin when the following conditions are met:

* The preliminary project stage has been completed, and

* Management with the relevant authority, explicitly or implicitly, authorizes and commits to funding a computer software project and believes it is probable the project will be completed and the software will be used to perform the intended function.

Capitalization would cease no later than the point at which the software is substantially complete--including all necessary testing--and ready for use. The costs of testing as well as installing the software are capitalizable.

The costs to include as a long-lived asset once the capitalization period has begun would be the following:

* External direct costs (i.e., from third-party transactions) of materials and services consumed in developing or obtaining internal use computer software,

* Payroll and payroll-related costs for employees who are directly associated with and devote time to the internal use software project, and

* Interest costs capitalized in accordance with SFAS No. 34, Capitalization of Interest Cost.

General and administrative costs, as well as overhead and training costs, are not capitalizable costs of internal-use software.

Post-Implementation/Operation Stage. Once the internal use software is placed into service, the post-implementation/operation stage begins. The capitalized cost should be amortized over the period of expected benefit in a systematic and rational manner. Obviously, it can be difficult to accurately estimate the useful life for software, but a company should make an evaluation of the expected life of the software within the context of its own operations. In determining the expected period of benefit, companies should consider the effects of obsolescence, technology, competition, and other economic factors.

Determining the Costs to Capitalize

Interest. One question companies may have is how and why should interest costs be capitalized on these projects. SFAS No. 34 identifies qualifying assets for purposes of interest capitalization, one of which is an asset constructed as a discrete project for the entity's own use. Clearly, internal-use software is such an asset. Thus, interest would be capitalized on the internal-use software in accordance with the entity's existing interest capitalization policies. Thus, the decision of whether to capitalize interest on internal-use software depends upon its policy for capitalizing interest on tangible assets.

Training, Maintenance, and Enhancements. Once the software has been placed into service, it can be difficult to determine whether subsequent changes should be capitalized or expensed. When a company purchases software from a vendor and the purchase price includes training, maintenance fees for routine maintenance, and/or rights to future upgrades and enhancements, AcSEC requires that companies allocate these components based on the vendor-specific evidence of fair value. (This conclusion is consistent with AcSEC's conclusions in SOP 97-2, Software Revenue Recognition, although AcSEC is currently reconsidering certain parts of SOP 97-2.)

In evaluating whether or not to capitalize the costs assigned to upgrades, only upgrades or enhancements that can be demonstrated to have additional functionality beyond the original software would be capitalized. In short, the company should ask: Does this software now do something significantly different than it did previously? If the answer is not clearly yes, the costs should be expensed as maintenance. Importantly, AcSEC makes a distinction between increased functionality (an upgrade) and increased efficiency (maintenance). Modifications to software that allow the system to operate more efficiently while still performing the same functions do not result in capitalizable costs. Additionally, under SOP 98-1, the costs of training users on the use of the software would be expensed.

Impairment

Since SOP 98-1 requires that internal-use software be capitalized as a long-lived asset, it is not surprising that it also directs SFAS No. 121, Accounting for the Impairment of Long-Lived Assets and for Long-Lived Assets to Be Disposed Of, to be applied when determining whether there has been an impairment of the asset. In particular, AcSEC specifies that, when the internal- use software is no longer expected to be completed and placed in service, the asset should be treated as if abandoned or held for disposal. Under SFAS No. 121, this would result in the entire capitalized cost being recognized as an impairment loss, since the estimated selling price of an incomplete software product would typically be $0. Conversely, the application of SFAS No. 121 to software placed into service is very difficult since the software does not generate an identifiable stream of cash flows. As a result, it would seem the impairment issue for software placed into service is operationalized by having companies continue to make periodic assessments of the useful life of the software and make adjustments as necessary.

Internal Use Software Subsequently Sold

SOP 98-1 specifies that the company not have a marketing plan associated with the internal use software project during its development period. Nonetheless, it is possible the company might subsequently sell the software after it has been placed into service. The company should not recognize any profit until the aggregate proceeds from sales exceed the carrying amount of the software (i.e., the cost-recovery method would be applied). Subsequent proceeds would be recognized as earned.

Other Implementation Issues

Besides the accounting standards SOP 98-1 establishes, there are other significant implementation issues that companies will face. These issues include determining the capitalization costs and data conversion costs.

Determining Costs to Capitalize. Companies now need to determine what payroll and payroll-related costs and external direct costs to capitalize. To measure the payroll and payroll-related costs, it will be necessary for companies to have some measure of the time spent by its employees working on software development. Furthermore, these employees are not restricted to programmers and others directly developing the software. In most significant software development projects, the company has a team involved that would include some user representatives whose payroll costs would also be included in the capitalizable amounts.

Some companies have argued that they can avoid the need to track employee time by contracting the development of the software to an outside consulting firm. Though elegant in theory, the reality is that virtually no company is willing to give an outside consulting firm carte blanche. In almost all large software development projects, the company will have some of its own people involved in the project.

The external direct costs may seem to be an easier item to get a handle on, and, in many cases, they are. However, if the contract with the outside company is a bundled arrangement (meaning that it includes several components, such as software development and installation, training, and maintenance), the company will need to unbundle the contract, because some of its elements are capitalizable while others are not.

Data Conversion Costs. Paragraph 22 of SOP 98-1 discusses data conversion costs and notes that data conversion costs, "except as noted in paragraph 21, should be expensed as incurred." While this appears to be straightforward, paragraph 21 of SOP 98-1 discusses the capitalization of software development costs. Thus, a reading of those two paragraphs could lead to confusion. The reality is that AcSEC is making a distinction between the writing of software to facilitate data conversion (sometimes referred to as bridging software) and manually converting data for use by the new system. Clearly, it is the intent of AcSEC that manual data conversion efforts do not result in capitalizable costs. Conversely, the costs of developing bridging software are capitalizable under SOP 98-1. A problem that may result with capitalizing bridging software is that the software may only be used for this specific data conversion effort (i.e., there is no alternative future use to the bridging software). In that case, while the costs of developing the bridging software are capitalizable, its useful life would be of such short duration as to effectively preclude capitalization. Therefore, in determining the capitalizability of bridging software, it is extremely important that the company also assess whether there is an alternative future use to the software.

Year 2000 Issues

In addition to the basic issue of software development, many companies are concerned about their existing software's ability to process information into the Year 2000. This concern has caused many companies to engage in more rapid software development and modification of existing systems than would have been contemplated otherwise. There is the additional complication that many software projects are only one component of a broader reengineering effort within the company. These issues have been addressed in several different standards. Exhibit 2 summarizes the applicability of each of these standards.

In EITF Issue 96-14, Accounting for the Costs Associated with Modifying Computer Software for the Year 2000, the EITF was asked to determine the appropriate accounting when companies modify existing software so that it will be Year 2000 compliant. Some argued that these costs should be capitalized because the efforts extend the useful life of the software. However, the EITF concluded that the costs incurred to make existing software Year 2000 compliant should be expensed as incurred.

As can be seen, EITF Issue 96-14 has substantially different accounting conclusions from SOP 98-1, thus the applicability of the documents is critical. As Exhibit 2 indicates, EITF Issue 96-14 is applicable only in the specific situation where a company will be modifying existing software to make it Year 2000 compliant, i.e., software that is identical except in its ability to process a four-digit date field. If the company is going to obtain or develop new software, whether motivated by Year 2000 concerns or not, SOP 98-1 would apply.

Reengineering

The issue of reengineering was discussed in EITF Issue 97-13, Accounting for Costs Incurred in Connection with a Consulting Contract or an Internal Project That Combines Business Process Reengineering and Information Technology Transformation. In Issue 97-13, the EITF notes that in today's business climate it is quite common for companies to enter into consulting contracts that will combine business process reengineering and information technology transformation. These consulting services may include software development, software acquisition, software implementation, training, and ongoing support in addition to the business process reengineering. Indeed, the business process reengineering may be either a component of some of the software-related activities or a separate activity.

As Exhibit 2 shows, the EITF concluded that the cost of business process reengineering activities is to be expensed as incurred regardless of whether the business process reengineering is undertaken as a separate project or as part of a larger project that includes software development. In situations where an outside consultant is used to complete a business process reengineering project, the total consulting contract price should be allocated to each activity based on the relative fair values of those separate activities. This allocation should be based on the objective evidence of the fair value of the elements in the contract, not necessarily the separate prices stated within the contract for each element.

Disclosure Issues

Exhibit 2 also shows that the AICPA and SEC have offered additional guidance that focuses on disclosure rather than accounting issues.

The AICPA Guidance, The Year 2000 Issue: Current Accounting and Auditing Guidance, amplifies the accounting guidance contained in SOP 98-1, EITF Issues 96-14 and 97-13, as well as offering specific guidance for auditors in assessing the appropriateness of the client's accounting and the adequacy of its disclosures.

SEC Staff Legal Bulletin No. 5, Year 2000 Disclosure Issues, (which, of course, is focused on disclosure issues for SEC registrants) notes that companies may need to discuss Year 2000 issues in the following parts of an SEC filing:

Management's Discussion and Analysis of Financial Condition and Results of Operations, if the cost of addressing the Year 2000 issue is a material event or uncertainty that could cause the reported financial information to be misleading of future trends or if the costs or consequences of incomplete or untimely resolution represent a known material event or uncertainty that is reasonably expected to affect future financial results

Description of Business, if Year 2000 issues materially affect the company's products, services, or competitive conditions

Form 8-K, under Item 5 (other important matters), if Year 2000 costs or consequences reach a significant level of importance.

Special Disclosure Considerations. If the company has not assessed its Year 2000 issues or not yet determined whether the issues are material, the SEC staff believes the following disclosures are required:

* The company's general plans to address Year 2000 issues as they relate to its business; operations and operating systems; its relationships with customers, suppliers, and other constituents; and timetable for completing the plans.

* The total dollar amount the company estimates will be spent to remediate its Year 2000 issues *

Paul Munter, PhD, CPA, is the KPMG Peat Marwick Scholar and chair of the Department of Accounting at the School of Business Administration, University of Miami, Fla.

The new SOP on internal use software changes the picture.

The CPA Journal is broadly recognized as an outstanding, technical-refereed publication aimed at public practitioners, management, educators, and other accounting professionals. It is edited by CPAs for CPAs. Our goal is to provide CPAs and other accounting professionals with the information and news to enable them to be successful accountants, managers, and executives in today's practice environments.