2016-23174. Credit for Increasing Research Activities

AGENCY:

Internal Revenue Service (IRS), Treasury.

ACTION:

Final regulations.

SUMMARY:

This document contains final regulations concerning the application of the credit for increasing research activities. These final regulations provide guidance on software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer (internal use software). These final regulations also include examples to illustrate the application of the process of experimentation requirement to software. These final regulations will affect taxpayers engaged in research activities involving software.

DATES:

Effective date: These regulations are effective on October 4, 2016.

Applicability date: For date of applicability see § 1.41-4(e).

FOR FURTHER INFORMATION CONTACT:

Martha Garcia or Jennifer Records of the IRS Office of the Associate Chief Counsel (Passthroughs and Special Industries) at [phone] (not a toll-free number).

SUPPLEMENTARY INFORMATION:

Background

This document contains final regulations that amend the Income Tax Regulations (26 CFR part 1) relating to the credit for increasing research activities (research credit) under section 41 of the Internal Revenue Code (Code). Section 41(d)(4)(E) provides that, except to the extent provided by regulations, research with respect to software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer is excluded from the definition of qualified research under section 41(d). Software that is developed for use in an activity that constitutes qualified research for purposes of section 41(d) and software that is developed for use in a production process with respect to which the general credit eligibility requirements under section 41 are satisfied are internal use software, but are not excluded under section 41(d)(4)(E) from the definition of qualified research and are not subject to these regulations.

On January 20, 2015, the Treasury Department and the IRS published in the Federal Register (80 FR 2624, January 20, 2015) a notice of proposed rulemaking (REG-153656-03, 2015-5 IRB 566) under section 41 (the proposed regulations) relating to the research credit. Comments responding to the proposed regulations were received and a public hearing was held on April 17, 2015. After consideration of all of the comments received, these final regulations adopt the proposed regulations as revised by this Treasury decision.

Summary of Comments and Explanation of Provisions

I. Definition of Internal Use Software

The proposed regulations provided that 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. General and administrative functions, as defined in the proposed regulations, are limited to (1) financial management functions, (2) human resource management functions, and (3) support services functions. Financial management functions are functions that involve the financial management of the taxpayer and the supporting recordkeeping. Human resource management functions are functions that manage the taxpayer's workforce. Support services functions are functions that support the day-to-day operations of the taxpayer, such as data processing or facilities services.

Commenters expressed concern that the list of general and administrative functions in the proposed regulations was overly broad and included functions that do not represent “back-office” functions. In particular, the commenters noted that inventory management, marketing, legal services, and government compliance services can provide significant benefits to third parties and may be 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. Specifically, one commenter noted that many inventory management software applications are an integral part of a taxpayer's supply chain management system and can be readily seen as part of the modern “front office.” This commenter noted that modern inventory management software usually requires interaction with a number of third party vendors to ensure the correct flow of raw materials and a corresponding flow of finished goods. Additionally, the commenter added that inventory management is inherently customer facing because it provides the proper amount of inventory to customers at the point of sale at the right time. Another commenter added that marketing is an external-facing function by nature, and software that supports marketing is necessarily intended to interact with third parties.

The Treasury Department and the IRS understand that many modern software systems perform more than back-office functions. These software systems commonly provide benefits to vendors and include functions that are customer facing. Additionally, software with functions such as marketing or inventory management may not provide solely back-office functions, but may also contain functions that enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system. Recognizing such situations, the proposed regulations provided rules under § 1.41-4(c)(6)(iv)(C) (dual function rules) to evaluate whether software that has both back-office and front-office functions is developed primarily for internal use. The Treasury Department and the IRS continue to believe that functions such as inventory management, marketing, legal services, and government compliance services provide support to day-to-day operations of a taxpayer in carrying on business regardless of the taxpayer's industry and that the benefits that such functions may provide to third parties are collateral and secondary. In addition, the Treasury Department and the IRS believe the dual function rules in these final regulations sufficiently address these comments by allowing taxpayers to identify subsets of elements of dual function software that only enable a taxpayer to interact with third parties or allow third parties to initiate functions or review data. Accordingly, the list of general and administrative functions provided in the proposed regulations remains unchanged in the final regulations.

Another commenter referred to the tax software example in the preamble to the proposed regulations which notes that tax software developed by a company engaged in providing tax services to its customers is not used by the taxpayer in general and administrative functions even though tax is listed under § 1.41-4(c)(6)(iii)(B)(1) of the proposed regulations, as a general and administrative function. The commenter requested that we make this concept more explicit by revising § 1.41-4(c)(6)(iii)(A) of the proposed regulations and providing additional examples. As discussed in the preamble to the proposed regulations, the list of general and administrative functions is intended to target the back-office functions that most taxpayers would have regardless of the taxpayer's industry, although the characterization of a function as back office will vary depending on the facts and circumstances of the taxpayer. Because § 1.41-4(c)(6)(v) of these final regulations makes clear that the determination of whether software is developed primarily for internal use depends on the intent of the taxpayer and the facts and circumstances at the beginning of software development, the Treasury Department and the IRS believe that additional clarifying language and examples are unnecessary.

II. Definition of Software Not Developed Primarily for Internal Use

The 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. After consideration of the comments described herein, these final regulations clarify that (1) software is not developed primarily for the taxpayer's internal use if it is not developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business; and (2) software that is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties and software that 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 are examples of software that is not developed primarily for the taxpayer's internal use.

A. Software Developed To Be Commercially Sold, Leased, Licensed or Otherwise Marketed to Third Parties

A commenter requested that § 1.41-4(c)(6)(iv)(A)(1) of the proposed regulations be revised to state that software is not developed primarily for the taxpayer's internal use if the software is developed to be commercially sold, leased, licensed, hosted, or otherwise marketed to third parties. (Emphasis added.) The commenter also recommended additional language to further define “otherwise marketed” to include transactions where the taxpayer effectively provides the functionality of the software to a third party even if there is no transfer of a copy of the software itself to such third party. The Treasury Department and the IRS understand that a taxpayer may develop software where the full functionality of that software is provided to a third party even though there is no transfer of a copy of the software. The Treasury Department and the IRS believe the phrase “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. An example has been added to further illustrate this point (Example 9 of these final regulations).

B. Software Developed To Enable a Taxpayer To Interact With Third Parties or Allow Third Parties To Initiate Functions or Review Data on the Taxpayer's System

Several commenters requested clarification on the terms “interact,” “initiate,” or “review,” and recommended additional examples illustrating the terms. One commenter noted that a common example that should be clarified is whether a third party reviewing a Web site constitutes “interaction,” “initiate functions,” or “review data.” In response to these comments, the final regulations clarify that software that 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 are examples of software that is not developed primarily for the taxpayer's internal use. In addition, these final regulations provide that the determination of whether software is internal use or 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 depends on the intent of the taxpayer and the facts and circumstances at the beginning of the software development. Accordingly, Example 3 of the proposed regulations, now designated as Example 4 in these final regulations, is revised to show that software developed with the intent of marketing via a Web site and not to allow third parties to review data on the taxpayer's system is developed for internal use because it was developed for use in a general and administrative function.

III. Connectivity Software

In the proposed regulations, the Treasury Department and the IRS requested comments on the appropriate definition and treatment of connectivity software that allows multiple processes running on one or more machines to interact across a network, sometimes referred to as bridging software, integration software, or middleware. The Treasury Department and the IRS received very few responses to this request for comments. One of the commenters noted that the treatment of such software is challenging because of its multi-faceted purposes; it could fall within a category in which it is not sold, does not interact with a third party, and does not perform a general and administrative function. The other commenter recommended that the regulations provide a general rule for connectivity software that is tied to the intent of the taxpayer and the facts and circumstances at the beginning of the software development and that the regulations provide examples demonstrating the rule. In addition, with respect to this category of software, the Treasury Department and the IRS understand that with wide use and availability of enterprise resource planning (ERP) software, few companies actually engage in developing connectivity software. Connectivity software is often purchased or the need for it has diminished due to the use of ERP software.

After further consideration of business practices and the limited comments received, the Treasury Department and the IRS believe that a special rule for connectivity software is not needed. The final regulations clarify that software is not developed by (or for the benefit of) the taxpayer primarily for the taxpayer's internal use if the software is not developed for use in general and administrative functions. Accordingly, any software that is not developed to be used in a general and administrative function will not be considered to be developed for internal use. This is the case even if the software is not developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or is not 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.

Furthermore, connectivity software should not be specifically identified or categorized differently from other types of software. Whether certain software is developed to be used primarily for internal use should be based on the function the software provides, rather than the type of software. For example, connectivity software that is developed to connect a taxpayer's existing payroll software with financial budgeting software to allow an exchange of data between the two software modules would be considered to be developed for the taxpayer's internal use because the connectivity software's function is to be used in human resources and financial management functions. Accordingly, the Treasury Department and the IRS believe that the general rule in the final regulations to determine whether or not software is developed primarily for internal use already provides sufficient guidance for connectivity software. Whether software, including connectivity software, is developed for use in general and administrative functions depends upon the intent of the taxpayer and the facts and circumstances at the beginning of the software development.

IV. Intent of the Taxpayer and the Facts and Circumstances at the Beginning of the Software Development

The proposed regulations provided that whether software is or is not developed primarily for internal use depends upon the intent of the taxpayer and the facts and circumstances at the beginning of the software development. If a taxpayer originally develops software primarily for internal use but later makes improvements to the software with the intent to hold the improved software for commercial sale, lease, or license or to allow third parties to initiate functions or review data on the taxpayer's system, the improvements will be considered separate from the existing software and will not be considered developed primarily for internal use. Likewise, if a taxpayer originally develops software for commercial sale, lease, or license or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system, but later makes improvements to the software with the intent to use the software in general and administrative functions, the improvements will be considered separate from the existing software and will be considered developed primarily for internal use. After consideration of the comments described below, these final regulations retain these rules without modification.

A commenter explained that it is common for a taxpayer to initiate a software development project with one purpose in mind and to later discover that other purposes should be considered and pursued. Commenters also explained that it is common for a taxpayer to abandon its original intentions of how the software might be used. Commenters made several different recommendations, among them that the final regulations adopt a standard that allows facts at any point during the software development to be considered. Another suggested looking to the intended use of the software, and not just the improvements, as of the tax return filing date for the taxable year or the beginning of the taxable year in which the software development expenditures were incurred. One commenter further suggested that if the regulations require a determination at the beginning of the software development, the regulations should allow that determination to be rebutted with evidence about how the software is actually used when it is placed in service. Commenters also noted that taxpayers will likely have difficulty substantiating their intended use of the software at the beginning of the development process.

The Treasury Department and the IRS conclude that only a rule that generally requires that a determination be made at the beginning of software development is consistent with the intent and the purpose of section 41. Congress intended that the credit for increasing research activities would provide an incentive for greater private activity in research. That incentive nature of section 41 is promoted by taking into account a taxpayer's intent at the beginning of the software development; allowing any change in a taxpayer's intent throughout the development to support treatment as qualifying research of expenses incurred prior to that change would frustrate the purpose of the credit. Furthermore, allowing a taxpayer to redetermine the overall project's credit eligibility throughout the development which could span multiple years would provide uncertain and inconsistent treatment and impose an undue burden on both taxpayers and the IRS. Finally, 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 to the same software.

V. Dual Function Software and Safe Harbor

A. Presumption and Third Party Subset

The proposed regulations provided that software developed by (or for the benefit of) the taxpayer both for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business and to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data (dual function software) is presumed to be developed primarily for a taxpayer's internal use. However, this presumption is inapplicable to the extent that a taxpayer can identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer's system (third party subset). The proposed regulations provided that if the taxpayer can identify a third party subset, the portion of qualified research expenditures allocable to such third party subset of the dual function software may be eligible for the research credit, provided all the other applicable requirements are met.

The Treasury Department and the IRS received several comments on dual function software rules. One commenter recommended changes to clarify that the dual function software rules do not apply to software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, even if such software was also 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.

The Treasury Department and the IRS believe such clarification is unnecessary as § 1.41-4(c)(6)(iv)(C)(1) of the proposed regulations clearly defines dual function software as software that is developed by the taxpayer both for use in general and administrative functions and to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data. Software that is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties is not dual function software, even if such software was also 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.

One commenter suggested that the “substantially all” and “shrink back” rules found in § 1.41-4(b)(2) can be easily applied to evaluate dual function software. If substantially all of the software is non-internal use, then all of the software should be considered non-internal use under the substantially all rule. Similarly, if substantially all of the software is internal use, then the software should be considered internal use. In the case where the software as a whole does not meet the substantially all rule, then the taxpayer would apply the shrink back rule and the software would be divided into subcomponents based on functionality until the non-internal use portion and the internal use portion were appropriately separated. That commenter noted that these two rules have worked for many years with little difficulty in other areas of the research credit rules and could be used equally well to address the issue of dual function software. Another commenter encouraged the addition of a rule to cover cases in which a taxpayer's dual function subset's third party use or interaction exceeds 80 percent. The commenter stated that in this circumstance, the remaining internal use is de minimis and should be disregarded and the entire development should be treated as not developed for internal use.

The shrink back rule provides that the requirements of section 41(d) and § 1.41-4(a) are to be applied first at the level of the discrete business component, that is, the product, process, computer software, technique, formula, or invention to be held for sale, lease, or license, or used by the taxpayer in a trade or business of the taxpayer. If these requirements are not met at that level, then they apply at the most significant subset of elements of the product, process, computer software, technique, formula, or invention to be held for sale, lease, or license. This shrinking back of the product is to continue until either a subset of elements of the product that satisfies the requirements is reached, or the most basic element of the product is reached and such element fails to satisfy the test.

The Treasury Department and the IRS believe that the proposed rules already apply principles similar to the shrink back rule to allow taxpayers to identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer's system. The substantially all test referenced by the commenter is similar to the general credit eligibility requirement in section 41(d)(1)(C), which provides that in order for activities to constitute qualified research, substantially all of the activities must constitute elements of a process of experimentation that relates to a qualified purpose. Under § 1.41-4(a)(6), this substantially all requirement is satisfied only if 80 percent or more of a taxpayer's research activities, for the development or improvement of a business component, measured on a cost or other consistently applied reasonable basis, constitute elements of a process of experimentation. In contrast to the general requirement of section 41(d)(1) pertaining to qualifying research, section 41(d)(4)(E) does not apply the substantially all test when it excludes activities related to internal use software from qualifying research. Accordingly, the Treasury Department and the IRS believe the use of the substantially all test in these regulations is inappropriate, and the final regulations do not adopt the commenter's suggested approach.

Another commenter requested that the dual function rules be eliminated because the provisions are confusing and unnecessary and that trying to delineate elements of dual function software raises significant administrative issues. Similarly, another commenter noted that the concepts in the dual function rules can be confusing to taxpayers and will require additional recordkeeping by taxpayers. According to this commenter, most taxpayers do not differentiate their software applications by “third party interactions” or generally track such interactions. One commenter similarly stated that § 1.41-4(c)(6)(iv)(C) of the proposed regulations fails to take into account that software systems cannot always be broken into mutually exclusive subsets enabling only internal use or third party functionality.

Regarding the presumption that dual function software is developed for internal use, a commenter stated that such presumption is contrary to the intent of the statute. One commenter recommended that the presumption should be replaced with a primary purpose test, consistent with the statutory language that looks to whether software is developed “primarily” for internal use.

The Treasury Department and the IRS believe it is necessary to implement rules for dual function software as this type of software development is increasingly common in business practice. Rather than simply reiterating the “primarily” language in the statute, these regulations specifically identify the types of software functions that are considered to be primarily for internal use. A definition that specifically identifies the types of software functions that are considered to be primarily for internal use provides a clearer objective test that will provide consistency in application. The nature of software and its development has rapidly evolved over time, and the statute did not expressly address the treatment of dual function software. In conjunction with crafting a narrow definition of internal use, the Treasury Department and the IRS believe that the dual function software rules in the proposed regulations strike an appropriate balance between the administrative burdens and compliance concerns relating to claiming the research credit for activities relating to software. Thus, these final regulations retain the dual function rules. These final regulations are applicable to taxable years beginning on or after the date of their publication in the Federal Register. Taxpayers have been aware of the proposed rules and have had the opportunity to begin maintaining the necessary documentation to establish their entitlement to research credits under these rules.

B. Safe Harbor

The proposed regulations provided taxpayers with a safe harbor to apply to dual function software if there remains a subset of elements of dual function software (dual function subset) after the third party subset has been identified. The safe harbor allows a taxpayer to include 25 percent of the qualified research expenditures of the dual function subset in computing the amount of the taxpayer's credit, provided that the taxpayer's research activities related to the dual function subset constitute qualified research and the use of the dual function subset by third parties or by the taxpayer to interact with third parties is reasonably anticipated to constitute at least 10 percent of the dual function subset's use.

Some commenters requested that the safe harbor be removed from the regulations. Specifically, one commenter stated that the burdens associated with the safe harbor may be greater than its benefits and noted the multiple steps that a taxpayer must take to determine if it meets the safe harbor. Another commenter noted that the safe harbor complicates the administration of the credit for both taxpayers and the IRS.

Another commenter noted that the safe harbor potentially penalizes the taxpayer with the inequitable result of allowing only 25 percent of the qualified research expenditures. According to the commenter, given that a taxpayer must document anticipated use, it should then follow that the portion of software treated as third party facing should mirror this analysis. In other words, the proportion anticipated to be third party facing should be the proportion of software that is not developed primarily for internal use.

After careful consideration, the final regulations do not adopt these comments. However, the safe harbor has been modified to clarify that the safe harbor can be applied to the dual function software or the dual function subset after the application of § 1.41-4(c)(6)(vi)(B) of the final regulations. The safe harbor is not a requirement but an option available for taxpayers who cannot identify a third party subset, or after identification of a third party subset, still have a dual function subset. Without the safe harbor, dual function software or a dual function subset would be presumed to be internal use and the taxpayer would have to demonstrate that the research with respect to the dual function software or dual function subset meets the high threshold of innovation test in addition to the general eligibility requirements under section 41(d)(1). The safe harbor provides a benefit, not a detriment, to taxpayers, provided the dual function software or dual function subset's use by third parties is anticipated to be at least 10 percent of the total use. Taxpayers who consider it too burdensome to comply with the requirements of the safe harbor can choose not to rely upon it.

C. Time of Determination

Several commenters noted concerns with the time of determination for the application of the safe harbor. A commenter noted that determining the percentage of third party use based upon an estimate made at the beginning of software development imposes an undue administrative burden and may not be an accurate reflection of the actual use once the software is released. This commenter requested that the rule be eliminated or amended to provide that a taxpayer must estimate third party use once the software is deployed. Similarly, another commenter noted that it has not been their experience that taxpayers plot out the future expected use of their software at the time the development begins with such specificity, especially given that software development is an iterative development process where functionality and expected uses rapidly evolve. Lastly, another commenter requested that, similar to the provisions for improvements to existing software, there should be a mechanism to recharacterize software over time.

While the Treasury Department and the IRS understand commenters' concerns, the final regulations do not change the requirement that the time of determination occur at the beginning of the software development. As discussed herein, the Treasury Department and the IRS continue to believe that the rule requiring that a determination be made at the beginning of the software development is most accurate and appropriate given Congress' intent that the research credit serve as an incentive to conduct qualifying research rather than an unanticipated reward for doing so.

D. Objective Reasonable Method

In the proposed regulations, the Treasury Department and the IRS invited comments on the administrability of measuring the reasonably anticipated use of software by taxpayers to interact with third parties and by third parties to initiate functions or review data based on reasonable methods (such as processing time, amount of data transfer, number of software user interface screens, number of third party initiated functions, and other objective, reasonable methods) and whether the regulations should include specific reasonable methods and examples.

A commenter recommended that due to the wide range of taxpayers that will be subject to these regulations, the final regulations should not provide overly detailed examples of “reasonable methods.” This commenter noted that it should be clear that any examples of reasonable methods are for illustrative purposes only and any reasonable method may be acceptable. Another commenter recommended the adoption of the phrase “within each industry” to ensure that the application of the objective, reasonable method takes into account unique aspects of all taxpayers within given industries.

The Treasury Department and the IRS agree that it is unrealistic to impose one specific method that will be used to measure reasonably anticipated use due to the variety of industries that are subject to the final regulations. Therefore, the final regulations provide that any objective, reasonable method within the taxpayer's industry may be used for purposes of the safe harbor.

VI. Third Party Definition

The proposed regulations provided that the term “third party” means any corporation, trade or business, or other person that is not treated as a single taxpayer with the taxpayer pursuant to section 41(f). A commenter raised concerns and requested that the Treasury Department and the IRS reconsider whether it is appropriate to apply the controlled group standard under section 41(f). The commenter contended that this third party definition would potentially deny a research credit to some software for artificial reasons. The commenter further noted that if the regulations do not modify the third party definition, taxpayers should at least have an opportunity to demonstrate that software provided to a member of the controlled group is not internal use software based on the facts and circumstances.

The Treasury Department and the IRS continue to believe that the use of the controlled group standard under section 41(f) is appropriate. A well established, objective standard is essential and using the standard in section 41(f) is consistent with the reference to section 41(f) in section 41(b)(2) relating to in-house research expenditures and in § 1.41-6(a)(3)(ii) relating to the definition of controlled group for purposes of aggregating expenditures.

The proposed regulations also provided that third parties do not include any persons that use the software to support the taxpayer's general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business, e.g., the taxpayer's own vendors. A commenter contended that excluding any person that uses a taxpayer's software to support a general and administrative function from the definition of third party creates confusion and blurs a well-conceived, objective measurement. This commenter believes the term third party suggests a person who is external to the organization or a person who is not an employee. The Treasury Department and the IRS note that the statute provides a higher standard for internal use software, in part, because the benefits of such software are intended primarily for the taxpayer developing it. Where a taxpayer develops software for internal use, any benefit to others, such as vendors or those who provide support services to the taxpayer, is collateral and secondary. Accordingly, the final regulations do not adopt these comments requesting a change to the definition of third party.

VII. High Threshold of Innovation—Significant Economic Risk

The proposed regulations provided that certain internal use software is eligible for the research credit if the software satisfies the high threshold of innovation test, the three parts of which are (1) software is innovative in that the software would result in a reduction in cost or improvement in speed or other measurable improvement, that is substantial and economically significant, if the development is or would have been successful; (2) software development involves significant economic risk in that the taxpayer commits substantial resources to the development and there is a substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period; and (3) software is not commercially available for use by the taxpayer in that the software cannot be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy the innovation and significant economic risk requirements. The proposed regulations further provided that substantial uncertainty exists 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.

A. Design Uncertainty

Several commenters requested that the final regulations include design uncertainty in the definition of technical risk for purposes of meeting the significant economic risk test. Commenters noted that both sections 174 and 41 have long included the concept of design uncertainty. Commenters also raised concerns that the statute and regulations do not define the concepts of capability, methodology, and design uncertainty. Commenters further explained that these three types of uncertainties are inherently related to each other, and it is often difficult for taxpayers to clearly state or describe which type of uncertainty they face.

The use of the word “substantial” before “uncertainty” in the significant economic risk test for internal use software indicates a higher threshold of uncertainty than that required for business components that are not internal use software. While there may be design uncertainty in the development of internal use software, substantial uncertainty generally exists only when there is also uncertainty in regard to the capability or method of achieving the intended result. However, the Treasury Department and the IRS understand that it is difficult to delineate the types of technical uncertainties and attempting to do so may lead to unnecessary burdens on both taxpayers and the IRS. Furthermore, the appropriate design uncertainty of internal use software may be inextricably linked to substantial uncertainty regarding capability or method. The focus of the significant economic risk test should be on the level of uncertainty that exists and not the types of uncertainty. For these reasons, the final regulations remove the reference to capability and method uncertainty. However, the Treasury Department 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.

B. Substantial Resources/Reasonable Time Period

A commenter requested that the final regulations provide further explanation or examples on what constitutes “substantial resources” or a “reasonable time period” for purposes of meeting the significant economic risk test. The Treasury Department and the IRS believe that whether the amount of resources committed is substantial or whether substantial resources would be recovered within a reasonable time period are factual determinations to be resolved based on the taxpayer's facts and circumstances and, therefore, further explanation or examples would be too specific and not helpful. Accordingly, the final regulations do not adopt these comments.

C. Application of High Threshold of Innovation Test

Another commenter requested deletion of the statement, “[i]t is not always necessary to have a revolutionary discovery or creation of new technologies such as a new programming language, operating system, architecture, or algorithm to satisfy the high threshold of innovation test.” The commenter is concerned that the sentence can be read to imply that in some situations it will be necessary to have a revolutionary discovery to qualify internal use software for the research credit. The Treasury Department and the IRS did not intend the inclusion of this statement to have the interpretation suggested or taken by the commenter. Accordingly, the Treasury Department and the IRS agree that this statement should be removed from the final regulations because a revolutionary discovery is not required to meet the high threshold of innovation test.

Furthermore, the Treasury Department and the IRS are revising §§ 1.41-4(c)(6)(i) and (ii) of the proposed regulations to clarify that the internal use software rules under § 1.41-4(c)(6) do not apply to (1) software developed for use in an activity that constitutes qualified research, (2) software developed for use in a production process to which the requirements of section 41(d)(1) are met, and (3) a new or improved package of software and hardware developed together by the taxpayer as a single product. Accordingly, under the final regulations, the high threshold of innovation test applies only to the software developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business and to dual function software.

VIII. Examples

A. Process of Experimentation

Section 1.41-4(a)(8) of the proposed regulations provided six new examples illustrating the application of the process of experimentation requirement to software under section 41(d)(1)(C).

One commenter noted that the examples appear to suggest a presumption that activities related to developing web design or ERP software do not meet the process of experimentation requirement. This commenter requested that the final regulations clearly state the reasons for such presumption. The proposed regulations and these final regulations do not establish a presumption against a particular type of software; rather these examples focus on the facts and circumstances surrounding activities to determine whether they involve a process of experimentation.

Another commenter requested that the final regulations include additional examples demonstrating fact patterns that do not initially qualify as a process of experimentation but where a change in facts introduces technical uncertainty that requires a process of experimentation. The final regulations could provide examples describing a particular change in facts that would introduce technical uncertainty and require a process of experimentation; however, because the examples are very factual and would differ based on a taxpayer's business, we do not think more examples would provide the clarification that the commenter is seeking. Accordingly, the final regulations do not include additional examples to address this comment.

i. Example 6

Section 1.41-4(a)(8), Example 6, of the proposed regulations analyzed whether activities related to selecting a commercial software vendor with object-oriented functions and selecting and incorporating the specific functions into new software developed by X involved conducting a process of experimentation.

One commenter noted that the use of certain terms in Example 6, such as “develop,” “evaluate,” and “determine” suggest that the process of experimentation criteria may be met and recommended changes to clearly show that a purchase, installation, and selection from pre-determined categories do not meet a process of experimentation. We disagree with the commenter because the use or nonuse of certain terms is not an implication that the process of experimentation criteria has or has not been met. This example is intended to show that the process of experimentation requirement is not met regardless of the terms used. Accordingly, the final regulations do not adopt this comment.

ii. Example 7

Section 1.41-4(a)(8), Example 7, of the proposed regulations analyzed whether when developing software, activities relating to X's decision to use a separate server to distribute the workload across each of the web servers and X's decision that a round robin workload distribution algorithm is appropriate for its needs involved conducting a process of experimentation.

Two commenters recommended removing Example 7. One commenter believed that the example did not provide any clarification. The other commenter stated that the example shows a failure to meet the technical uncertainty requirement under section 174, rather than a process of experimentation. While the Treasury Department and the IRS agree with the commenter that activities under section 174 must be for the purpose of discovering information that would eliminate uncertainties, Example 7 is intended to demonstrate the process of experimentation requirement under section 41(d). The example shows a taxpayer's failure to meet the process of experimentation requirement under section 41(d)(1) because the use of a technique or design, such as a round robin workload distribution algorithm, does not qualify where the taxpayer did not conduct a process of evaluating alternatives intended to eliminate uncertainty regarding the development of software. Accordingly, the final regulations do not adopt these comments.

iii. Example 8

Section 1.41-4(a)(8), Example 8, of the proposed regulations analyzed whether X's activities relating to design and systematic testing and evaluation of several different algorithms in the development of load balancing software involved conducting a process of experimentation.

One commenter recommended that all references to the terms “dynamic” and “highly volatile” be removed because the commenter believes the terms provide no additional value and that they suggest that the nature of X's business environment has some bearing on the performance of qualified research. The Treasury Department and the IRS disagree and the final regulations do not adopt the commenter's recommendation because we believe the nature of a taxpayer's business environment can be a valuable indicator of circumstances that may result in the necessary uncertainty required for a process of experimentation.

Another commenter requested that for both Example 8 and Example 10, the Treasury Department and the IRS provide clarification by applying the high threshold of innovation test once the software is determined to be internal use software. Additionally, this commenter requested that the final regulations provide an additional example addressing this process. The Treasury Department and the IRS note that the examples are added to illustrate only the application of a process of experimentation to software research. They are not meant to address the high threshold of innovation test; those examples were provided under § 1.41-4(c)(6)(vi) of the proposed regulations. Furthermore, a comprehensive example that applies the rules contained in § 1.41-4(c)(6) would require more developed facts and layers of analysis and would be better suited for a different type of published guidance than these final regulations. Accordingly, the final regulations do not adopt these comments.

iv. Example 9

Section 1.41-4(a)(8), Example 9, of the proposed regulations analyzed whether X's activities relating to the installation of an ERP system involved a process of experimentation.

Two commenters requested deletion of the phrase “routine programming” in Example 9 because the term is subjective, immeasurable, and inconsistent with Suder v. Commissioner, T.C. Memo 2014-201. One commenter also stated that taxpayers may confront uncertainty about the appropriate design of the configuration of an ERP system, and the example does not address this technical uncertainty. The Treasury Department and the IRS did not intend to illustrate in this example the types of uncertainty that must be eliminated to satisfy the process of experimentation requirement under section 41(d)(1). Rather, this example demonstrates a taxpayer's failure to meet the process of experimentation requirement under section 41(d)(1) because X did not conduct a process of evaluating alternatives in order to eliminate uncertainty regarding the development of the ERP software. Accordingly, the Treasury Department and the IRS believe further clarification of these examples is unnecessary. Furthermore, the Tax Court's decision in Suder is not inconsistent with Example 9 because in Suder the court did not address whether “routine programming” could meet the process of experimentation requirement.

B. Internal Use Software

The proposed regulations provided examples illustrating the provisions contained in § 1.41-4(c)(6) of the proposed regulations.

i. Example 3

Section 1.41-4(c)(6)(vi), Example 3, of the proposed regulations analyzed whether software that is developed for a Web site that provides general information about the taxpayer's business, and which does not enable a taxpayer to interact with third parties or allow third parties to initiate functions or review data, is internal use software.

One commenter disagreed with the characterization of the facts in Example 3 which illustrates a support services function. The commenter believes that the software is dual function software that is developed to allow a third party to review data and to be used in marketing. The Treasury Department and the IRS disagree with the commenter's characterization of Example 3. The example demonstrates that the software is intended to serve marketing purposes and thus is developed to be used in general and administrative functions. Changes were made to clarify this example which is designated as Example 4 of the final regulations.

ii. Example 6

Section 1.41-4(c)(6)(vi), Example 6, of the proposed regulations analyzed the definition of third parties, specifically whether software that is developed to allow its users to upload and modify photographs at no charge allows third parties to initiate functions on the taxpayer's system.

A commenter believed the example is an important example that comes to the correct conclusion, but the commenter believed it is not a particularly good fact pattern to illustrate the third party interaction exclusion. Specifically, the commenter requested changes to the conclusion of the example to show that the advertising software is developed for use in a marketing function to an unrelated third party.

The purpose of the example is to illustrate the third party definition and to demonstrate whether the software is developed to allow third parties to initiate functions or review data. The example is not meant to address which, if any, general and administrative function applies to the software. Accordingly, the final regulations do not adopt this comment. However, other changes were made to clarify Example 6 of the proposed regulations, which is designated as Example 8 of the final regulations.

IX. Effective/Applicability Date

Some commenters requested that the final regulations apply retroactively back to 1986, while one commenter requested that the final regulations apply retroactively back to 2004 to give software development equal treatment with all other types of qualified research as defined under TD 9104 (69 FR 22). After further consideration, the effective date in the proposed regulations is generally retained with slight modifications. These final regulations are prospective and apply to taxable years beginning on or after the date of publication of this Treasury decision in the Federal Register.

Retroactive application of these final regulations may provide an unfair advantage to taxpayers whose prior taxable years are not closed by the statute of limitations. Furthermore, retroactively determining whether taxpayers engaged in research activities does not further the purpose of section 41 which is to encourage taxpayers to engage in qualifying research activities within the United States and would impose a significant administrative burden on the IRS.

Section 41(d)(4)(E) provides that, except to the extent provided by regulations, research with respect to computer software that is developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer is excluded from the definition of qualified research under section 41(d). The nature of software and its development has rapidly evolved over time. Recognizing the evolving nature of software technology and its role in business practices, these final regulations more narrowly define internal use software than the rules that apply for prior periods. These final regulations are not, and should not be viewed as, an interpretation of prior regulatory guidance. Software not developed for internal use under these final regulations, such as software developed to enable a taxpayer to interact with third parties, may or may not have been internal use software under prior law.

The proposed regulations provided that the 2004 ANPRM (published in the Federal Register (69 FR 43)) is withdrawn effective for taxable years beginning on or after January 20, 2015, the date the proposed regulations were published in the Federal Register (80 FR 2624). For taxable years ending before January 20, 2015, taxpayers may choose to follow either all of the internal use software provisions of § 1.41-4(c)(6) in the final regulations published on January 3, 2001 in the Federal Register (TD 8930; 66 FR 280) or all of the internal use software provisions of § 1.41-4(c)(6) contained in the proposed regulations (REG-112991-01) published on December 26, 2001 in the Federal Register (66 FR 66362). In addition, the IRS will not challenge return positions consistent with all of paragraph (c)(6) of these final regulations or all of paragraph (c)(6) of the proposed regulations for any taxable year that both ends on or after January 20, 2015, the date the proposed regulations were published in the Federal Register (80 FR 2624), and begins before October 4, 2016.

X. Duty of Consistency

Some commenters noted the administrative difficulties of applying the duty of consistency rule under section 41(c)(6)(A) and requested guidance on how to comply with the consistency rule.

The duty of consistency is a statutory requirement and existing regulations under §§ 1.41-3(d) and 1.41-9(c) provide sufficient guidance for taxpayers to follow. In computing the research credit, qualified research expenses and gross receipts must be determined on a basis consistent with the definition of qualified research expenses and gross receipts for the credit year. These final regulations do not modify this existing law. Section 1.41-3(d) provides that in computing the credit for increasing research activities, qualified research expenses and gross receipts taken into account in computing a taxpayer's fixed-base percentage and 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, without regard to the law in effect for the taxable years taken into account in computing the fixed-base percentage or the base amount. Section 1.41-3(d) also provides examples illustrating the requirement. Current section 1.41-9(c) contains similar rules. Accordingly, the final regulations do not adopt the commenters' suggestions concerning the duty of consistency.

Special Analyses

Certain IRS regulations, including this one, are exempt from the requirements of Executive Order 12866, as supplemented and reaffirmed by Executive Order 13563. Therefore, a regulatory impact assessment is not required. It also has been determined that section 553(b) of the Administrative Procedure Act (5 U.S.C. chapter 5) does not apply to these regulations, and because the regulations do not impose a collection of information on small entities, the Regulatory Flexibility Act (5 U.S.C. chapter 6) does not apply. Pursuant to section 7805(f) of the Code, the notice of proposed rulemaking was submitted to the Chief Counsel for Advocacy of the Small Business Administration for comment on its impact on small business, and no comments were received.

Drafting Information

The principal author of these regulations is Martha M. Garcia, Office of the Associate Chief Counsel (Passthroughs and Special Industries), IRS. However, other personnel from the Treasury Department and the IRS participated in their development.

List of Subjects in 26 CFR Part 1

• Income taxes
• Reporting and recordkeeping requirements

Adoption of Amendments to the Regulations

Accordingly, 26 CFR part 1 is amended as follows:

PART 1—INCOME TAXES

Paragraph 1. The authority citation for part 1 is amended by adding an entry in numerical order to read in part as follows:

Authority: 26 U.S.C. 7805 * * *

* * * * *

Section 1.41-4 also issued under 26 U.S.C. 41(d)(4)(E).

* * * * *

Par. 2. Section 1.41-0 is amended by:

1. Revising the entry in the table of contents for § 1.41-4(c)(6).

2. Adding entries in the table of contents for § 1.41-4(c)(6)(i) through (viii).

The revision and additions read as follows:

§ 1.41-0.

Table of contents.

* * * * *

§ 1.41-4.

Qualified research for expenditures paid or incurred in taxable years ending on or after December 31, 2003.

* * * * *

(c) * * *

(6) Internal use software.

(i) General rule.

(ii) Inapplicability of the high threshold of innovation test.

(iii) Software developed primarily for internal use.

(iv) Software not developed primarily for internal use.

(v) Time and manner of determination.

(vi) Software developed for both internal use and to enable interaction with third parties (dual function software).

(vii) High threshold of innovation test.

(viii) Illustrations.

* * * * *

Par. 3. Section 1.41-4 is amended by:

1. Adding Example 5 through Example 10 at the end of paragraph (a)(8).

2. Revising paragraphs (c)(6) and (e).

The additions and revisions read as follows:

§ 1.41-4

Qualified research for expenditures paid or incurred in taxable years ending on or after December 31, 2003.

(a) * * *

(8) * * *

Example 5.

(i) Facts. X, a retail and distribution company, wants to upgrade its warehouse management software. X evaluates several of the alternative warehouse management software products available from vendors in the marketplace to determine which product will best serve X's technical requirements. X selects vendor V's software.

(ii) Conclusion. X's activities to select the software are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating alternatives in order to eliminate uncertainty regarding the development of a business component. X's evaluation of products available from vendors is not a process of experimentation.

Example 6.

(i) Facts. X wants to develop a new web application to allow customers to purchase its products online. X, after reviewing commercial software offered by various vendors, purchases a commercial software package of object-oriented functions from vendor Z that X can use in its web application (for example, a shopping cart). X evaluates the various object-oriented functions included in vendor Z's software package to determine which functions it can use. X then incorporates the selected software functions in its new web application software.

(ii) Conclusion. X's activities related to selecting the commercial software vendor with the object-oriented functions it wanted, and then selecting which functions to use, are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. In addition, incorporating the selected object-oriented functions into the new web application software being developed by X did not involve conducting a process of evaluating alternatives in order to eliminate uncertainty regarding the development of software. X's evaluation of products available from vendors and selection of software functions are not a process of experimentation.

Example 7.

(i) Facts. In order to be more responsive to user online requests, X wants to develop software to balance the incoming processing requests across multiple web servers that run the same set of software applications. Without evaluating or testing any alternatives, X decides that a separate server will be used to distribute the workload across each of the web servers and that a round robin workload distribution algorithm is appropriate for its needs.

(ii) Conclusion. X's activities to develop the software are activities relating to the development of a separate business component under section 41(d)(2)(A). X's activities to develop the load distribution function are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating different load distribution alternatives in order to eliminate uncertainty regarding the development of software. X's selection of a separate server and a round robin distribution algorithm is not a process of experimentation.

Example 8.

(i) Facts. X must develop load balancing software across a server cluster supporting multiple web applications. X's web applications have high concurrency demands because of a dynamic, highly volatile environment. X is uncertain of the appropriate design of the load balancing algorithm, given that the existing evolutionary algorithms did not meet the demands of their highly volatile web environment. Therefore, X designs and systematically tests and evaluates several different algorithms that perform the load distribution functions.

(ii) Conclusion. X's activities to develop software are activities to develop a separate business component under section 41(d)(2)(A). X's activities involving the design, evaluation, and systematic testing of several new load balancing algorithms meet the requirements as set forth in paragraph (a)(5) of this section. X's activities constitute elements of a process of experimentation because X identified uncertainties related to the development of a business component, identified alternatives intended to eliminate those uncertainties, and evaluated one or more alternatives to achieve a result where the appropriate design was uncertain at the beginning of X's research activities.

Example 9.

(i) Facts. X, a multinational manufacturer, wants to install an enterprise resource planning (ERP) system that runs off a single database so that X can track orders more easily, and coordinate manufacturing, inventory, and shipping among many different locations at the same time. In order to successfully install and implement ERP software, X evaluates its business needs and the technical requirements of the software, such as processing power, memory, storage, and network resources. X devotes the majority of its resources in implementing the ERP system to evaluating the available templates, reports, and other standard programs and choosing among these alternatives in configuring the system to match its business process and reengineering its business process to match the available alternatives in the ERP system. X also performs some data transfer from its old system, involving routine programming and one-to-one mapping of data to be exchanged between each system.

(ii) Conclusion. X's activities related to the ERP software including the data transfer are not qualified research under section 41(d)(1) and paragraph (a)(5) of this section. X did not conduct a process of evaluating alternatives in order to eliminate uncertainty regarding the development of software. X's activities in choosing between available templates, reports, and other standard programs and conducting data transfer are not elements of a process of experimentation.

Example 10.

(i) Facts. Same facts as Example 9 except that X determines that it must interface part of its legacy software with the new ERP software because the ERP software does not provide a particular function that X requires for its business. As a result, X must develop an interface between its legacy software and the ERP software, and X evaluates several data exchange software applications and chooses one of the available alternatives. X is uncertain as to how to keep the data synchronized between the legacy and ERP systems. Thus, X engages in systematic trial and error testing of several newly designed data caching algorithms to eliminate synchronization problems.

(ii) Conclusion. Substantially all of X's activities with respect to this ERP project do not satisfy the requirements for a process of experimentation. However, when the shrinking-back rule is applied, a subset of X's activities do satisfy the requirements for a process of experimentation. X's activities to develop the data caching software and keeping the data on the legacy and ERP systems synchronized meet the requirements of qualified research as set forth in paragraph (a)(2) of this section. Substantially all of X's activities to develop the specialized data caching and synchronization software constitute elements of a process of experimentation because X identified uncertainties related to the development of a business component, identified alternatives intended to eliminate those uncertainties, and evaluated alternatives to achieve a result where the appropriate design of that result was uncertain as of the beginning of the taxpayer's research activities.

* * * * *

(c) * * *

(6) Internal use software—(i) General rule. Research with respect to software that is developed by (or for the benefit of) the taxpayer primarily for the taxpayer's internal use is eligible for the research credit only if—

(A) The research with respect to the software satisfies the requirements of section 41(d)(1);

(B) The research with respect to the software is not otherwise excluded under section 41(d)(4) (other than section 41(d)(4)(E)); and

(C) The software satisfies the high threshold of innovation test of paragraph (c)(6)(vii) of this section.

(ii) Inapplicability of the high threshold of innovation test. This paragraph (c)(6) does not apply to the following:

(A) Software developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer for use in an activity that constitutes qualified research (other than the development of the internal use software itself);

(B) Software developed by (or for the benefit of) the taxpayer primarily for internal use by the taxpayer for use in a production process to which the requirements of section 41(d)(1) are met; and

(C) A new or improved package of software and hardware developed together by the taxpayer as a single product (or to the costs to modify an acquired software and hardware package), of which the software is an integral part, that is used directly by the taxpayer in providing services in its trade or business. In these cases, eligibility for the research credit is to be determined by examining the combined hardware-software product as a single product.

(iii) Software developed primarily for internal use—(A) In general. Except as otherwise provided in paragraph (c)(6)(vi) of this section, software is developed by (or for the benefit of) the taxpayer primarily for the taxpayer's internal use if the software is developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business. Software that the taxpayer develops primarily for a related party's internal use will be considered internal use software. A related party is any corporation, trade or business, or other person that is treated as a single taxpayer with the taxpayer pursuant to section 41(f).

(B) General and administrative functions. General and administrative functions are:

(1) Financial management. Financial management functions are functions that involve the financial management of the taxpayer and the supporting recordkeeping. Financial management functions include, but are not limited to, functions such as accounts payable, accounts receivable, inventory management, budgeting, cash management, cost accounting, disbursements, economic analysis and forecasting, financial reporting, finance, fixed asset accounting, general ledger bookkeeping, internal audit, management accounting, risk management, strategic business planning, and tax.

(2) Human resources management. Human resources management functions are functions that manage the taxpayer's workforce. Human resources management functions include, but are not limited to, functions such as recruiting, hiring, training, assigning personnel, and maintaining personnel records, payroll, and benefits.

(3) Support services. Support services are other functions that support the day- to-day operations of the taxpayer. Support services include, but are not limited to, functions such as data processing, facility services (for example, grounds keeping, housekeeping, janitorial, and logistics), graphic services, marketing, legal services, government compliance services, printing and publication services, and security services (for example, video surveillance and physical asset protection from fire and theft).

(iv) Software not developed primarily for internal use. Software is not developed primarily for the taxpayer's internal use if it is not developed for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business, such as—

(A) Software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties; or

(B) 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.

(v) Time and manner of determination. For purposes of paragraphs (c)(6)(iii) and (iv) of this section, whether software is developed primarily for internal use or not developed primarily for internal use depends on the intent of the taxpayer and the facts and circumstances at the beginning of the software development. For example, software will not be considered internal use software solely because it is used internally for purposes of testing prior to commercial sale, lease, or license. If a taxpayer originally develops software primarily for internal use, but later makes improvements to the software with the intent to hold the improved software to be sold, leased, licensed, or otherwise marketed to third parties, or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system using the improved software, the improvements will be considered separate from the existing software and will not be considered developed primarily for internal use. Alternatively, if a taxpayer originally develops software to be sold, leased, licensed, or otherwise marketed to third parties, or to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system, but later makes improvements to the software with the intent to use the software in general and administrative functions, the improvements will be considered separate from the existing software and will be considered developed primarily for internal use.

(vi) Software developed for both internal use and to enable interaction with third parties (dual function software)—(A) Presumption of development primarily for internal use. Unless paragraph (c)(6)(vi)(B) or (C) of this section applies, software developed by (or for the benefit of) the taxpayer both for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business and 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 (dual function software) is presumed to be developed primarily for a taxpayer's internal use.

(B) Identification of a subset of elements of software that only enables interaction with third parties. To the extent that a taxpayer can identify a subset of elements of dual function software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data (third party subset), the presumption under paragraph (c)(6)(vi)(A) of this section does not apply to such third party subset, and such third party subset is not developed primarily for internal use as described under paragraph (c)(6)(iv)(B) of this section.

(C) Safe harbor for expenditures related to software developed for both internal use and to enable interaction with third parties. If, after the application of paragraph (c)(6)(vi)(B) of this section, there remains dual function software or a subset of elements of dual function software (dual function subset), a taxpayer may include 25 percent of the qualified research expenditures of such dual function software or dual function subset in computing the amount of the taxpayer's credit. This paragraph (c)(6)(vi)(C) applies only if the taxpayer's research activities related to the development or improvement of the dual function software or dual function subset constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the dual function software or dual function subset's use by third parties or by the taxpayer to interact with third parties is reasonably anticipated to constitute at least 10 percent of the dual function software or the dual function subset's use. An objective, reasonable method within the taxpayer's industry must be used to estimate the dual function software or dual function subset's use by third parties or by the taxpayer to interact with third parties. An objective, reasonable method may include, but is not limited to, processing time, amount of data transfer, and number of software user interface screens.

(D) Time and manner of determination. A taxpayer must apply this paragraph (c)(6)(vi) based on the intent of the taxpayer and the facts and circumstances at the beginning of the software development.

(E) Third party. For purposes of paragraphs (c)(6)(iv), (v), and (vi) of this section, the term third party means any corporation, trade or business, or other person that is not treated as a single taxpayer with the taxpayer pursuant to section 41(f). Additionally, for purposes of paragraph (c)(6)(iv)(B) of this section, third parties do not include any persons that use the software to support the general and administrative functions of the taxpayer.

(vii) High threshold of innovation test—(A) In general. Software satisfies this paragraph (c)(6)(vii) only if the taxpayer can establish that—

(1) The software is innovative;

(2) The software development involves significant economic risk; and

(3) The software is not commercially available for use by the taxpayer in that the software cannot be purchased, leased, or licensed and used for the intended purpose without modifications that would satisfy the requirements of paragraphs (c)(6)(vii)(A)(1) and (2) of this section.

(B) Innovative. Software is innovative if the software would result in a reduction in cost or improvement in speed or other measurable improvement, that is substantial and economically significant, if the development is or would have been successful. This is a measurable objective standard, not a determination of the unique or novel nature of the software or the software development process.

(C) Significant economic risk. The software development involves significant economic risk if the taxpayer commits substantial resources to the development and if there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period. The term “substantial uncertainty” requires a higher level of uncertainty and technical risk than that required for business components that are not internal use software. 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. Technical risk arises from uncertainty that is technological in nature, as defined in paragraph (a)(4) of this section, and substantial uncertainty must exist at the beginning of the taxpayer's activities.

(D) Application of high threshold of innovation test. The high threshold of innovation test of paragraph (c)(6)(vii) of this section takes into account only the results anticipated to be attributable to the development of new or improved software at the beginning of the software development independent of the effect of any modifications to related hardware or other software. The implementation of existing technology by itself is not evidence of innovation, but the use of existing technology in new ways could be evidence of a high threshold of innovation if it resolves substantial uncertainty as defined in paragraph (c)(6)(vii)(C) of this section.

(viii) Illustrations. The following examples illustrate provisions contained in this paragraph (c)(6). No inference should be drawn from these examples concerning the application of section 41(d)(1) and paragraph (a) of this section to these facts.

Example 1.

Computer hardware and software developed as a single product—(i) Facts. X is a telecommunications company that developed high technology telephone switching hardware. In addition, X developed software that interfaces directly with the hardware to initiate and terminate a call, along with other functions. X designed and developed the hardware and software together.

(ii) Conclusion. The telecommunications software that interfaces directly with the hardware is part of a package of software and hardware developed together by the taxpayer that is used by the taxpayer in providing services in its trade or business. Accordingly, this paragraph (c)(6) does not apply to the software that interfaces directly with the hardware as described in paragraph (c)(6)(ii)(C) of this section, and eligibility for the research credit is determined by examining the combined software-hardware product as a single product.

Example 2.

Internal use software; financial management—(i) Facts. X, a manufacturer, self-insures its liabilities for employee health benefits. X develops its own software to administer its self-insurance reserves related to employee health benefits. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The software is developed for use in a general and administrative function because reserve valuation is a financial management function under paragraph (c)(6)(iii)(B)(1) of this section. Accordingly, the software is internal use software because it is developed for use in a general and administrative function.

Example 3.

Internal use software; human resources management—(i) Facts. X, a manufacturer, develops a software module that interacts with X's existing payroll software to allow X's employees to print pay stubs and make certain changes related to payroll deductions over the internet. At the beginning of the development, X does not intend to develop the software module for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The employee access software module is developed for use in a general and administrative function because employee access software is a human resources management function under paragraph (c)(6)(iii)(B)(2) of this section. Accordingly, the software module is internal use software because it is developed for use in a general and administrative function.

Example 4.

Internal use software; support services—(i) Facts. X, a restaurant, develops software for a Web site that provides information, such as items served, price, location, phone number, and hours of operation for purposes of advertising. At the beginning of the development, X does not intend to develop the Web site software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system. X intends to use the software for marketing by allowing third parties to review general information on X's Web site.

(ii) Conclusion. The software is developed for use in a general and administrative function because the software was developed to be used by X for marketing which is a support services function under paragraph (c)(6)(iii)(B)(3) of this section. Accordingly, the software is internal use software because it is developed for use in a general and administrative function.

Example 5.

Internal use software—(i) Facts. X, a multinational manufacturer with different business and financial systems in each of its divisions, undertakes a software development project aimed at integrating the majority of the functional areas of its major software systems (Existing Software) into a single enterprise resource management system supporting centralized financial systems, human resources, inventory, and sales. X purchases software (New Software) upon which to base its enterprise-wide system. X has to develop software (Developed Software) that transfers data from X's legacy financial, human resources, inventory, and sales systems to the New Software. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The financial systems, human resource systems, inventory and sales systems are general and administrative functions under paragraph (c)(6)(iii)(B) of this section. Accordingly, the Developed Software is internal use software because it is developed for use in general and administrative functions.

Example 6.

Internal use software; definition of third party—(i) Facts. X develops software to interact electronically with its vendors to improve X's inventory management. X develops the software to enable X to interact with vendors and to allow vendors to initiate functions or review data on the taxpayer's system. X defines the electronic messages that will be exchanged between X and the vendors. X's software allows a vendor to request X's current inventory of the vendor's product, and allows a vendor to send a message to X which informs X that the vendor has just made a new shipment of the vendor's product to replenish X's inventory. At the beginning of development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties.

(ii) Conclusion. Under paragraph (c)(6)(vi)(E) of this section, X's vendors are not third parties for purposes of paragraph (c)(6)(iv) of this section. While X's software was developed to allow vendors to initiate functions or review data on the taxpayer's system, the software is not excluded from internal use software as set forth in paragraph (c)(6)(iv)(B) of this section because the software was developed to allow vendors to use the software to support X's inventory management, which is a general and administrative function of X.

Example 7.

Not internal use software; third party interaction—(i) Facts. X, a manufacturer of various products, develops software for a Web site with the intent to allow third parties to access data on X's database, to order X's products and track the status of their orders online. At the beginning of the development, X does not intend to develop the Web site software for commercial sale, lease, license, or to be otherwise marketed to third parties.

(ii) Conclusion. The software is not developed primarily for internal use because it is not developed for use in a general and administrative function. X developed the software to allow third parties to initiate functions or review data on the taxpayer's system as provided under paragraph (c)(6)(iv)(B) of this section.

Example 8.

Not internal use software; third party interaction—(i) Facts. X developed software that allows its users to upload and modify photographs at no charge. X earns revenue by selling advertisements that are displayed while users enjoy the software that X offers for free. X also developed software that has interfaces through which advertisers can bid for the best position in placing their ads, set prices for the ads, or develop advertisement campaign budgets. At the beginning of the development, X intended to develop the software to enable X to interact with third parties or to allow third parties to initiate functions on X's system.

(ii) Conclusion. The software for uploading and modifying photographs is not developed primarily for internal use because it is not developed for use in X's general and administrative functions under paragraph (c)(6)(iii)(A) of this section. The users and the advertisers are third parties for purposes of paragraph (c)(6)(iv) of this section. Furthermore, both the software for uploading and modifying photographs and the advertising software are not internal use software under paragraph (c)(6)(iv)(B) of this section because at the beginning of the development X developed the software with the intention of enabling X to interact with third parties or to allow third parties to initiate functions on X's system.

Example 9.

Not internal use software; commercially sold, leased, licensed, or otherwise marketed—(i) Facts. X is a provider of cloud-based software. X develops enterprise application software (including customer relationship management, sales automation, and accounting software) to be accessed online and used by X's customers. At the beginning of development, X intended to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties.

(ii) Conclusion. The software is not developed primarily for internal use because it is not developed for use in a general and administrative function. X developed the software to be commercially sold, leased, licensed, or otherwise marketed to third parties under paragraph (c)(6)(iv)(A) of this section.

Example 10.

Improvements to existing internal use software—(i) Facts. X has branches throughout the country and develops its own facilities services software to coordinate moves and to track maintenance requests for all locations. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system. Several years after completing the development and using the software, X consults its business development department, which assesses the market for the software. X determines that the software could be sold at a profit if certain technical and functional enhancements are made. X develops the improvements to the software, and sells the improved software to third parties.

(ii) Conclusion. Support services, which include facility services, are general and administrative functions under paragraph (c)(6)(iii)(B) of this section. Accordingly, the original software is developed for use in general and administrative functions and is, therefore, developed primarily for internal use. However, the improvements to the software are not developed primarily for internal use because the improved software was not developed for use in a general and administrative function. X developed the improved software to be commercially sold, leased, licensed, or otherwise marketed to third parties under paragraphs (c)(6)(iv)(A) and (c)(6)(v) of this section.

Example 11.

Dual function software; identification of a third party subset—(i) Facts. X develops software for use in general and administrative functions that facilitate or support the conduct of X's trade or business and to allow third parties to initiate functions. X is able to identify a third party subset. X incurs $50,000 of research expenditures for the software, 50% of which is allocable to the third party subset.

(ii) Conclusion. The software developed by X is dual function software. Because X is able to identify a third party subset, the third party subset is not presumed to be internal use software under paragraph (c)(6)(vi)(A) of this section. If X's research activities related to the third party subset constitute qualified research under section 41(d), and the allocable expenditures are qualified research expenditures under section 41(b), $25,000 of the software research expenditures allocable to the third party subset may be included in computing the amount of X's credit, pursuant to paragraph (c)(6)(vi)(B) of this section. If, after the application of paragraph (c)(6)(vi)(B) of this section, there remains a dual function subset, X may determine whether paragraph (c)(6)(vi)(C) of this section applies.

Example 12.

Dual function software; application of the safe harbor—(i) Facts. The facts are the same as in Example 11, except that X is unable to identify a third party subset. X uses an objective, reasonable method at the beginning of the software development to determine that the dual function software's use by third parties to initiate functions is reasonably anticipated to constitute 15% of the dual function software's use.

(ii) Conclusion. The software developed by X is dual function software. The software is presumed to be developed primarily for internal use under paragraph (c)(6)(vi)(A) of this section. Although X is unable to identify a third party subset, X reasonably anticipates that the dual function software's use by third parties will be at least 10% of the dual function software's use. If X's research activities related to the development or improvement of the dual function software constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under section 41(b), X may include $12,500 (25% of $50,000) of the software research expenditures of the dual function software in computing the amount of X's credit pursuant to paragraph (c)(6)(vi)(C) of this section.

Example 13.

Dual function software; safe harbor inapplicable—(i) Facts. The facts are the same as in Example 11, except X is unable to identify a third party subset. X uses an objective, reasonable method at the beginning of the software development to determine that the dual function software's use by third parties to initiate functions is reasonably anticipated to constitute 5% of the dual function software's use.

(ii) Conclusion. The software developed by X is dual function software. The software is presumed to be developed primarily for X's internal use under paragraph (c)(6)(vi)(A) of this section. X is unable to identify a third party subset, and X reasonably anticipates that the dual function software's use by third parties will be less than 10% of the dual function software's use. X may only include the software research expenditures of the dual function software in computing the amount of X's credit if the software satisfies the high threshold of innovation test of paragraph (c)(6)(vii) of this section and X's research activities related to the development or improvement of the dual function software constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under section 41(b).

Example 14.

Dual function software; identification of a third party subset and the safe harbor—(i) Facts. X develops software for use in general and administrative functions that facilitate or support the conduct of X's trade or business and to allow third parties to initiate functions and review data. X is able to identify a third party subset (Subset A). The remaining dual function subset of the software (Subset B) allows third parties to review data and provides X with data used in its general and administrative functions. X is unable to identify a third party subset of Subset B. X incurs $50,000 of research expenditures for the software, 50% of which is allocable to Subset A and 50% of which is allocable to Subset B. X determines, at the beginning of the software development, that the processing time of the third party use of Subset B is reasonably anticipated to account for 15% of the total processing time of Subset B.

(ii) Conclusion. The software developed by X is dual function software. Because X is able to identify a third party subset, such third party subset (Subset A) is not presumed to be internal use software under paragraph (c)(6)(vi)(A) of this section. If X's research activities related to the development or improvement of Subset A constitute qualified research under section 41(d), and the allocable expenditures are qualified research expenditures under section 41(b), the $25,000 of the software research expenditures allocable to Subset A may be included in computing the amount of X's credit pursuant to paragraph (c)(6)(vi)(B) of this section. Although X is unable to identify a third party subset of Subset B, 15% of Subset B's use is reasonably anticipated to be attributable to the use of Subset B by third parties. If X's research activities related to the development or improvement of Subset B constitute qualified research under section 41(d), without regard to section 41(d)(4)(E), and the allocable expenditures are qualified research expenditures under 41(b), X may include $6,250 (25% x $25,000) of the software research expenditures of Subset B in computing the amount of X's credit, pursuant to paragraph (c)(6)(vi)(C) of this section.

Example 15.

Internal use software; application of the high threshold of innovation test—(i) Facts. X maintained separate software applications for tracking a variety of human resource (HR) functions, including employee reviews, salary information, location within the hierarchy and physical location of employees, 401(k) plans, and insurance coverage information. X determined that improved HR efficiency could be achieved by redesigning its disparate software applications into one employee-centric system, and worked to develop that system. X also determined that commercially available database management systems did not meet all of the requirements of the proposed system. Rather than waiting several years for vendor offerings to mature and become viable for its purpose, X embarked upon the project utilizing older technology that was severely challenged with respect to data modeling capabilities. The improvements, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. For example, having one employee-centric system would remove the duplicative time and cost of manually entering basic employee information separately in each application because the information would only have to be entered once to be available across all applications. The limitations of the technology X was attempting to utilize required that X attempt to develop a new database architecture. X committed substantial resources to the project, but could not predict, because of technical risk, whether it could develop the database software in the timeframe necessary so that X could recover its resources in a reasonable period. Specifically, X was uncertain regarding the capability of developing, within a reasonable period, a new database architecture using the old technology that would resolve its technological issues regarding the data modeling capabilities and the integration of the disparate systems into one system. At the beginning of the development, X did not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. However, the software satisfies the high threshold of innovation test set forth in paragraph (c)(6)(vii) of this section. The software was intended to be innovative in that it would provide a reduction in cost or improvement in speed that is substantial and economically significant. In addition, X's development activities involved significant economic risk in that X committed substantial resources to the development and there was substantial uncertainty, because of technical risk, that the resources would be recovered within a reasonable period. Finally, at the time X undertook the development of the system, software meeting X's requirements was not commercially available for use by X.

Example 16.

Internal use software; application of the high threshold of innovation test—(i) Facts. X undertook a software project to rewrite a legacy mainframe application using an object-oriented programming language, and to move the new application off the mainframe to a client/server environment. Both the object-oriented language and client/server technologies were new to X. This project was undertaken to develop a more maintainable application, which X expected would significantly reduce the cost of maintenance, and implement new features more quickly, which X expected would provide both significant improvements in speed and reduction in cost. Thus, the improvements, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. X also determined that commercially available systems did not meet the requirements of the proposed system. X was certain that it would be able to overcome any technological uncertainties and implement the improvements within a reasonable period. However, X was unsure of the appropriate methodology to achieve the improvements. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. X's activities do not satisfy the high threshold of innovation test of paragraph (c)(6)(vii) of this section. Although the software meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of this section, X's development activities did not involve significant economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X did not have substantial uncertainty, because of technical risk, that the resources committed to the project would be recovered within a reasonable period.

Example 17.

Internal use software; application of the high threshold of innovation test—(i) Facts. X wants to expand its internal computing power, and is aware that its PCs and workstations are idle at night, on the weekends, and for a significant part of any business day. Because the general and administrative computations that X needs to make could be done on workstations as well as PCs, X develops a screen-saver-like application that runs on employee computers. When employees' computers have been idle for an amount of time set by each employee, X's application goes back to a central server to get a new job to execute. This job will execute on the idle employee's computer until it has either finished, or the employee resumes working on his computer. The ability to use the idle employee's computers would save X significant costs because X would not have to buy new hardware to expand the computing power. The improvements, if successful, would provide a reduction in cost that is substantial and economically significant. At the time X undertook the software development project, there was no commercial application available with such a capability. In addition, at the time X undertook the software development project, X was uncertain regarding the capability of developing a server application that could schedule and distribute the jobs across thousands of PCs and workstations, as well as handle all the error conditions that occur on a user's machine. X commits substantial resources to the project. X undertakes a process of experimentation to attempt to eliminate its uncertainty. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. However, the software satisfies the high threshold of innovation test as set forth in paragraph (c)(6)(vii) of this section. The software was intended to be innovative because it would provide a reduction in cost or improvement in speed that is substantial and economically significant. In addition, X's development activities involved significant economic risk in that X committed substantial resources to the development and there was substantial uncertainty that because of technical risk, such resources would be recovered within a reasonable period. Finally, at the time X undertook the development of the system, software meeting X's requirements was not commercially available for use by X.

Example 18.

Internal use software; application of the high threshold of innovation test—(i) Facts. X, a multinational manufacturer, wants to install an enterprise resource planning (ERP) system that runs off a single database. However, to implement the ERP system, X determines that it must integrate part of its old system with the new because the ERP system does not have a particular function that X requires for its business. The two systems are general and administrative software systems. The systems have mutual incompatibilities. The integration, if successful, would provide a reduction in cost and improvement in speed that is substantial and economically significant. At the time X undertook this project, there was no commercial application available with such a capability. X is uncertain regarding the appropriate design of the interface software. However, X knows that given a reasonable period of time to experiment with various designs, X would be able to determine the appropriate design necessary to meet X's technical requirements and would recover the substantial resources that X commits to the development of the system within a reasonable period. At the beginning of the development, X does not intend to develop the software for commercial sale, lease, license, or to be otherwise marketed to third parties or to enable X to interact with third parties or to allow third parties to initiate functions or review data on X's system.

(ii) Conclusion. The software is internal use software because it is developed for use in a general and administrative function. X's activities do not satisfy the high threshold of innovation test of paragraph (c)(6)(vii) of this section. Although the software meets the requirements of paragraphs (c)(6)(vii)(A)(1) and (3) of this section, X's development activities did not involve significant economic risk under paragraph (c)(6)(vii)(A)(2) of this section. X did not have substantial uncertainty, because of technical risk, that the resources committed to the project would be recovered within a reasonable period.

* * * * *

(e) Effective/applicability dates. Other than paragraph (c)(6) of this section, this section is applicable for taxable years ending on or after December 31, 2003. Paragraph (c)(6) of this section is applicable for taxable years beginning on or after October 4, 2016. For any taxable year that both ends on or after January 20, 2015 and begins before October 4, 2016, the IRS will not challenge return positions consistent with all of paragraph (c)(6) of this section or all of paragraph (c)(6) of this section as contained in the Internal Revenue Bulletin (IRB) 2015-5 (see www.irs.gov/​pub/​irs-irbs/​irb15-05.pdf). For taxable years ending before January 20, 2015, taxpayers may choose to follow either all of § 1.41-4(c)(6) as contained in 26 CFR part 1 (revised as of April 1, 2003) and IRB 2001-5 (see www.irs.gov/​pub/​irs-irbs/​irb01-05.pdf) or all of § 1.41-4(c)(6) as contained in IRB 2002-4 (see www.irs.gov/​pub/​irs-irbs/​irb02-04.pdf).

John Dalrymple,

Deputy Commissioner for Services and Enforcement.

Approved: August 22, 2016.

Mark J. Mazur

Assistant Secretary of the Treasury (Tax Policy).