• United States



by Cal Braunstein

Accounting For Software Acquisitions and Development

Jul 12, 19997 mins
CSO and CISOData and Information Security

RFG believes that as organizations determine to either purchase or internally develop software solutions, tax ramifications need to be considered. Indeed, the CIO should understand and review each software acquisition/development as it relates to the tax liability of the corporation. Statement No. 86 of the Federal Accounting and Standards Board (FASB) outlines when software may be capitalized versus expensed. CIOs should understand how expensing or capitalizing software impacts the corporation as a whole.

Business Imperatives:

  • Software developed internally must be expensed (full cost deducted in the year in which it occurs) until completion of a trial solution or detail program design or specifications. However, in subsequent phases of development, the costs must be capitalized or spread out over three-to-five years. CIOs should discuss the tax ramifications of internally-developed software solutions with their CFOs or corporate tax accountants.
  • Software that is acquired must be capitalized after completion of initial implementation/integration specifications. In order to minimize that portion of a software project that must be expensed, CIOs should discuss tax ramifications with their finance colleagues to determine the best way to structure the software-implementation project.
  • According to a 1998 survey by the University of California, Los Angeles (UCLA) and New York University (NYU), investors consider software capitalization as a criteria in determining an organization’s value. Investors tend to undervalue organizations that expense all their software development costs. CIOs and their financial colleagues need to evaluate the impact of software development tax treatment on stock prices.
  • Software development tools and methodologies are drastically different from those employed in 1985 the year in which FAS 86 was created. Software development firms, accounting organizations and many large public organizations have been politicking for a revision to this accounting rule. As proposals are heard by FASB, there is agreement that a more practical approach to software capitalization is needed. CIOs with their financial colleagues should be working with organizations such as the Institute of Management Accountants to have this rule modified.

Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, impacts not only those firms developing, distributing or selling software but any organization that purchases or internally-develops software solutions. CIOs must not only understand how this accounting rule affects the tax liability of the organization but how it impacts the overall value of the corporation.

“This statement specifies that costs incurred internally in creating a computer software product shall be charged to expense when incurred as research and development until technological feasibility has been established for the product. Technological feasibility is established upon completion of a detail program design or, in its absence, completion of a working model. Thereafter, all software production costs shall be capitalized and subsequently reported at the lower of unamortized cost or net realizable value. Capitalized costs are amortized based on current and future revenue for each product with an annual minimum equal to the straight-line amortization over the remaining economic life of the product.” (Summary of Statement No. 86, issued August 1985, FASB)

As all CIOs know, organizations depend on IT infrastructure to run their businesses. From large enterprise resource planning systems to the Microsoft Excel spreadsheet on an employee’s desktop, software has become an integral part of the cost of running a business. And as with all operating costs, there are tax ramifications to each and every purchase. In 1985, FASB created FAS 86 which established procedures for the expensing and/or amortization of software. During the last decade however, technology has evolved software and software development tools so that the old guidelines are no longer meaningful. Software is developed and upgraded on a six-month cycle something unheard of when this regulation was put in place. Additionally, software life can be anywhere from six months to unlimited years. Tax amortization and expense schedules from more than ten years ago unjustly prevent an organization from realistically valuing these solutions.

There are many ways for a CIO to help the enterprise maximize shareholder value through the creative accounting of software development and purchase. The CIO needs to work in concert with the financial executive to determine when it is best to roll software purchases together such as individual purchases of desktop software to allow capitalization of that software. This demands constant participation by the CIO and the IT staff in all software purchases. Not only does this need to be managed from a support standpoint but if the CIO can help the firm maximize the tax treatment, this will increase his or her viability as a member of the executive team.

Additionally, internally-developed software systems may be best-structured to take advantage of tax treatments. In other words, to minimize that portion of the project that must be expensed in the year in which the expense occurred, the development methodology could be switched from a traditional design-code-test approach to a design-prototype approach which reduces the expense side of the effort. By working with the finance executive the CIO can determine what method will, within reason, work to the firm’s advantage. After all, software vendors such as Microsoft have no problem reducing the design effort and emphasizing the “code-fix” phases. By releasing “half-baked’ code on the market they manage to maximize shareholder value. It should be noted that RFG is not proposing CIOs revert to shoddy coding methods to accommodate tax benefits but that different development methodologies can result in different tax treatments.

There is a concerted effort underway, however, to either discard FAS 86 or modify it to allow more meaningful tax treatment of software development and acquisition. Organizations such as the Institute of Management Accountants have presented Statements of Position (SOP) that encourage FASB to modify this regulation to better represent the value that software solutions bring to a firm. These proposals seek to clarify the tax treatment of R&D, software used in the production of core products and services, implementation and training of such software solutions. Additionally, these proposals point out the intrinsic value to the firm of these software solutions. The American Institute of Certified Public Accountants (AICPA) has also released several SOP in 1998 dealing with the complexity of recognizing revenue form software and how organization may account for software acquisitions. It is clear that there is movement underway to drastically change the way businesses must account for the sale and purchase of these assets. The Year 2000-compliance effort has helped increase the urgency of this need as organizations are being forced to expense millions of dollars of software modification.

Indeed, it has been discovered that investors and shareholders consider the tax treatment of software development and purchase when evaluating the organization. A recent study completed by UCLA and NYU states that the stock of firms that expense all of the costs related to software development or acquisition is undervalued by potential investors and analysts.

As an executive with the corporation it is the CIOs’ duty to maximize shareholder value. It is the CIOs’ responsibility to work with the tax accountants of the organization and determine the best way to maximize each and every software development and purchase. With the current ambiguity in the tax law, organizations are capturing software development and purchase differently. This leads to some organizations valued more favorably than others. Working with the financial executive, the CIO needs to help determine the best approach for valuing every software development project and acquisition that will help present the organization favorably to shareholders and potential investors. The CIO also needs to help the financial executive understand the value of any project or acquisition beyond the tax ramifications to ensure that a project or purchase is not denied based solely or largely on its tax treatment.

RFG believes that until FAS 86 is amended or replaced, CIOs need to play an active role in ensuring that the tax treatment of software projects and purchases reflects the organization positively to investors and shareholders. Additionally, the CIO needs to work closely with the financial executive to determine the costs associated with and useful life of every project and purchase.

© 1999 Robert Frances Group. All rights reserved.

Cal Braunstein is CEO and Principal Analyst for the Robert Frances Group. He can be reached at 203-291-6900 or