Final R&D Internal-Use Software Regulations Provide More Certainty

Editor: Greg A. Fairbanks, J.D., LL.M.

The IRS published final internal-use software regulations under Sec. 41 on Oct. 4 (T.D. 9786). The final rules come nearly two years after proposed regulations were issued in January 2015 (REG-153656-03). They should finally settle much of the uncertainty for determining when software is developed for internal use and therefore subject to the high-threshold-of-innovation test for eligibility for the research credit.

Although the final regulations did not incorporate many taxpayer suggestions, they do retain much of the taxpayer-favorable rules in the proposed regulations. Taxpayers will still benefit from a narrower definition of internal-use software and a safe harbor for carving out eligible portions of dual-use software.

Background

Generally, Sec. 41 bars a research credit for software developed primarily for internal use. The IRS originally issued final regulations in 2001 that defined internal-use software as any software that is not developed to be sold, leased, licensed, or otherwise marketed to third parties, with an exception for “innovative” software. But the IRS immediately reconsidered the 2001 regulations and later that year proposed a new version with a more stringent “innovative” test. When the IRS finalized these regulations in 2003, the IRS omitted all the rules on internal-use software, confusing taxpayers and leading to controversy. The latest final regulations finally define software that is developed “primarily for internal use” and clarify when internal-use software can still qualify for the credit.

Defining Internal Use

The final regulations retain the narrower taxpayer-favorable definition of internal-use software from the 2015 proposed regulations. Software is developed primarily for internal use if it is “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 regulations further limit the term “general and administrative functions” to the following:

• Financial management functions, which involve the financial management of the taxpayer and the supporting recordkeeping;
• Human resources management functions, which allow the taxpayer to manage its workforce; and
• Support services functions, which support the taxpayer’s day-to-day operations.

Software Used by Third Parties

The IRS did slightly broaden the definition of software that is not considered developed primarily for internal use. The 2015 proposed regulations provided that software is not developed primarily for internal use only if it is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or if it is 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.

In the final version, this standard is used merely as an example of software that is not developed primarily for internal use, and the actual definition of software not developed primarily for internal use is any software that does not meet the basic internal-use definition (i.e., 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 final regulations retain the proposed rule that the determination of whether software is developed primarily for internal use is made at the beginning of the project. The IRS did not change this, despite several commenters’ pointing out that a taxpayer may initiate a software development project with one purpose in mind and later discover that other purposes should be considered and pursued, or abandon its original intentions entirely. However, the final regulations continue to provide a special rule for improvements to software that can be separately identified. This special rule would apply, for example, when a taxpayer completes a software development and then decides to improve that software by undertaking further development of the same software.

Dual-Function Software

The final regulations provide that software developed to serve both internal and third-party functions is presumed to be developed for internal use. However, the final regulations also allow taxpayers with dual-use software to segregate a subset of elements that enable the taxpayer to interact with third parties or to allow third parties to initiate functions or review data. The segregated subset is not considered internal-use software.

For software subsets for which the third-party portion and internal-use portion of the software are interwoven such that the third-party portion cannot be segregated, a safe-harbor provision allows for 25% of the dual-function software to not be internal-use software if at least 10% of the dual-function software is for third-party use. The final regulations clarify that this safe harbor applies only after the determination of whether the software is presumed developed for internal use.

High Threshold of Innovation

The final regulations provide that internal-use software can still qualify for the research credit if it meets a higher standard of innovation than is required for other business components. The three-part test for meeting this higher threshold for innovation generally follows the proposed regulations, with a minor change in the significant-economic-risk test:

• Innovative: The intent for developing the software must be to reduce cost, improve speed, or make another improvement that is substantial and economically significant. The “unique or novel” standard does not apply.
• Significant economic risk: The taxpayer must commit substantial resources to development that would be recovered within a reasonable period if substantial uncertainty and technical risk are overcome. The final rules do not include proposed language that requires the uncertainty to be specifically related to capability or methodology issues.
• Not commercially available: Software must not be commercially available for its intended purpose without modifications.

The change in the significant-economic-risk test is interesting, as the Treasury Department and the IRS acknowledged it is difficult to delineate the types of technical uncertainties. They instruct that the focus of the significant-economic-risk test should be on the level of uncertainty that exists and not the types of uncertainty. However, the preamble then indicates that Treasury and the IRS believe that internal-use software research activities that involve only uncertainty related to appropriate design, and not capability or methodology, would rarely qualify as having substantial uncertainty for purposes of the high-threshold-of-innovation test.

Duty of Consistency

Some commenters noted the administrative difficulties of applying the duty-of-consistency rule under Sec. 41(c)(6)(A) and requested guidance on how to comply. The final regulations do not modify this existing law. Therefore, a taxpayer’s base amount must be determined on a basis consistent with the definition of qualified research expenses and gross receipts for the credit year, which in many cases may lead to a base period adjustment when a taxpayer applies the final regulations to software.

Next Steps

The final regulations are effective for tax years beginning on or after Oct. 4, 2016, but taxpayers can generally rely on either the 2015 proposed regulations or the final regulations for tax years that end after Jan. 20, 2015, and begin before Oct. 4, 2016. With the passage of the Protecting Americans From Tax Hikes (PATH) Act of 2015, P.L. 114-113, the research credit is now permanent. With the increased certainty these regulations and a permanent statute bring, taxpayers should consider putting in place better, more permanent processes for identifying and documenting the research credit. Taxpayers should begin by identifying opportunities to use these new favorable rules.

The final regulations are particularly significant for taxpayers that incur significant software development expenses for software that is not sold, leased, or licensed to third parties. Taxpayers that operate in a “software as a service” model or other taxpayers that interact with customers through software functions also may have significant opportunities.

Going forward, taxpayers developing software that wish to claim the research credit should document the intent of the software at the beginning of development. The new definition of what is internal-use software and what is not, at the very least, clarifies and brings more certainty when claiming the credit. In many instances, it may allow taxpayers to broaden the types of software activities allowed to be included toward the credit. In these instances, taxpayers should ensure they are properly documenting their activities and making appropriate adjustments when computing the research credit amount.

EditorNotes

Greg Fairbanks is a tax managing director with Grant Thornton LLP in Washington.

For additional information about these items, contact Mr. Fairbanks at 202-521-1503 or greg.fairbanks@us.gt.com.

Unless otherwise noted, contributors are members of or associated with Grant Thornton LLP.