Credit for Increasing Research Activities, 68299-68312 [2016-23174]

Agencies

• Internal Revenue Service
• DEPARTMENT OF THE TREASURY

[Federal Register Volume 81, Number 192 (Tuesday, October 4, 2016)]
[Rules and Regulations]
[Pages 68299-68312]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-23174]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF THE TREASURY

Internal Revenue Service

26 CFR Part 1

[TD 9786]
RIN 1545-BC70


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 Sec.  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 (202) 317-6853 (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 Sec.  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

[[Page 68300]]

even though tax is listed under Sec.  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 
Sec.  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 Sec.  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 Sec.  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

[[Page 68301]]

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 Sec.  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 Sec.  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

[[Page 68302]]

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 Sec.  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 Sec.  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 Sec.  
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

[[Page 68303]]

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 Sec.  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 Sec.  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

[[Page 68304]]

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 
Sec. Sec.  1.41-4(c)(6)(i) and (ii) of the proposed regulations to 
clarify that the internal use software rules under Sec.  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

[[Page 68305]]

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 
Sec.  1.41-4(c)(6)(vi) of the proposed regulations. Furthermore, a 
comprehensive example that applies the rules contained in Sec.  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 Sec.  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

[[Page 68306]]

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 Sec.  
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 Sec.  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 Sec. Sec.  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

0
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).
* * * * *

0
Par. 2. Section 1.41-0 is amended by:
0
1. Revising the entry in the table of contents for Sec.  1.41-4(c)(6).
0
2. Adding entries in the table of contents for Sec.  1.41-4(c)(6)(i) 
through (viii).
    The revision and additions read as follows:


Sec.  1.41-0.  Table of contents.

* * * * *


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

* * * * *
    (c) * * *

[[Page 68307]]

    (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.
* * * * *

0
Par. 3. Section 1.41-4 is amended by:
0
1. Adding Example 5 through Example 10 at the end of paragraph (a)(8).
0
2. Revising paragraphs (c)(6) and (e).
    The additions and revisions read as follows:


Sec.  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

[[Page 68308]]

    (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

[[Page 68309]]

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

[[Page 68310]]

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.

[[Page 68311]]

    (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

[[Page 68312]]

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 Sec.  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 Sec.  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).
[FR Doc. 2016-23174 Filed 10-3-16; 8:45 am]
 BILLING CODE 4830-01-P