Connect with us


Tax Treatment for Research and Development Costs of Software



Tax Treatment For financial accounting purposes research and development costs are generally expensed in the year incurred, in accordance with FASB Statement No. 2, Accounting for Research and Development Costs. Certain costs associated with developing software must be capitalized for financial accounting purposes under FASB Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed. Expensing generally applies to these types of costs for tax purposes. This post discuss tax treatment and some rules that specifically applicable to a reasearch and development cost of software. But, before discussing the rules governing software development costs, a brief review of the underlying rules on the tax treatment of research costs maybe appropriate.



Underlying Rules On Tax Treatment Of Research Cost

The tax rules permit either current expensing or capitalization and amortization of certain research and development costs over a period of 60 months or less. Under definitions developed in the 1950s, the tax laws refer to the costs that may be treated in this manner as “research or experimental expenditures.” This terminology was originally intended to refer to the usual and customary costs associated with industrial and commercial research and development.

The tax law definition of research or experimental expenditures is slightly broader than the financial accounting concept of research and development costs. This distinction generally has limited practical significance, however, because few companies separately compute research or experimental expenditures for tax purposes. Moreover, most companies expense currently their research or experimental expenditures. For these reasons, the deduction of these costs is often the same for financial accounting and tax purposes. These general rules governing the treatment of research or experimental expenditures applied to software development costs until 1969.


Software-Specific Rules

The decision to unbundle hardware and software set into motion the AICPA Task Force on Accounting for the Development and Sale of Computer Software. The IRS also acted in response to this development by promulgating a series of examination guidelines relating to software costs. These guidelines, published in Rev. Proc. 69-21 (1969–2 C.B. 303), included guidelines permitting current expensing or optional capitalization and amortization of software development costs. Revenue Procedure 69-21 permits software development costs to be currently expensed or capitalized and amortized over a period of 60 months or less. This treatment applies to the costs of developing software for sale and to the costs of creating software to be used by a company in its business.

This treatment is substantially similar to the treatment of research costs under Rule 174 of the IRC. Although 60-month amortization of capitalized research costs is the general rule in both of these areas, Rev. Proc. 69-21 permits capitalized software costs to be amortized over a period shorter than 60 months if the taxpayer can justify a shorter life to the satisfaction of the IRS. The IRS has not issued any guidance on how a shorter life might be established and there exists no specific authority on this issue. It is likely, however, that 60 months may be too long a life in many cases, given the pace of technological development within the software industry today.
For purposes of Rev. Proc. 69-21, the term “computer software” includes:

. . . All programs or routines used to cause a computer to perform a desired task or set of tasks, and the documentation required to describe and maintain those programs. Computer programs of all classes, for example, operating systems, executive systems, monitors, compilers and translators, assembly routines, and utility programs as well as application programs are included. “Computer software” does not include procedures which are external to the computer operations, such as instructions to transcription operators and external control procedures.


This definition was updated and expanded in proposed regulations issued in January 1997 concerning the amortization of certain intangibles. According to the proposed intangibles regulations, computer software is any program or routine (that is, any sequence of machine-readable code) that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain those programs. It includes all forms and media in which the software is contained, whether written, magnetic, or otherwise. However, computer software does not include any data or information base unless the item is in the public domain and incidental to a computer program. The requirement that a database must be in the public domain is in contrast to the definition of “computer program” provided in the proposed software regulations, which did not have a similar requirement. However, both definitions require the database to be incidental to the computer program.

The proposed intangibles regulations also include other provisions of importance to software companies. In general, these regulations provide for 15-year amortization of certain software costs that are not specifically provided for in other sections. Examples of non-15-year software include software included in the cost of computer hardware, which is capitalized and depreciated along with the hardware, and software that is readily available for purchase by the general public, which is amortized over a 36-month period.

A potential problem for software companies is that the proposed regulations appear to require capitalization and amortization over a 15-year period of all amounts paid pursuant to a license of intangibles. If the proposed regulation is not changed, all royalty payments paid as a result of licensing transactions would have to be amortized over 15 years instead of being fully deducted in the year paid.

Note: It is important to note that, in spite of these proposed regulations, Rev. Proc. 69-21 continues to be used to provide guidelines for deductibility of certain software costs and carries substantial precedential value since proposed regulations do not become law until they are issued as final regulations.


Limitations on Revenue Procedure 69-21

The tax treatment of software development costs under Rev. Proc. 69-21 is similar to the treatment of research or experimental expenditures. The IRS did not adopt the view that software development costs are section 174 costs under Rev. Proc. 69-21. Instead, the IRS reasoned that: The costs of developing software (whether or not the particular software is patented or copyrighted) in many respects so closely resemble the kind of research or experimental expenditures that fall within the purview of section 174 of the Internal Revenue Code of 1954 as to warrant accounting treatments similar to that accorded such costs under that section. However, in guidelines announced in Rev. Proc. 97-50 for costs related to ensuring Year 2000 compliance of computer systems, the IRS states that these costs fall within the purview of Rev. Proc. 69-21. The direct reference to Rev. Proc. 69-21 is significant because the IRS continued to uphold this definition of software development costs during a time when defining these types of costs has become very contentious.


Capitalization of Software Development Costs

Under general tax accounting principles, expenditures resulting in a self-constructed asset having a useful life extending substantially beyond the end of a taxpayer’s year must be capitalized. In the event that the capitalized costs have a determinable useful life, they may be recovered through either depreciation or amortization deductions over that life.

An exception to these general rules is provided, however, for research or experimental expenditures as defined in IRC 174. Moreover, software companies may avoid capitalizing these costs under Rev. Proc. 69-21, if they follow one of the two specific alternative methods of accounting for these costs. Thus, software companies may be protected from capitalization of software development costs under § 174 or Rev. Proc. 69-21.

In March 1993, the IRS stated that it “has no present intention of changing its administrative position contained in Rev. Proc. 69-21, but continues to study its viability”. The IRS concluded affirmatively that “as long as Rev. Proc. 69-21 remains in effect, taxpayers are not required to capitalize (and may currently deduct) computer software development costs.” As discussed in Section 11.3 (c), the IRS seemed to uphold the validity of Rev. Proc. 69-21 in Rev. Proc. 97-50.

Important note: Once the decision of deducting or capitalizing software development costs is made, it must be consistently followed from year to year in accordance with the consistency rules generally applicable to accounting methods that were outlined in section 9.2(b).


In 1994, the IRS issued a ruling in which an accounting method change that was implemented without permission was sanctioned by the IRS. This ruling, which appears contrary to the IRS’s own regulations, may have been designed to require the taxpayer to continue capitalizing software development costs. In Private Letter Ruling 9421003, a taxpayer in the oil and gas pipeline business began capitalizing software development costs for financial accounting purposes and unknowingly followed this treatment for tax purposes for five years.

When the taxpayer discovered the new treatment of software development costs, it filed amended tax returns in an effort to revert to its long-standing method of expensing software development costs in the year incurred. The IRS rejected this treatment, thereby sanctioning the change that had been implemented without permission, following the theory that the taxpayer had established a new method by capitalizing a portion of its software development costs. Having sanctioned the unauthorized change, the IRS went on to rule that the taxpayer could not correct its unauthorized change by amending its returns because this would be contrary to its newly established method of capitalization.

In March 1998, the Accounting Standards Executive Committee (ASEC) of the American Institute of Certified Public Accountants (AICPA) released new guidance with respect to internal use software in Statement of Position (SOP) 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use.


While the financial accounting ramifications are discussed in detail elsewhere, this does not change the accepted tax accounting methods for development of internal use software found in Rev. Proc. 69-21 and Sec. 174. Thus, in order to avoid the result of PLR 9421003, companies should be careful to not change their tax method of accounting for these costs by inadvertently following the new financial accounting guidelines in SOP 98-1 for tax purposes.

Finally, it should be noted that the IRS views as appropriate the capitalization by software companies of the costs of duplication and packaging of individual items of software offered for sale in accordance with the general inventory capitalization rules.


Deductible Contract Research Costs

The tax rules permit a software company to deduct not only research or experimental expenditures arising from research activities conducted by the company, but also permit amounts paid for qualifying research conducted by another company (or individual) on the software company’s behalf to be deductible as research costs. The determination of when payments made to a third party are for research conducted on behalf of the software company is difficult. In order to claim that payments were for contract research expenses, the software company must bear the expense of the research regardless of the outcome of the research effort and the software company must benefit from the effort. A software company will benefit from a research effort if it obtains rights to exploit the research results by virtue of the payments.

Because it is difficult to determine which of two parties to a contract may consider the research to have been conducted on its behalf, situations occasionally arise where both parties to the contract will claim the research costs as their own. The IRS has recently become aware of some of these situations and is becoming more aggressive in examinations in this area. The IRS is particularly interested in the risks under a contract and frequently evaluates warranty provisions and guarantees in light of software company claims that they are a risk. The IRS also evaluates whether software companies retain meaningful rights to exploit research results.

The contract research rules are essentially the complement of the research credit funding rules. For this reason, it is often useful to evaluate contract research arrangements in light of the research credit funding rules. The research credit funding rules are discussed toward the end of the next subsection.


Research Credit

As noted above, a credit for increasing research expenditures was enacted in 1981. Because the credit was intended to provide an incentive for increases in research spending, the research credit is available for qualified research costs incurred in any given tax year, in excess of a taxpayer-specific base amount. The credit applies at a rate of 20 percent of the excess of qualified research costs over the base amount. The research credit originally applied to almost all product development costs that were made to the definition of costs eligible for the credit; in 1989, the manner in which the credit was computed was significantly changed.

The research credit was initially enacted with a sunset provision in order to provide Congress an opportunity to re-evaluate its effectiveness before a more permanent incentive was put in place. Because Congress in recent years has been perpetually short of money to provide tax incentives, the research credit has been enacted for only limited periods each time it has been extended. (The credit has ultimately been extended each time). In the two situations where it was permitted to expire, Congress provided both a retroactive and prospective extension, thereby preventing gaps in the application of the credit rules.

The taxpayer-specific base amount is currently computed using a research intensity concept. The foundation of this concept is the idea that taxpayers should continue to dedicate a historic proportion of sales to their research efforts. Thus, the research credit rules refer back to the years 1984 through 1988 and use this period of time to compute the ratio of qualified research costs to sales. This historic ratio is then applied to a rolling average of the prior four years’ gross receipts to arrive at the annual base.

Special rules apply to “start-up” companies that did not have research and sales in the majority of the years 1984 through 1988. Qualified research expenses incurred in any given year in excess of the base may give rise to research credits.


For companies in the business of developing computer software for sale, the research credit generally applies to the qualifying costs that are directly attributable to the research efforts conducted to create products for sale. Qualified costs include wages, supplies, and 65 percent of contract research payments. The costs of acquiring machinery and equipment, depreciation on property (e.g., computers) used in the performance of research, and overhead costs allocated to research efforts through burden rates on labor or otherwise are not credit-eligible.

In evaluating the research credit, an important consideration for software companies is the special research credit funding rules. Under these rules, software companies must omit from their research credit computations otherwise qualifying research costs to the extent of funding amounts received. These rules must be considered where research is performed under a customer contract.

There appears to be an infinite variety of customer contractual arrangements that must be considered in light of the funding rules. Analyses of these arrangements must be made in light of two key elements of the funding rules: (1) rights in the research results and (2) risks under the contract.

A software company must retain substantial rights in the software created under the contract in order to claim the research credit. If substantial rights are not present, the software company must exclude from its research computation all otherwise qualifying amounts incurred under a contract.

A common example of a situation in which a software company does not retain substantial rights is the situation where the company is prohibited from marketing the software created under the contract. Substantial rights are also not retained where the software company must pay the funding company a market value royalty on subsequent sales of the software. In these situations, the funding company will be treated as the owner of the software. If a software company retains substantial rights, it may claim the research credit on costs incurred pursuant to the contract, but only to the extent the software company is at risk for the amounts incurred. Thus, if a software company enters into a time-and-materials contract to create software for another party, none of the amounts would be incurred at the software company’s risk because the company will be reimbursed for its expenses.

On the other hand, where the contract calls for the software company to create software that performs specified functions for a specified price, the software company is fully at risk and may claim the credit because the contract is essentially a contract for the purchase of finished software.
As noted above, the IRS in recent years has begun to examine with greater intensity contractual arrangements involving research. Because of the rich variety of the arrangements and the complexity of the rules, this can be a troublesome area for software companies. The IRS has been particularly aggressive in examinations of government contracts.

The research credit may also be available to software companies for qualified costs to create software for internal use. For example, the research credit applies for software created by the taxpayer for use in other qualified research activities. Thus, the research credit may apply for the qualifying costs incurred by a software company to develop software programming tools for use in creating new or improved products for sale.

In early 1997, proposed § 41 regulations were issued dealing with the qualification of internal use software for the research credit. The proposed regulations do not appear to create any new rules or requirements; rather, they appear to generally follow the legislative history of the Tax Reform Act of 86 (TRA 86), which established a three-part test that internal use software be “innovative,” involve significant economic risk, and not be commercially available (in addition to the general requirements for credit eligibility).

Several groups, representing high tech companies have asked Treasury to consider several changes:

First an ambiguous reference to a “high threshold of innovation” can be construed as a fourth test, in addition to the three-part test, which is inconsistent with legislative intent.

Second, a clarification was requested to clearly state the credit eligibility of general and administrative software and software written to perform non-computer services such as banking or accounting, provided all tests for credit eligibility are fulfilled.

Third, Treasury was urged to implement an activity-based approach consistent with the final § 174 regulations to focus on the nature of the activities being performed instead of the end result of the research.

Are you looking for easy accounting tutorial? Established since 2007, hosts more than 1300 articles (still growing), and has helped millions accounting student, teacher, junior accountants and small business owners, worldwide.