Alert

Expanded R&D Credit Opportunities for Software Developers and Investors

November 14, 2016

Businesses that develop or invest in software for their own use may be newly eligible to claim research and development (“R&D”) tax credits or increase the amount of their R&D tax credits, thanks to the Treasury’s publication of the final regulations. The regulations went into effect on October 4, 2016.

Businesses that develop or invest in software to sell to customers or to use in the development of their own products have been able to claim these R&D tax credits for a while now. They can claim the credit for costs they incur in the development process. However, businesses that develop software for their own internal use have been subject to strict limitations on their ability to benefit from the credit. These businesses may now find it easier to claim R&D tax credits or increase the amount of their credits.

The new final regulations specifically address R&D tax credits for internal use software (“IUS”) – that is, software developed by a business primarily for their own use within their business and/or with their own clients. These final IUS regulations largely adopt the proposed regulations released on January 20, 2015. They:

  • Clarify and narrow the definition of IUS
  • Clarify and expand the definition of software not developed primarily for internal use
  • Retain dual function software rules and safe harbor
  • Allow the rules to be applied retroactively to periods beginning in 2015 or 2016

Background – What Qualifies for the R&D Credit?

The R&D credit has been getting a lot of attention this year, especially since it was made permanent through the Protecting Americans from Tax Hikes Act of 2015 (“PATH Act”). The R&D credit in § 41 of the Internal Revenue Code (“IRC” or “the Code”) allows a taxpayer a nonrefundable income tax credit for certain qualified research expenses (“QREs”) paid or incurred in carrying on qualified research activities (“QRAs”) in an active trade or business. In some cases, businesses with minimal income tax liability may apply the credit against their payroll tax liabilities.

QREs include both in-house research expenses and 65% of certain contract research expenses. In-house research expenses include wages paid to employees for qualified services and the costs of supplies used in the conduct of qualified research. Qualified services consist of performing QRAs or the direct supervision and/or support of persons performing the QRAs.

Qualified research means research that satisfies the four-part test laid out in IRC § 41(d) and which also isn’t specifically excluded from the definition of qualified research. The four-part test consists of:

  • The IRC § 174 test: Research expenses must be eligible for treatment as research or experimental expenses under IRC § 174
  • The Technological-in-Nature test: Research must be undertaken for the purpose of discovering information that is technological in nature
  • The Business Component test: Application of the discovered information must be intended to be useful in the development of a new or improved business component of the taxpayer
  • The Process of Experimentation test: A substantial part of all the research activities must constitute elements of a process of experimentation

However, the statute specifically excludes certain activities from the definition of qualified research. One of those exclusions is research related to the development of IUS. In order for IUS development to be treated as a QRA, a separate three-part test needs to be satisfied. This test is referred to as the high threshold of innovation test (“HTIT”). To satisfy this test, the IUS must:

  • Be innovative, meaning the software results in a reduction in cost, an improvement in speed, or other measurable improvement that is substantial and economically significant, if the development is or would have been successful
  • Involve significant economic risk to the taxpayer, where the taxpayer commits substantial resources to the software development and technical risk causes substantial uncertainty that the investment and resources would be recovered within a reasonable period
  • Not be commercially available for use by the taxpayer, meaning there’s no other software that can be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy the first two parts of this test

The final IUS regulations retain this three-part test but specify that it’s only applicable to IUS and not to software that is developed primarily for external use. They’ve also lowered some of the standards from the proposed regulations concerning uncertain methodology (meaning how uncertain the development process is), software capabilities, and whether or not your project is making a “revolutionary discovery.” Now that the Treasury has relaxed some of these standards, more businesses should be able to claim R&D credits for their software development.

A Brief History of Software Development and the R&D Credit

The history of the application of the R&D credit to computer software and the IUS exclusion has been long, tedious, confusing, and complex, to say the least. For starters, Congress declined to define IUS when drafting IRC § 41 as part of the Tax Reform Act of 1986. Next, Treasury issued five iterations of regulations (proposed and final) governing IUS from 1997 to 2015. Some of those iterations also declined to define IUS. In addition, these various iterations of the regulations often failed to reflect the accelerated advancement and use of technology and software in the business world. Plus, they were routinely criticized and subject to conflicting interpretations. Thus, the availability of the R&D credit for software development has long been an area of uncertainty and dispute between taxpayers and the IRS.

The 2016 final IUS regulations provide some clarity and expanded opportunities for taxpayers. They also provide clarification regarding the applicability of the credit to software that is not treated as IUS. However, areas of concern still exist with the latest iteration and some conflicting interpretations are likely.

The 2016 Final Internal Use Software Regulations

The IRS released the 2016 final IUS regulations (T.D. 9786) on October 3, 2016, and they went into effect the very next day for tax years beginning on or after October 4, 2016. The 2016 final IUS regulations adopt the proposed IUS regulations (REG-153656-03) released on January 20, 2015, with only a handful of changes. Because the regulations clarify the definition of IUS and retain the concept of dual function software, many businesses that invest in the development of software may be able to utilize the R&D credit for the first time or to increase their R&D credit going forward. The regulations also provide rules related to software that is not IUS.

The Definition of Internal Use Software

The 2016 final regulations divide software into two broad categories for purposes of the R&D credit:

  • Internal use software or software developed primarily for internal use; and
  • Software not developed primarily for internal use

The final regulations define IUS as software developed by a taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business – so-called “back office” functions. General and administrative functions are defined in the final regulations as:

  • Financial management functions: Tasks that involve the financial management of the taxpayer and any supporting recordkeeping
  • Human resource management functions: Functions that manage the taxpayer’s workforce
  • Support services functions: Tasks and processes that support the day-to-day operations of the taxpayer, such as data processing or facilities services

The Treasury and the IRS declined to change this definition in the final regulations despite multiple comments made about whether this definition, which was used in the proposed regulations, is too broad. Commenters were concerned that inventory management, marketing, legal services, and government compliance services can provide significant benefits to third parties and that software could be developed to enable third parties to initiate or otherwise utilize such services on a taxpayer’s system. In other words, commenters felt many of these services and systems could be considered modern “front office” functions and not IUS. Rather than alter the definition, Treasury and the IRS felt that the dual function software rules could be used to analyze such a situation for R&D credit purposes. That’s why the definition did not change in the final regulations.

R&D Credit Opportunities for Software Not Developed Primarily for Internal Use

The 2016 final regulations define software that hasn’t been developed primarily for internal use by referencing the IUS definition: software notdeveloped by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. The regulations state that software can’t be considered IUS for R&D credit purposes if that software has been developed to:

  • Be commercially sold, leased, licensed, or otherwise marketed to third parties
  • Enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system

Because they do not limit the definition of non-IUS to the above-mentioned examples, these final regulations expand on the 2015 proposed regulations. Non-internal software development research activities only have to satisfy the traditional four-part test of IRC § 41(d) and not the HTIT.

The determination of whether software is or is not developed primarily for internal use occurs at the beginning of the software development effort. So, for example, if a taxpayer initially starts to develop software for internal use but later makes improvements to make the software available for commercial or third-party use, only the improvements are treated as software not developed for internal use.

On one hand, this definition of what qualifies as IUS and what doesn’t limits the R&D credit of businesses that initiate a development project with one purpose in mind only to discover along the way that there may be other commercial applications and possibilities. The IRS was not convinced by any of the comments on the proposed regulations concerning alternative methods or timeframes for determining when and whether software is developed primarily for internal use.

On the other hand, because the definition of IUS is ultimately narrower than before, more types of software development will only need to satisfy the traditional four-part R&D test. This change potentially expands R&D credit opportunities for businesses.

Dual Function Software and Substantiation Hurdles

Dual function software is software that is developed by or for the benefit of the taxpayer for use in general and administrative functions that facilitate or support the taxpayer’s business. It can also be software that enables the business to interact with third parties or to allow third parties to initiate functions or review data. In other words, dual function software has components or subsets of both IUS software and non-IUS software.

The 2016 final regulations retain the general presumption of the 2015 proposed regulations. That is, dual function software is presumed to be developed primarily for a taxpayer’s internal use. However, this presumption can be overcome if the taxpayer can identify a subset of software elements that exist only to enable third parties to interact with the taxpayer or to allow third parties to initiate functions or review data on the taxpayer’s system (a “third-party subset”).

The substantiation hurdles imposed when attempting to navigate this rule and delineate a third-party subset could be significant. For example, to avoid the dual function rule and the high threshold of innovation test, you would need to substantiate wages and other QREs allocable to the efforts to develop only the third-party features of the software (rather than costs allocable to the software project in its entirety). That is no small hurdle, even for taxpayers with project-based accounting. For other taxpayers, like those who use cost center accounting or where development is too integrated with operations, it may be extremely difficult to identify and substantiate the third-party subsets of the dual function software, let alone the specific allocation of any expenses incurred in creating those subsets.

However, all is not lost. If third-party subsets cannot be readily identified or additional costs remain after any subsets of dual function software elements have been substantiated, the final regulations provide a safe harbor provision. This safe harbor automatically assumes 25% of total project development costs aren’t allocable to IUS and are therefore not subject to the additional tests in order to be eligible for the credit.

The safe harbor only applies if two criteria are met. First, your research activities related to the dual function software or subset must constitute qualified research. Second, the use of the dual function software or subset by third parties or by the taxpayer to interact with third parties must reasonably be anticipated to constitute at least 10% of the dual function software or subset’s use.

The dual function rule and applicable safe harbor will likely end up being a double-edged sword. In situations where the software development efforts anticipate significant third-party interactions, the dual function rule will reduce the R&D credit of taxpayers who cannot substantiate discrete third-party subsets by limiting the non-IUS costs to 25% of total project costs through the safe harbor. (That’s assuming the HTIT could not be satisfied.)

In other situations where the software development efforts relate mostly to back office functions, say in excess of 75% but not more than 90%, the safe harbor would cut into the government’s take by deeming 25% of total project costs to be non-IUS. The safe harbor is intended to provide a benefit, not a hindrance, to taxpayers. That being the case, taxpayers can choose not to rely on the safe harbor and instead attempt to satisfy HTIT.

Effective Date and Implications

Despite the requests of many commenters to make the 2016 final regulations retroactive to 1986 (since the regulations are interpreting a statute from 1986), the new rules are generally effective for tax years beginning on or after October 4, 2016, the date when the final regulations were published in the Federal Register. The Treasury generally took a forward-looking approach (with a few exceptions) for fear of giving an unfair advantage to taxpayers with open statutes of limitations on prior years and because of administrative burden concerns.

However, the IRS will not challenge return positions that are consistent with either the 2016 final regulations or the 2015 proposed regulations, as long as the credits are taken on a return for a tax year that ends on or after January 20, 2015, and the year begins by October 3, 2016. This means that almost every taxpayer has the opportunity to amend their 2015 returns to apply these new more taxpayer-friendly IUS rules. The 2016 final regulation can also be used to determine R&D credits on any 2016 tax return, even if the year started before the regulations were issued.

Alternatively, taxpayers that were using the 2015 proposed regulations for determining their R&D credit are not required to implement the 2016 final regulations for any tax year beginning prior to October 4, 2016. In other words, calendar-year taxpayers can wait until 2017 to apply the 2016 final regulations if they so choose.

The Takeaways

The narrowing of the definition of IUS by the 2016 final regulations opens the door for more taxpayers who develop software, or who invest in the development of software, to use the R&D credit. The dual function rule and accompanying safe harbor will create substantiation hurdles for some taxpayers. The rule may change how software development projects are accounted for and tracked. The dual function rule and safe harbor will either favor the IRS or the taxpayer, depending on the nature of the software development project.

If you develop or invest in the development of software and already take advantage of the R&D credit, the 2016 final regulations provide expanded opportunities for larger credits, beginning with your 2015 tax year.

If you do not already take advantage of the R&D credit, these regulations provide a good motivation to re-examine the benefits you may qualify for.

Do you think these new regulations change things for your business – and you may qualify for an R&D credit? Could your business qualify for the R&D credit because of your development, testing and improvement of products and processes? Do you claim a federal R&D credit but wonder if there are state tax benefits available, too?

Feel free to contact Cherry Bekaert’s Credits/Accounting Methods team. There’s no obligation, and they’re a great starting point for your R&D questions.

Or, reach out to your local Cherry Bekaert service team to set up a meeting. We’ll be happy to pair you with a professional who can help you navigate – and maximize – your R&D options.