The Tax Reform Act of 1986 enacted section 41 of the Internal Revenue Code setting forth the requirements that research projects must meet to qualify for a research tax credit. Section 41(d)(4)(E) provides that, except to the extent provided by regulations, research with respect to computer software that is developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use is excluded from the definition of qualified research under section 41(d). The 1986 Act’s legislative history indicates that the regulations were to incorporate an additional three-part high threshold of innovation test that internal use software must clear to obtain the research credit. Hence, developers of internal use software are less likely to qualify for a research credit than other software developers and developers of other types of products.
When Congress in 1986 enacted the research credit, computers were still mostly mainframe machines that filled rooms and cost millions, and most companies were not creating their own software. Instead companies largely purchased software for its general and administrative functions and internal development was mostly customizing the purchased software. While customizing such software for a large company can be expensive and time consuming, such activities do not seem to rise to the level of research. In such an environment, one can see why Congress may have wanted to set a higher standard for allowing a research credit for internally developed software.
On January 16, 2015, Treasury released proposed regulations addressing internal use software. As the preamble to the proposed regulations recognizes: “Today, computer software is used in all aspects of business activity, especially in providing goods and services to third parties, and such software has played a vital role in increasing the productivity of the U.S. economy and in making the U.S. more competitively globally.” The proposed regulations will now reward more software activities by removing from the definition of internal use software most software that customers use on a taxpayer’s website. However, significant portions of taxpayers’ software development will continue to face a higher standard than other types of research.
Prior to the proposed regulations, classification as internal use software primarily focused on whether a separate payment was made for the use of the software. Those rules did not envision the growth of the internet and a world where software provides many valuable services to third-party customers without a separate charge. As a result, many disputes arose regarding whether software development projects satisfied the three-part high threshold of innovation test for internal use software.
Under the proposed regulations, software that “is developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or to review data on the taxpayer’s system” is not internal use software. The examples in the proposed regulations confirm that common situations such as software that enables customers to place and track orders on-line or software for a photo editing site supported through advertising are not internal use software. Hence, developers of many software applications that customers use to access websites on their computers, tablets, and mobile devices should now be able to claim the research credit without having to satisfy a higher standard of innovation.
While the proposed regulations are a huge step forward, they cannot avoid the statutory mandate that the expenditures for internal use software must meet a higher threshold in order to receive the research credit. Considerable resources are still devoted to software that performs general and administrative functions. The proposed regulations attempt to provide a reasonable balance between the Congressional dictates and the modern world, but careful attention remains necessary to properly classify projects and to document qualified activities.
For example, the regulations attempt to deal with the fact that software projects are not always neatly divisible between internal and third-party functions. While software that enables the customer to place and track orders is not internal use software, such software will often be part of a development project that includes software that performs general and administrative functions supporting the conduct of the taxpayer’s trade or business, such as software that processes payments, and therefore would constitute internal use software.
Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(C) attempts to address this type of dual development issue. Prop. Reg. § 1.41-4(c)(6)(iv)(C)(2) allows taxpayers to attempt to isolate a subset of software elements that only enables a taxpayer to interact with third parties or allows third parties to initiate functions. Establishing a record keeping system to use this provision is likely to prove challenging for most taxpayers. Perhaps in recognition of this fact, Prop. Treas. Reg. § 1.41-4(c)(6)(iv)(C)(3) provides safe harbor of allowing 25 percent of the expense for developing dual function software. However, taxpayers still must be able to show that at least 10 percent of the dual function software will be used by third parties.
The proposed regulations try to clarity the three-part test for innovative software. The regulations are faithful to the legislative history in that they require that the software provide a significant reduction in cost or improvement in speed, involve a significant risk that the investment will not be recovered in a reasonable time because of technical risk, and that no existing commercially available software could perform the function. While the third requirement is usually straightforward, the other two requirements can be contentious.
Although estimates are often made of the benefits expected of a software development project, such records may reside in the finance department, or some other department, and may not be known to the tax department when it is seeking to collect documentation for the research credit. Taxpayers and IRS auditors are also prone to have different views on what is economically significant improvement. In particular, one can readily see disagreements about whether a $1 million savings at a company with $10 billion in sales is significant.
Showing a substantial economic risk that the investment will not be recovered within a reasonable time because of a technical risk will require the tax department to be proactive in documenting such risk. The examples attempt to illustrate what situations the IRS may regard as a technical risk: “Specifically, X was uncertain regarding the capability of developing, within a reasonable period, a new database architecture using the old technology that would resolve its technological issues regarding the data modeling capabilities and the integration of the disparate system into one system.” Given that many software development projects will need to integrate multiple platforms as well as legacy software and numerous databases, many projects are likely to face these types of technical risk.
Unfortunately, the written record will rarely highlight such issues. The documents most likely to be retained will be those that reflect a tentative strategy for resolving the technical risk. For example, a document seeking approval of a project most likely will embody a strategy that will address the technical risks. Serious risks may still exist, but they are most likely presented in a way that stresses the approach to resolve the problem. Unless the tax department gathers supporting evidence of the potential risks at the outset, finding evidence that the project had substantial technical risk during a later audit can be very challenging.
The proposed regulations are not effective until the IRS issues the final regulations on this subject. However, the IRS states that in years ending after issuance of the proposed regulations, the IRS will not challenge returns taking positions consistent with the proposed regulations. Unfortunately, the proposed regulations will not resolve internal use software issues in prior years as the IRS has explicitly determined that it would be inappropriate to make the final regulations retroactive.
In summary, the proposed regulations are a substantial advancement in recognizing that the research credit should reward the substantial improvements in software used by the taxpayer’s customers even if the customers do not directly pay for the software. However, the regulations cannot avoid the statutory mandate that there is a category of software that is subject to a higher standard of innovation. Significant portions of internal use software may in fact be highly innovative but proving that will continue to require vigilance and advance planning by tax departments.