The Credit for Increasing Research Activities, better known as the "R&D Credit," is one of the most valuable tax incentives for technology companies, with its original legislation dating back to the 1980s. IRC section 41 defines eligible activity as the development of a new or improved business component, the definition of which includes computer software.  While many activities related to software development do qualify for the tax credit, not all software is treated equally for purposes of the tax credit. 

Defining Internal Use Software and the HTI Test

The tax code specifically excludes the development of "internal use software" (IUS) as a qualified activity unless the software satisfies a three-part high threshold of innovation (HTI) test. This HTI test requires the software to be innovative, involve significant economic risk, and not be commercially available for use without modification. The definition of IUS further confounds the issue. In fact, the IRS has defined four types of software and in 2016 issued TD 9786, replete with examples of how different software might fit these categories:

• IUS is software that supports general and administrative functions of a business. 
• Dual function software (DFS) is similar to IUS but allows third parties to interact with the business's systems. Scenarios exist where components of DFS may not be subject to the HTI test.  
• Non-IUS is developed to be sold, leased, licensed, or marketed to third parties or used in a non-administrative function for the taxpayer. 
• Software excepted from IUS is used in otherwise qualified research activities such as pharmaceutical development, production processes, or a package of software and hardware as a single product.

Software Development for Others: Credit Rules

Having evaluated eligibility requirements for the four categories of software development above, one question remains unanswered: "What if a business builds software for someone else?" Many software developers assume they are ineligible for the credit because they receive financial compensation for that work, when in fact, two tests must be applied to determine whether the client or contractor is eligible for the credit. 

• The first test evaluates whether the business incurs economic risk associated with a given project. 
• The second test evaluates the exclusion of intellectual property rights (i.e. would the business owe royalties or other fees to utilize the knowledge gained from the development effort?).

Evaluating these tests requires a review of invoices, service agreements, purchase orders, and other relevant documents as well as evaluating tax law, IRS guidance, and case law. Intent at the outset of the technical effort is often a primary driver when evaluating contractor or software type tests mentioned above. For example, incurring unbillable time on a "time and materials" project would not automatically reclassify that project as a fixed price engagement.  Similarly, software development that was undertaken for IUS and ultimately became externally used would still be subject to HTI tests up to the point the development focus shifted to non-IUS, according to TD 9786. 

What does CohnReznick think?

Technology companies should work with a team of experienced professionals to evaluate the nuances of qualified and non-qualified business activities for eligibility for the R&D Credit. New for 2025, enhanced compliance will require businesses to identify the type of software developed at the time a tax return is filed.