Eligibility of internal-use software for research credit needs clarification.

Prop. Regs. Sec. 1.41-4, released Dec. 31, 1996, addresses the Tax Reform Act of 1986 (TRA '86) provision on eligibility of internal-use software for the research credit. The proposed regulations generally track the legislative history underlying Sec. 41(d)(4)(E), with little elaboration. In the absence of further guidance, a recent U.S. magistrate's opinion used a questionable reading of the legislative history to deny the credit for costs of developing software to automate and computerize a wholesaler's business operations (United Stationers, DC Ill., 3/18/97). Regardless of the final outcome of this case, it indicates that some IRS agents have a very restricted view of the circumstances under which internal-use software development costs can qualify for the credit.

The taxpayer in United Stationers, the nation's largest independent office products wholesaler, had been unable to satisfy customer demand after a rapid growth rate in annual sales. The taxpayer developed seven software programs to increase its business efficiency and claimed a research credit of $156,000. The programs were designed for document retention and retrieval, centralized invoicing, marketing, computer-to-computer order entry, inventory maintenance, shipment processing, and inventory forecasting and replenishment. All of these functions, not previously automated, enabled the taxpayer to manage its growing customer demand so that the business process add workflow efficiency improved markedly.

In denying credit eligibility, the magistrate's opinion quoted extensively from the legislative history of the TRA '86, stating that the scope and applicability of the credit "remain ambiguous" and that there is "very little case law even discussing the issues." Turning first to the general "technological in nature" requirement for the credit, the magistrate virtually ruled out eligibility for internal-use software, writing that the credit is limited to "widely applicable, high technology advancements" that benefit "aspects of the country's economy." The magistrate found that "merely adding a new program to a computer so that it becomes a more efficient tool for a particular business" does not meet the test. The TRA '86 legislative history, however, stated that research that "fundamentally relies" on principles of computer science satisfies the "technological in nature" test; there is no requirement that the taxpayer produce "widely applicable" advancements enhancing other businesses.

In a second questionable reading of the legislative history, the opinion interpreted the "process of experimentation" test to mean that Congress intended the credit for "ventures into uncharted territory," e.g., to develop technology to use computers "in a manner that was never before available" or "to develop a new realm of computer science." The taxpayer's activities did not meet these standards, the magistrate said, since there was no uncertainty that computers could perform bookkeeping functions. By contrast, the legislative history defines "process of experimentation" as "a process of scientific experimentation or engineering activities to design a business item where the design of the item as a whole is uncertain at the outset, but instead must be determined by developing one or more hypotheses for specific design decisions, testing and analyzing those hypotheses .... and refining or discarding the hypotheses as part of a sequential design process to develop the overall item." (Emphasis added.)

The magistrate also concluded that the taxpayer's software development faded to satisfy the first two elements of the three-part additional test for credit-eligible internal-use software: (1) that the software is innovative, (2) that the software development involves significant risk and (3) that the software is not commercially available. The opinion stated that the software programs "were not innovative, nor did they create a revolutionary new way to organize businesses, such that the efficiency or productivity of the market would be greatly affected." The magistrate agreed, however, that the taxpayer's efficiency and revenues had increased. This would seem to reflect that the software -- which was not commercially available -- was innovative in improving the efficiency in delivery of the taxpayer's goods.

The TRA '86 legislative history stated the first test as follows: "[T]he software is innovative (as where the software results in a reduction in cost, or improvement in speed, that is substantial and economically significant)." The magistrate stated that "qualified software must provide a substantially significant improvement in speed, as well as a reduction in cost, that is economically significant." (Emphasis added.) Here, the opinion misstated the legislative history, since either a significant reduction in cost or a significant improvement in speed is an example of innovative software.

As to the second test for internal-use software, the magistrate stated that the taxpayer's development of the programs did not involve an economic risk, "since the ability to implement them was clear from the outset." The relevant test, however, is whether the means to develop the product or process is known or is uncertain at the outset. In this regard, it is instructive that the preamble to the final regulations under Sec. 174, allowing current deductibility of research expenditures, states that "a taxpayer's knowledge that a product development project will be successful does not preclude the process of determining the appropriate design of the product from qualifying as research." Thus, Regs. Sec. 1.174-2(a)(1) clarifies that "[u]ncertainty exists if the information available to the taxpayer does not establish the capability or method for developing or improving the product or the appropriate design of the product."

The opinion also seems incorrect in concluding that the taxpayer did not bear any economic risk; the risk existed in how much time, expense and other resources would be necessary to develop the software, not whether the software eventually would be completed. Further, because the IRS had conceded that the software development activities met the Sec. 174 requirements for deductibility, the activities, ipso facto, involved uncertainty. Economic risk was present because the taxpayer funded the activity itself with no source of replenishment other than internal generation, and because it was technically uncertain as to how to successfully develop the software.

Apart from the questionable interpretations of Sec. 41 and its legislative history in the magistrate's opinion, Prop. Regs. Sec. 1.41-4 introduces some additional confusion by suggesting that even if a taxpayer satisfies the three-part test for internal-use software, it must also show that the research activities resulted in a "high threshold of innovation." The legislative history, however, merely used that term as a shorthand reference to the three-part test, and did not create a fourth test or separate standard. To avoid misunderstanding, the proposed regulations should be clarified by deleting the reference.

The regulations should also provide expressly that computer software is eligible for the credit when it is to be used internally (e.g., in general and administrative functions), provided it meets the three-part test. An explicit statement to that effect might deter agents and courts from following the language of the magistrate's opinion in United Stationers.