|

Software Credit for Increasing Research Activities

By AASHNA SHAH AND JAMES W. RINIER, CPA, EA
March 1, 2017
0 comments
Program code and computer keyboard

New Treasury regulations concerning the application of the software credit for increasing research activities went into effect October 4, 2016.

 

The credit for increasing research activities under Internal Revenue Code (IRC) §41 was enacted in 1981 to help support U.S. businesses incur greater research expenditures and thus stimulate a greater level of innovation. Software technology has evolved significantly since then, leading the Treasury Department and IRS to issue proposed regulations that provide a definition of internal use software. Most businesses today use “cloud” solutions, which make the computer software explanation for claiming the credit more significant.

 

The Final Regulations (TD 9786) published in the Federal Register, 81 Fed. Reg. 68299 (October 4, 2016) provide a summary of examples and comments made in response to the proposed regulations, adding more details and clarification. The internal use software and the dual-function software provisions appear to be the most useful to review.

 

INTERNAL USE SOFTWARE

 

Under IRC §41(d)(4)(E), no research credit is allowed for internal use software development, except as provided by regulations. Under the proposed regulations, software was considered to be for internal use if it’s developed by (or for the benefit of) the taxpayer primarily for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business.

 

The final regulations include further details that clarify when software isn’t developed for internal use, such as: (1) software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties or (2) software 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.

 

For example, a restaurant named Clara develops software for a website that provides information to potential customers, such as the menu, price, location, phone number, and hours of operation. At the beginning of the development, Clara doesn’t intend to develop the website software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable Clara to interact with third parties or to allow third parties to initiate functions or review data on Clara’s system. Clara intends to use the software for marketing by allowing third parties to review general information on Clara’s website. Would this be considered as developed for internal use? With the final regulations, there’s a definite answer: Yes. The software is developed for use in a general and administrative function because the software was developed to be used by Clara for marketing, which is a support services function under Regulation §1.41-4(c)(6)(iii)(B)(3). Thus, no credit would be allowed in this example.

 

Consider another hypothetical situation: Tomas is a provider of cloud-based software. Tomas develops enterprise application software (including customer relationship management, sales automation, and accounting software) to be accessed online and used by Tomas’s customers. At the beginning of development, Tomas intended to develop the software to collect fees for commercial sale, lease, license, or to be otherwise marketed to third parties. Considering the facts of this situation, the software isn’t developed primarily for internal use because it isn’t developed for use in a general and administrative function. Tomas developed the software to be commercially sold, leased, licensed, or otherwise marketed to third parties under Regulation §1.41-4(c)(6)(iv)(A). Per the Federal Register Preamble, the Treasury Department and IRS believe that “software that is developed to be commercially sold, leased, licensed or otherwise marketed to third parties” is sufficiently broad to encompass hosted software and other software where there is no transfer of a copy of the software. Thus, the credit would be allowed in this example.

 

DUAL-FUNCTION SOFTWARE

 

Software that’s developed by the taxpayer for both internal use and to enable third-party interaction is considered dual-function software. If the taxpayer can identify a subset of elements that exists only to enable third parties to interact with the taxpayer, initiate functions, or review data on the taxpayer’s system, then the software isn’t considered internal use for that subset of elements. So long as the third-party functions are anticipated to account for at least 10% of the software’s use, then a safe harbor for computing the research tax credit allows the taxpayer to include 25% of the otherwise qualified research expenditures for the dual-function subset.

 

An example helps demonstrate this concept: SeeC develops software for use in general and administrative functions that facilitate or support the conduct of its trade or business and to allow third parties to initiate functions. SeeC is able to identify a third-party subset. In total, SeeC incurs $50,000 of research expenditures for the software, 50% of which is allocable to the third-party subset. Based on these facts, the conclusion is that the software developed by SeeC is dual-function software. Because SeeC is able to identify a third-party subset, the third-party subset isn’t presumed to be internal use software under Regulation §1.41-4(c)(6)(iv)(B). Thus, the credit would be allowed in this example.

 

Now consider the flip side of the dual-function software with the application of the safe harbor under Regulation §1.41-4(c)(6)(vi)(C). Assume that SeeC is unable to identify a third-party subset. SeeC uses an objective, reasonable method at the beginning of the software development to determine that use by third parties to initiate functions is reasonably anticipated to constitute 15% of the software’s use. Although SeeC is unable to identify a third-party subset, it reasonably anticipates that the software’s use by third parties will be at least 10% of the software’s use. Hence, it is considered dual-function software, and the credit would be allowed in this example using the safe harbor.

 

The final regulations as explained in the Federal Register (81 Fed. Reg. 68299 to 68312) clarify the concerns over the last few years for taxpayers trying to determine if they are eligible for the software credit. Most businesses and companies should have substantial software use, and, therefore, the final regulations will be beneficial. Taxpayers certainly should take advantage of the credit applicable to their use of software.

 

© 2017 A.P. Curatola

Aashna Shah is the Vertex Fellow at Drexel University’s LeBow College of Business in Philadelphia, Pa. You can reach her at ars442@drexel.edu.  
  James W. Rinier, CPA, EA, is an assistant clinical professor of accounting at Drexel University. He can be reached at jwr29@drexel.edu.
0 No Comments

You may also like