KPMG report: Credit for increasing research activities involving computer software

Credit for increasing research activities

This report concerns the recent proposed regulations concerning the credit for increasing research activities involving computer software.

Related content


Proposed regulations [PDF 242 KB] concerning the application of the credit for increasing research activities pursuant to section 41 for computer software that is developed by or for the taxpayer, for the taxpayer’s internal use—IUS or “internal-use software”—were published in theFederal Register on January 20, 2015.

The preamble to the new regulations signals a fresh look at the rules for IUS and states:


The role that computer software plays in business activities is very different today than it was when the exclusion for internal use software was enacted in 1986. Today, computer software is used in all aspects of business activity, especially in providing goods and services to third parties, and such software has played a vital role in increasing the productivity of the U.S. economy and in making the U.S. more competitive globally.


The proposed regulations would provide a comprehensive set of rules dealing with the requirements for a research credit for internal-use software development as well as examples applying the general process of experimentation test to all software development.

The proposed regulations have many facets, some of which are less stringent—and some more stringent—than prior versions of the proposed regulations. These regulations have been long-awaited and are generally taxpayer friendly. An appendix [PDF 138 KB] to this report provides a high-level timeline of the evolution of the new proposed regulations. What follows below is a further discussion of the content of the new regulations.

Definition of internal-use software

Under the proposed regulations, software is developed by (or for the benefit of) the taxpayer primarily for internal use if the software 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.

If developed for the internal use of a member of the taxpayer’s controlled group, it will be considered internal-use software. This is relevant based on the rules that must be applied to determine qualification for research credit purposes.

This standard eliminates the distinction between software developed to deliver computer and noncomputer services. The definition is intended to target software used in the back-office functions of the taxpayer—financial management functions, human resource functions, and support services functions. Additionally, the new IUS regulations target software designed by the taxpayer to enable third parties to provide administrative functions to the taxpayer.

Software that is developed to be commercially sold, leased, licensed or otherwise marketed (“commercial software”) is characterized as software not developed primarily for internal use. The proposed regulations attempt to alleviate confusion prevalent in prior interpretations that software must have a third-party commercial focus to avoid being characterized as internal-use software.

Certain software that benefits third parties by enabling them to interact, with the taxpayer, or initiate functions or review data is also excluded from the definition of internal-use software. Examples include software developed for third parties to execute banking transactions, track the progress of a delivery of goods, search a taxpayer’s inventory for goods, store and retrieve a third party’s digital files, purchase tickets for transportation or entertainment, or receive services over the internet. For purposes of these rules, third parties do not include any persons that use the software to support a taxpayer’s general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. These exclusions, applicable to a wide variety of industries, may significantly reduce disagreements with the IRS about what is considered internal use software.

Improvements to software, to make internal-use software commercially available to others, or to make a taxpayer’s commercial software useful for the taxpayer’s general and administrative functions, need to be analyzed separately from the existing software to determine proper treatment under these regulations. More specifically:

  • Enhancements to commercial software that are specifically designed for the taxpayer’s administrative use will be considered internal-use software.
  • Enhancements to internal-use software that are intended to provide non-administrative functionality to a third party will be considered non-internal- use software.

Internal testing of commercial software will not make it internal-use software

The proposed regulations contain special rules for a category it refers to as “dual function software” which is defined as software that is developed for internal general and administrative functions of the taxpayer as well as to both enable third parties to interact and initiative functions.

Dual function software is presumed to be for internal use; there is no de minimis exception. However, if the taxpayer can identify subsets of elements that only facilitate third-party interaction or enable third parties to initiate functions or review data, those subsets will not be presumed to be for internal use and will qualify for the research credit without application of the three-part high threshold of innovation test.

A safe harbor is provided that would allow 25% of the research expenses of a remaining dual-use subset of the dual use software to qualify for the credit whether or not the subset satisfies the additional three-part threshold of innovation test. To be eligible for the safe harbor, it must have been reasonably anticipated at the time of the software development that the third-party functions will constitute at least 10% of the total use of the subset’s functions. The proposed regulations state that an objective, reasonable method must be used to estimate the dual function subset’s use by third parties, at the beginning of the computer software development. How this safe harbor might come into play if a taxpayer had originally treated all of the dual function software as four-part test software is an area that may need to be further explored as part of the development of the regulations and or IRS exam guidance.

The preamble to the regulations specifically requests comments about whether the safe harbor standard is administrable, and how the use can be measured. Whether the remaining 75% of the expenses of the subset are eligible for the credit appears to depend on whether the subset as a whole meets the seven-part test.

By implication, a subset of dual function software that is developed only for general and administrative functions, or that fails the 10% threshold for the safe harbor, would be subject to the seven-part test to be eligible for the research credit.

By statute, software that is developed for use in a production process that meets the requirements for qualified research is not considered developed for internal use. The regulations specify that computer software supporting the delivery of goods or services to third parties is not part of a production process that is excluded from the definition of internal-use software. Nonetheless, under rules provided in the proposed regulations, computer software supporting the delivery of goods or services to third parties may be outside the definition of software developed primarily for internal use, to the extent that the software enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data.

Also, as in the past, software developed for use in a qualified research activity is not affected, and development costs of a package of software and hardware, that are a single product, used in providing services are evaluated as a single product under the four-part test, not as separate internal-use software and another business component.

High threshold of innovation test

Similar to prior regulations, internal-use software requires three additional tests (collectively referred to as the “high threshold of innovation test”) to be met in order to constitute qualified research under these regulations, as discussed below.

Internal-use software development will, as under prior standards, be qualified research if it meets a three-part high threshold of innovation test. The preamble states that this is a higher standard than for other business components to be qualified research, but the test is not be so restrictive as to make the standard impossible to meet.

The proposed regulations retain the outline and traditional statement about what the three additional requirements are. However, there are new nuances of what is required—and that are likely to provide new challenges to taxpayers seeking to satisfy the high threshold of innovation test.

The traditional innovative test, similar to that in 1986 Committee Reports, is generally reiterated, requiring an economically significant reduction in cost or improvement in speed or other measurable improvement. The proposed regulations would not require successful development, but would require the hoped-for result to be a measurable and objective improvement.The traditional significant economic risk requirement has been modified from prior guidance. This test is to be applied to the level of uncertainty involved at the outset of the development, rather than the degree of innovation represented by the end result. A substantial uncertainty would be considered to exist if, at the beginning of the taxpayer’s activities, the information available to the taxpayer does not establish the capability or method for developing or improving the software. Uncertainty related to appropriate design is an eligible uncertainty under section 174 and for purposes of the general four-part test for all R&D projects.

Under the proposed regulations, however, uncertainty only about appropriate design would apparently not allow IUS development activity to satisfy the high threshold of innovation test. The recognition of appropriate design uncertainty as sufficient for section 174 purposes was the result of careful consideration of comments in the 1990s; its omission from the significant economic risk standard will probably be vigorously addressed in comments.

Significant economic risk requires both technical and economic risk that the substantial uncertainty will not be resolved within a timeframe that will allow the resources devoted to be recovered within a reasonable period. This standard does not require technical uncertainty regarding whether the final result can ever be achieved, but rather whether the final result can be achieved within a timeframe that will allow the substantial resources committed to the development to be recovered within a reasonable period. However, the use of the word “substantial” in terms of uncertainty indicates a higher level of uncertainty is required for IUS than for business components that are not IUS.

The traditional requirement that the software not be commercially available is retained.

Process of experimentation requirement for all software development

These proposed regulations contain examples of how the IRS will apply to computer software—and not only to internal-use software—the requirement in the general definition of qualified research that the activity qualify as a process of experimentation with respect to technical uncertainty. The preamble states that the examples are intended to reflect the view of the IRS and Treasury that the development of certain types of web design and installation of enterprise resource planning (ERP) software would generally not qualify as a process of experimentation; the examples present results for such software that conclude, in the specific situations, no credit would be allowed.

More to the point, however, the examples show how systematic design, evaluation, and testing of algorithms will satisfy the process of experimentation requirement, and show that shrinking back principles will be applied.

For example, Example 9 of the proposed regulations applies the process of experimentation rules to a “plain vanilla” ERP implementation and finds it does not meet the process of experimentation requirement.

On the other hand, Example 10 of the regulations provides further additional facts involving an integration that required a process of experimentation and concludes that the overall ERP project does not meet the process of experimentation requirement but the taxpayer can “shrink back” to a subset of the activities involving the integration and that subset of activities does meet the process of experimentation test. Thus, the fact that software is involved or implemented does not automatically imply that qualifying R&D activities are being performed; conversely, just because ERP software may be involved does not eliminate the potential for finding qualifying R&D activity has occurred under the new proposed IUS regulations.

Comments requested

A hearing at the IRS on the proposed regulations has been scheduled for April 17, 2015, at 10:00 a.m. Comments are requested (and are due March 23, 2015), with specific requests for comments on:

  • The appropriate definition and treatment of connectivity software
  • The safe harbor test for dual function software
  • Other facts and circumstances that could be considered in determining whether internal-use software development meets the three prongs of the high threshold of innovation test

Effective dates

The proposed regulations, once finalized, will be prospective only, applicable in tax years ending on or after the date final regulations are published in the Federal Register.

However, the IRS will not challenge return positions consistent with the proposed regulations for tax years ending on or after January 20, 2015.

The advance notice of proposed rulemaking published at the beginning of 2004 is withdrawn. The notice had contained the contentious statement that taxpayers “may rely” on all of the provisions in the 2001 final regulations, including the since-disavowed “discovery test,” or the provisions dealing with internal-use software in the 2001 proposed regulations that included a “unique or novel” requirement to satisfy the innovativeness prong of the high threshold of innovation test.

In the new proposed regulations, instead, for tax years ending before January 20, 2015, taxpayers “may choose to follow” all of the internal-use software provisions in either the 2001 final regulations (without application of the “discovery test”) or the 2001 proposed regulations. This statement is consistent with the advice provided by the IRS National Office in CCA 201423023, with respect to the FedEx summary judgment order—read more about the provisions of these prior sets of regulations and the FedEx case in the appendix [PDF 138 KB].

How taxpayers may be required to apply the “duty of consistency” rules of section 41(c)(6)(A) for determination of QREs in the base period is an area that is not discussed by the regulations. This could be an area resulting in curious results. For example, in 2014, a taxpayer that develops software for third-party interaction (business component) meets the four-part test; under the standards in place during 2014, this software development could be considered IUS.

In this example, assume this particular software does not meet the high threshold of innovation test, under either the 2014 standards or the standard stated in the new regulations. Thus, the taxpayer does not include the related expenses in the 2014 claim. In 2015 (assuming that the credit gets extended for 2015 with no other changes to section 41), the same business component’s expenses for such software development would not be characterized as IUS, and the QREs are included in the 2015 credit claim.

Under the consistency rule, apparently the 2014 QREs need to be adjusted upward for purposes of an alternative simplified credit (ASC) calculation (an elective calculation method which generally has a base period of 50% of the prior three-year average QRE). Because the new regulations are prospective, the taxpayer might not be able to adjust the 2014 claim to include those software development expenses.

As the regulations are finalized, consideration might be given to establishing some type of transition guidance or a safe harbor to conserve resources of both taxpayers and the IRS.


For more information, contact a tax professional with KPMG’s research credit practice:

David P. Culp | +1 (202) 533-4104 |

Tyrone Montague | +1 (212) 954-6818 |

Christine Kachinsky | +1 (212) 872-2187 |

Michael Brossmer | +1(408) 367-4127 |

Michael Fishman | +1 (214) 840-6966 |

Richard G. Blumenreich | +1 (202) 533-3032 |

Todd Mazzeo | +1 (212) 872-3846 |

Ajay Wanchoo | +1 (212) 954-4488 |

© 2017 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved.

The KPMG logo and name are trademarks of KPMG International. KPMG International is a Swiss cooperative that serves as a coordinating entity for a network of independent member firms. KPMG International provides no audit or other client services. Such services are provided solely by member firms in their respective geographic areas. KPMG International and its member firms are legally distinct and separate entities. They are not and nothing contained herein shall be construed to place these entities in the relationship of parents, subsidiaries, agents, partners, or joint venturers. No member firm has any authority (actual, apparent, implied or otherwise) to obligate or bind KPMG International or any member firm in any manner whatsoever. The information contained in herein is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act on such information without appropriate professional advice after a thorough examination of the particular situation. For more information, contact KPMG's Federal Tax Legislative and Regulatory Services Group at: + 1 202 533 4366, 1801 K Street NW, Washington, DC 20006.

Connect with us


Request for proposal



KPMG's new digital platform

KPMG's new digital platform