October 19, 2016
The IRS recently finalized regulations related to claiming research and development (R&D) tax credits for certain types of software development. These regulations allow R&D tax credits on software projects that previously may have been excluded under the internal-use software (IUS) rules.
The new regulations are especially important for companies that invest heavily in internal software development projects that allow their customers to interact with their internal systems, such as banking, insurance or retail companies. Businesses that may not have been able to take advantage of the R&D credit in the past should determine if the new rules allow an opportunity to now claim valuable R&D credits.
Proposed regulations related to IUS were issued in January of 2015 but left several questions about application of the rules unanswered. The IRS then solicited comments from the tax community and fielded suggestions for clarity or additional language. As a result, the final regulations retain many of the provisions of the proposed regulations, but offer a few clarifications and language changes.
Internal Revenue Code (IRC) Section 41 provides a credit for research and development that meets certain criteria under a four-part test. The IRC specifically excludes any software developed “primarily for internal use” from credit eligibility, but provides certain exceptions where IUS can still qualify for the credit.
In 2001, the IRS issued final regulations that defined IUS as software not developed to be sold, leased, licensed or otherwise marketed to third parties, with an exception for software that was “innovative.” Shortly after those regulations were released, the IRS announced they were reconsidering the rules, and new proposed regulations were released later that year with a more stringent “innovative” test for IUS that defined innovation as a unique or novel concept that differed in a significant and inventive way from other software systems and methods.
In 2003, when the final regulations were issued for the R&D tax credit, IUS rules were not included, leading to confusion and litigation about which guidance could be used to qualify IUS for the R&D credit. Taxpayers engaged in IUS development were eventually provided additional clarity when the proposed regulations were released in 2015.
IUS Rules in Proposed Regulations
The proposed regulations were viewed as taxpayer-favorable, clarifying many ambiguous areas as technological advancements that had occurred through the years. To accommodate advancements in software development and how it is used, the proposed regulations addressed the definition of IUS, what constitutes third-party use, and the qualification of software that serves a dual purpose.
Definition of IUS
The IRS provided a narrowed definition of IUS to 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.” The new definition includes activities that involve the financial management of the taxpayer, supportive bookkeeping, managing payroll or employees, and overall support of the day-to-day operations of the taxpayer. By narrowing the definition of IUS, the proposed rules allowed more software to qualify for the credit by being more specific about which IUS would not qualify for the R&D tax credit.
Third-Party Use of Software
Developed software that is not sold but rather allows customers or other third parties to interact with the taxpayer’s software may now qualify for the credit. Following the preamble to the regulations, this includes software developed for third parties to execute banking transactions, track the progress of a delivery, search the taxpayer’s inventory, store and manage digital files, purchase tickets for travel and entertainment, and receive services over the Internet.
The IRS addressed the problem of how to treat software that is used both for internal use and interaction with third parties. If a taxpayer can identify a subset of software elements that exist only to allow the taxpayer to interact with third parties, or to allow third parties to initiate functions and review data, the elements may be treated as non-IUS, thus qualifying for the R&D tax credit.
If the taxpayer cannot identify such a subset, the regulation offers a safe harbor provision that, to the extent that at least 10 percent of the dual function software is for third-party use, the taxpayer may include 25 percent of the otherwise qualified costs for the dual-use function. The regulation requires the taxpayer to use an “objective, reasonable method” when making this estimation.
High Threshold of Innovation
IUS may still qualify for the R&D credit if it meets a higher standard of innovation than other types of qualified expenses. The threshold of innovation consists of three tests involving 1) innovation, 2) significant economic risk, and 3) commercial availability. The development of internal software must have the intent to make an improvement that is substantial and economically significant in such a way that there is no software commercially available for the intended purpose without modifications.
The taxpayer also must commit substantial resources to the development that would be recovered within a reasonable time period if substantial uncertainty and technical risk are overcome. The proposed rules clarify that the type of technical uncertainty required to meet the higher standard of significant risk must relate to either capability or methodology issues (not appropriateness of design uncertainty).
IUS Rules in Final Regulations
The IRS retained the safe harbor rules for dual-function software, but clarified the method for determining the estimation of what percentage is for third-party use, given the many different industries that develop and use software. Because the IRS agreed that no one specific method applies to all taxpayers, the language now reads that “any objective, reasonable method within the taxpayer’s industry may be used for purposes of the safe harbor.”
One significant change was made to the high threshold of innovation test. The proposed regulations emphasize that uncertainty must be related to capability or methodology issues, which differs from the four-part test in which appropriateness of design can also be identified as an uncertainty. The IRS recognized that it is difficult and burdensome on the taxpayer to delineate the types of technical uncertainties. Because appropriateness of design can often be linked with uncertainty regarding capability or method, any reference to “capability” or “methodology” in this section of the regulations has been removed.
The preamble to the regulations outlines the comments that were addressed and the IRS’s reasoning for either validating or dismissing those comments.
The effective dates are somewhat complicated, but for the changes in the final regulations, those are prospective and apply to taxable years beginning on or after Oct. 4, 2016.
In addition, the IRS will not challenge positions consistent with the previously proposed regulations for any taxable year that both ends on or after Jan. 20, 2015, and begins before Oct. 4, 2016. This will allow some opportunity for planning and potential amendment of prior filed returns for claiming the R&D tax credit.
With the IUS regulations now in final form, businesses undertaking software development activities have more certainty on how they can qualify for R&D tax credit beneifts.