5 October 2016
On October 3, 2016, the Internal Revenue Service (IRS) released final regulations establishing rules for claiming the research credit for internal use software. The regulations are substantially unchanged from the proposed regulations that were released on January 20, 2015, which provided a definition for “internal use software.” Given the importance of software in today's world, this increase in certainty is welcome. Still, advances in the critical role of software in today’s economy may leave the goal of obtaining the research credit out of reach for many important software projects.
In 1986, Congress provided that “except to the extent provided in regulations,” software developed “primarily for internal use by the taxpayer” was excluded from the definition of qualified research. I.R.C. §41(d)(4)(E). While research credit regulations were issued in 2001, these regulations, including the portions dealing with internal use software, were subsequently withdrawn. Regulations were re-proposed on December 26, 2001, but when the 2004 regulations finalized the 2001 proposed regulations, the regulations reserved on the rules for internal use software. Announcement 2004-9 stated that until further guidance was provided, taxpayers could continue to rely on the provisions relating to internal use software in the December 26, 2001 proposed regulations or in the January 2001 final regulations. Further guidance has now arrived.
The classification of software as internal use software results in the software needing to satisfy the “high threshold of innovation standard” in order to qualify for the research credit in addition to the normal four-part test that other types of research, including other types of software development, must meet. Therefore, the ability to obtain the research credit is greatly enhanced if software can escape the definition of internal use software.
How software is used has changed dramatically since 1986. In particular, software today often resides on a device, such as a server, that is separate from the device, such as a smartphone, used to access it. Prior to these new regulations, disputes often arose regarding whether the location of the software required it to satisfy the additional requirements for internal use software because the physical hardware on which the software resided was internal to the taxpayer. Agents focused on factors such as whether the software was sold on a disk or downloaded from the taxpayer's server to the customer's computer. This approach raised the specter of many types of online software being required to meet the additional requirements for internal use software.
Fortunately, the new regulations no longer focus on how the software is made available. Under the new regulations, the definition of internal use software examines whether the software is primarily intended to serve the general and administrative needs of the taxpayer. General and administrative functions are defined as (i) financial management, (ii) human resources and (iii) support services. While determining whether some software falls within this definition may be difficult, many cases will be clear.
Further, the regulations explicitly exclude from the definition of internal use software “[s]oftware developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer system.” In addition, the regulations provide an example concluding that online software supported by advertisements to edit photographs is not internal use software. Hence, the regulations establish that the developers of many of the apps that have become part of our everyday life can qualify for the research credit in the same ways as developers of tangible products.
Perhaps the biggest disappointment for taxpayers is that the IRS did not accept comments seeking a modification of dual function software. Dual function software is software that both is used by the taxpayer for general and administrative functions and allows its customers to initiate functions. Such software is presumed to be developed primarily for a taxpayer’s internal use unless one can identify a third party subset of the software that only enables a taxpayer to interact with third parties or to allow third parties to initiate functions or review data. If a third party subset cannot be identified, taxpayer may treat 25 percent of the project as non-internal use software provided that the taxpayer can establish that at least 10 percent of the software’s use is reasonably anticipated to relate to third party interaction. Despite the preamble's view that taxpayers have had over a year to develop appropriate recordkeeping systems to measure the degree of third party interaction, this requirement is likely to pose substantial difficulties for taxpayers.
The regulations place great stress on the taxpayer's intent at the time that the software development commences. Tax departments should consider whether they need to take a more proactive stance in dealing with their companies’ software developers to ensure that the necessary records will be available to confirm the appropriate classification. This is particularly important when the software has the potential for being sold to third parties as well as being used internally by the taxpayer.
The classification of software for general and administrative purposes as internal use is probably consistent with the original congressional intent in 1986. However, the policy seems anachronistic in today’s knowledge economy. Developing a design for an improved time clock can obtain the credit by only satisfying the basic four-factor test while software to improve utilization of the same workers must satisfy the high threshold of innovation standard. Unfortunately, placing all software development on a level playing field with other types of innovation will probably require legislative change.
The regulations also clarify the high threshold of innovation standard that internal use software must meet. The software must (i) be innovative, (ii) involve significant economic risk and (iii) not be commercially available without modifications that would satisfy requirements (i) and (ii). The significant economic risk requirement is likely to be particularly difficult to implement. The regulations require that the taxpayer commit substantial resources to the development and that substantial uncertainty exist, because of technical risk, that such resources would be recovered within a reasonable period. Establishing these requirements is likely to be challenging.
The parts of the regulation addressing internal use software are not effective until taxable years beginning on or after the date of publication in the Federal Register although the IRS will not challenge positions consistent with the regulations in taxable years that end on for after January 20, 2015—the date that the proposed regulations were released. Regrettably, this leaves the potential for continuing disputes about the classification of the software as internal use software for earlier years. The preamble justifies this position on the grounds that retrospective application would be inconsistent with the statute’s objective of being an incentive to conduct the research. For many taxpayers, this analysis is likely to be unsatisfying, as even in the absence of clarifying regulations, many taxpayers believed that software used by their customers was not internal use software even if it happened to reside on the taxpayer’s hardware. For such taxpayers, a retroactive application of the regulations would merely confirm their expectations at the time they undertook the research that the research credit would be available without the need to argue that point with the examining agent or appeals.
One’s attitude to these regulations may depend on whether you see the glass as half full or half empty. The regulations provide much-needed certainty. However, the regulations still place numerous hurdles in the way of taxpayers responsible for some of the most dramatic innovations in today’s economy. Progress has been made, but with software technology advancing, the regulations may still leave the goal posts out of reach for many.