Final internal use software regulations are mostly favorable
Final regulations addressing research tax credit issued
TAX ALERT |
On Oct. 3, 2016, Treasury and the IRS released the long-awaited internal use software regulations (T.D. 9786) for the section 41 credit for increasing research activities. The final regulations adopt, with few changes, the proposed regulations (REG-153656-03) issued Jan. 20, 2015. The final regulations could provide an increased research tax credit for businesses that invest in software development. See our prior article on the release of the proposed regulations.
The section 41 research tax credit’s application to computer software has been an area of much dispute and uncertainty. Section 41(d)(4) lists activities that do not constitute qualified research for purposes of determining the credit and section 41(d)(4)(E) further provides that research activities with respect to computer software that is developed by or for the benefit of the taxpayer primarily for its internal use is not considered qualified research, except to the extent provided in the regulations. However, this exclusion does not apply if the software research is for use in a qualifying research activity or in a production process for qualified research. The IRS has gone through several iterations of proposed and final regulations throughout the years, each meeting with varying degrees of criticism and conflicting interpretations.
Internal use software
The research credit exclusion for software as defined in the Internal Revenue Code is limited to internal use software, but the precise definition of internal use software was left up to the regulations to define. The final regulations define internal use software as software developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. General and administrative functions are limited to financial management, human resource management and support services. The preamble to the regulations refer to these functions as ‘back office’ activities that are necessary to support the day-to-day operations of carrying on a business.
The regulations also provide a definition for what is not internal use software. Although this definition generally restates the negative of the internal use software definition, it provides that software not developed primarily for internal use is software that is not developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business such as:
- Software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties
- Software developed to enable a taxpayer to interact with third-parties or to allow third-parties to initiate functions or review data on the taxpayer’s system.
This definition is similar to the one provided in the proposed regulations but expands the definition of non-internal use software by providing that the two carve outs are merely examples rather than the only way to qualify. Under this definition software development activities that are not developed primarily for internal use only have to meet the general definition of qualified research and not the high threshold of innovation test. Whether the activity is developed primarily for internal use depends on the intent of the taxpayer and the facts and circumstance at the beginning of the software development.
Dual function software
The new regulations keep the proposed rules for dual function software, that is, software that was developed both for internal use and for interaction with third-parties. The regulations contain a general presumption that dual function software is developed primarily for internal use. However, this presumption may be overcome by identifying the subset of software elements that exist only to enable third-parties to interact with the taxpayer, initiate functions or review data on the taxpayer’s system. This subset of elements may be treated as non-internal use software. To the extent an additional subset of elements of dual function computer software remains, a safe harbor allows the taxpayer to include 25 percent of the otherwise qualified research expenditures for the dual function subset in computing the research tax credit as long as the third-party functions is anticipated to account for at least 10 percent of the software’s use. The regulations also contain several examples that address dual function computer software.
High threshold of innovation
If research activities are found to be for the development of internal use software, the activities may still qualify for the credit if it satisfies the three-part high threshold of innovation test provided in the regulations. Under the first prong of the test, the software must be innovative, that is, it would result in a reduction in cost, improvement in speed, or other measurable improvement that is substantial and economically significant, if the development is or would have been successful.
Under the regulations, the second prong requires that the software development involves a significant economic risk which is demonstrated if the taxpayer commits substantial resources to the development and there is substantial uncertainty, because of technical risk, as to whether such resources will be recovered within a reasonable time. These finalized regulations remove a portion of the proposed regulations that referenced only capability and method uncertainty but excluded design uncertainty. The preamble to the final regulations notes that the focus of the significant economic risk test should be on the level of the uncertainty that exists, not the types of uncertainty.
The third prong of the high threshold of innovation test requires that the software being developed not be commercially available for use by the taxpayer, meaning that the software cannot be purchased, leased or licensed and used for the intended purpose without modifications that would satisfy the innovation and significant economic risk requirements.
Process of experimentation
The regulations contain nine examples of how to apply the process of experimentation test contained in the general qualified research requirements to both internal use and non-internal use software. These examples contain some of the same language from the examples provides in the proposed regulations while adding other examples to make them more comprehensive. Commonly encountered technology projects, such as developing load balancing software algorithms and developing interfaces between legacy software and an ERP system are addressed.
The regulations are effective for taxable years beginning on or after Oct. 4, 2016. In addition, the IRS will not challenge return positions consistent with the final or proposed regulations for taxable years that both ends on or after Jan. 20, 2015, and begins before Oct. 4, 2016. As such, taxpayers may rely on them immediately. The new regulations are consistent with the general concepts of the proposed regulations and, like the proposed regulations, are generally favorable in their guidance. Taxpayers that develop software may obtain a larger research tax credit due to the broader exclusions from the definition of internal use software. Taxpayers should continue to be cautious claiming research tax credits for internal use software, making sure that the additional high threshold of innovation test is met, and should consult their tax advisor.