Credit for Increasing Research Activities, 2624-2635 [2015-00690]

Agencies

• Internal Revenue Service
• DEPARTMENT OF THE TREASURY

[Federal Register Volume 80, Number 12 (Tuesday, January 20, 2015)]
[Proposed Rules]
[Pages 2624-2635]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2015-00690]


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

DEPARTMENT OF THE TREASURY

Internal Revenue Service

26 CFR Part 1

[REG-153656-03]
RIN 1545-BC70


Credit for Increasing Research Activities

AGENCY: Internal Revenue Service (IRS), Treasury.

ACTION: Withdrawal of advance notice of proposed rulemaking; notice of 
proposed rulemaking and notice of public hearing.

-----------------------------------------------------------------------

SUMMARY: This document contains proposed regulations concerning the 
application of section 41 of the Internal Revenue Code (Code), which 
provides a credit for increasing research activities. The proposed 
regulations provide guidance on computer software that is developed by 
(or for the benefit of) the taxpayer primarily for internal use by the 
taxpayer (internal use software) under section 41(d)(4)(E). These 
proposed regulations also include examples to illustrate the 
application of the process of experimentation requirement to computer 
software under section 41(d)(1)(C). The regulations will affect 
taxpayers engaged in research activities involving computer software. 
This document also provides notice of a public hearing on these 
proposed regulations and withdraws the advance notice of proposed 
rulemaking published on January 2, 2004.

DATES: Written or electronic comments must be received by March 23, 
2015. Outlines of topics to be discussed at the public hearing 
scheduled for April 17, 2015, must be received by March 23, 2015.

ADDRESSES: Send submissions to: CC:PA:LPD:PR (REG-153656-03), room 
5205, Internal Revenue Service, P.O. Box 7604, Ben Franklin Station, 
Washington, DC 20044.
    Submissions may be hand-delivered Monday through Friday between the 
hours of 8 a.m. and 4 p.m. to: CC:PA:LPD:PR (REG-153656-03), Courier's 
Desk, Internal Revenue Service, 1111 Constitution Avenue NW., 
Washington, DC; or sent electronically via the Federal eRulemaking 
Portal at www.regulations.gov (IRS REG-153656-03). The public hearing 
will be held in IRS Auditorium, Internal Revenue Building, 1111 
Constitution Avenue NW., Washington, DC

FOR FURTHER INFORMATION CONTACT: Concerning the regulations, Martha 
Garcia, (202) 317-6853; concerning submission of comments, the hearing, 
and/or to be placed on the building access list to attend the hearing, 
call Oluwafunmilayo (Funmi) Taylor, (202) 317-6901 (not toll-free 
numbers).

SUPPLEMENTARY INFORMATION:

Background

    This document amends 26 CFR part 1 to provide rules relating to the 
credit for increasing research activities (research credit) under 
section 41 of the Code. On January 2, 1997, the Treasury Department and 
the IRS published a notice of proposed rulemaking (REG-209494-90, 
referred to in this preamble as the 1997 proposed regulations) in the 
Federal Register (62 FR 81) to provide guidance on internal use 
software under section 41(d)(4)(E). Final regulations (TD 8930, 
referred to in this preamble as the 2001 final regulations), which 
substantively modified the 1997 proposed regulations on internal use 
software, and also addressed other aspects of section 41, were 
published in the Federal Register (66 FR 280) on January 3, 2001. In 
response to taxpayer concerns regarding the 2001 final regulations, on 
January 31, 2001, Treasury and the IRS published Notice 2001-19 (2001-
10 IRB 784) (see Sec.  601.601(d)(2) of this chapter) announcing that 
Treasury and the IRS would review the 2001 final regulations and 
reconsider comments previously submitted. Notice 2001-19 also provided 
that, upon the completion of this review, Treasury and the IRS would 
announce changes to the regulations, if any, in the form of new 
proposed regulations. On December 26, 2001, the Treasury Department and 
the IRS published proposed regulations (REG-112991-01, referred to in 
this preamble as the 2001 proposed regulations) in the Federal Register 
(66 FR 66362) relating to internal use software and other aspects of 
section 41. On January 2, 2004, the Treasury Department and the IRS 
published final regulations (TD 9104, referred to in this preamble as 
the 2004 final regulations) in the Federal Register (69 FR 22) on the 
research credit. The 2004 final regulations finalized the 2001 proposed 
regulations' rules relating to the definition of qualified research 
under section 41(d), but did not finalize rules relating to internal 
use software under section 41(d)(4)(E). The 2004 final regulations 
reserve the rules for internal use software. See Sec.  1.41-4(c)(6).
    Concurrently with the 2004 final regulations, the Treasury 
Department and the IRS issued an advance notice of proposed rulemaking 
(2004 ANPRM) (published in the Federal Register (69 FR 43)). The 2004 
ANPRM invited comments from the public regarding the 2001 proposed 
regulations relating to internal use software under section 
41(d)(4)(E). The Treasury Department and the IRS specifically requested 
comments concerning the definition of internal use software. In 
addition, the Treasury Department and the IRS requested comments on 
whether final rules relating to internal use software should have 
retroactive effect. Written and electronic comments responding to the 
2004 ANPRM were received. The preamble to these proposed regulations 
describes many of the comments received by the Treasury Department and 
the IRS. Although not all of the

[[Page 2625]]

comments are addressed in this preamble, the Treasury Department and 
the IRS have reviewed and considered all written and electronic 
comments in the process of preparing these proposed regulations.

General Overview

    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). Software that is developed for 
use in an activity that constitutes qualified research and software 
that is developed for use in a production process with respect to which 
the general credit eligibility requirements are satisfied are not 
excluded as internal use software under section 41(d)(4)(E).

Legislative History

    The legislative history of the Tax Reform Act of 1986, Public Law 
99-514 (100 Stat. 2085 (1986)) (1986 Act), states that ``the costs of 
developing software are not eligible for the credit where the software 
is used internally, for example, in general and administrative 
functions (such as payroll, bookkeeping, or personnel management) or in 
providing noncomputer services (such as accounting, consulting, or 
banking services) except to the extent permitted by Treasury 
regulations.'' See H.R. Conf. Rep. No. 841, at II-73 (1986 legislative 
history). The 1986 legislative history further states that Congress 
intended that regulations would make the costs of new or improved 
internal use software eligible for the credit only if the research 
satisfies, in addition to the general requirements for credit 
eligibility, an additional three-part high threshold of innovation test 
(that is, that the software is innovative, that the software 
development involves significant economic risk, and that the software 
is not commercially available for use by the taxpayer).
    Congress extended the research credit a number of times since the 
1986 Act, but has not made any changes to the statutory definition of 
qualified research or to the statutory exclusion from that definition 
for internal use software in section 41(d)(4)(E). When Congress 
extended the research credit in the Tax Relief Extension Act of 1999, 
(Pub. L. 106-170, 113 Stat. 1860 (1999)), however, the legislative 
history stated the following with respect to internal use software:

    The conferees further note the rapid pace of technological 
advance, especially in service-related industries, and urge the 
Secretary to consider carefully the comments he has and may receive 
in promulgating regulations in connection with what constitutes 
``internal use'' with regard to software expenditures. The conferees 
also wish to observe that software research, that otherwise 
satisfies the requirements of section 41, which is undertaken to 
support the provision of a service, should not be deemed ``internal 
use'' solely because the business component involves the provision 
of a service.

    H.R. Conf. Rep. No. 106-478, at 132 (1999).
Prior Regulations
    As discussed in the 2004 ANPRM, prior regulatory guidance generally 
reflects three approaches to the definition of internal use software. 
The 1997 proposed regulations closely followed the language contained 
in the 1986 legislative history and required an evaluation of ``all 
relevant facts and circumstances'' to determine whether software was 
primarily for internal use. The 1997 proposed regulations referenced 
the 1986 legislative history's identification of software used in 
general and administrative functions or used in providing noncomputer 
services as generally not eligible for the research credit. The 1997 
proposed regulations also incorporated the legislative history's three-
part high threshold of innovation test. The 2001 final regulations 
provided greater specificity than the 1997 proposed regulations 
regarding the definition of internal use software by distinguishing 
between computer services and noncomputer services and providing a rule 
that the development of internal use software used to deliver 
noncomputer services to customers with new features that are not yet 
offered by a taxpayer's competitors is deemed to satisfy the three-part 
high threshold of innovation test. The 2001 final regulations continued 
to provide a general definition of internal use software that 
incorporated the 1986 legislative history's examples of general and 
administrative functions and noncomputer services, but modified the 
application of the three-part high threshold of innovation test to 
require a comparison of ``the intended result with software that is 
within the common knowledge of skilled professionals'' to determine if 
internal use software is innovative or the development involves 
significant economic risk. Finally, the 2001 proposed regulations 
continued to distinguish between software that provides computer 
services and software that provides noncomputer services, but did not 
include the rule provided in the 2001 final regulations that the 
development of internal use software used to deliver noncomputer 
services to customers with new features that are not yet offered by a 
taxpayer's competitors was deemed to satisfy the three-part high 
threshold of innovation test. Instead, the 2001 proposed regulations 
departed from the language used in the 1986 legislative history and 
provided a bright-line presumption that software is developed primarily 
for internal use unless the software is developed to be commercially 
sold, leased, licensed, or otherwise marketed for separately stated 
consideration to unrelated third parties. The 2001 proposed regulations 
also modified the innovation component of the three-part high threshold 
of innovation test to state that software is innovative if intended to 
be unique or novel and differ in a significant and inventive way from 
prior software implementations or methods.

Summary of Comments and Explanation of Provisions

In General

    These proposed regulations provide a definition of software 
developed primarily for internal use and describe software not 
developed primarily for internal use. These proposed regulations also 
provide that certain internal use software is eligible for the research 
credit if the software satisfies the high threshold of innovation test. 
These proposed regulations provide rules for computer software that is 
developed for both internal use and non-internal use (dual function 
computer software), including a safe harbor for determining if any of 
the expenditures with respect to dual function computer software are 
qualified research expenditures. These proposed regulations include 
examples to illustrate application of the proposed regulations for 
internal use software. Finally, these proposed regulations include 
examples under Sec.  1.41-4 to illustrate the application of the 
process of experimentation requirement to computer software under 
section 41(d)(1)(C).

Definition of Internal Use Software

    The 2004 ANPRM requested comments concerning an appropriate 
definition of internal use software that reflects the statute and 
legislative intent, can be readily applied by taxpayers and readily 
administered by the IRS, and is flexible enough to provide continuing 
application into the future. In submitting comments, commenters were 
invited to address any of the definitions included in prior guidance as 
well as other definitions that have been proposed to the Treasury 
Department and the IRS.

[[Page 2626]]

    Commenters suggested that the definition of internal use software 
should closely follow the general and administrative examples from the 
1986 legislative history. Commenters stated that characterizing 
services provided to customers as ``computer'' or ``noncomputer'' will 
result in disparate treatment. Commenters recommended that the 
definition should be based on the function provided by the software and 
not the overall nature of the end product or service provided to third 
parties. Commenters noted that a facts and circumstances functionality 
rule may be more difficult to administer, but it is preferable to a 
bright-line separately stated consideration rule. In addition, 
commenters asserted that today's highly integrated nature of software 
development will not prevent taxpayers from being able to separate 
software development into functions.
    Although the 1986 legislative history indicates that Congress 
intended internal use software to include software used in noncomputer 
services, the 1999 legislative history requests that Treasury note the 
rapid pace of technological advance, especially in service-related 
industries, when providing rules for internal use software. The role 
that computer software plays in business activities is very different 
today than it was when the exclusion for internal use software was 
enacted in 1986. Today, computer software is used in all aspects of 
business activity, especially in providing goods and services to third 
parties, and such software has played a vital role in increasing the 
productivity of the U.S. economy and in making the U.S. more 
competitive globally.
    Accordingly, these proposed regulations provide 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. Similarly, 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). 
Furthermore, these proposed regulations eliminate the distinction 
between software developed to deliver computer and noncomputer 
services.
    Under these proposed regulations, general and administrative 
functions are limited to financial management functions, human resource 
management functions, and 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.
    This list of functions that constitute general and administrative 
functions is intended to target the back-office functions of a taxpayer 
that most taxpayers would have regardless of the taxpayer's industry. 
The benefits of software developed by the taxpayer for use in general 
and administrative functions are likely to be captured only by the 
taxpayer developing it and therefore exclusion from credit eligibility 
is more consistent with the purposes for which Congress created the 
credit. However, the characterization of a function as back-office may 
depend upon the taxpayer's industry. For example, tax software in the 
tax services industry is not used by the taxpayer in a general and 
administrative function, but for taxpayers that do not provide tax 
services, tax software is used by the taxpayer in a general and 
administrative function.

Non-Internal Use Software

    Some commenters, addressing the 2001 proposed regulations' 
definition of internal use software, suggested that software that is 
not developed to be commercially sold, leased, licensed, or otherwise 
marketed for separately stated consideration should not be presumed to 
be internal use software. Some commenters also questioned whether the 
exception for software developed to be commercially sold, leased, or 
licensed is appropriate given the purposes of the research credit. 
These commenters suggested that such criteria may not further the 
purposes of the statute because whether software is held for sale may 
not be indicative of the software's function. These proposed 
regulations do not contain a presumption for software that is not 
developed to be commercially sold, leased, licensed, or otherwise 
marketed for separately stated consideration, but they do treat 
software that is developed to be commercially sold, leased, licensed, 
or otherwise marketed as software not developed primarily for internal 
use.
    The Treasury Department and the IRS have determined that the 
purpose of the software's development can be indicative of the 
software's function. In this way, the inquiry of whether software is 
developed for commercial sale, lease, or license looks to the purpose 
of the software and serves as an additional test separate from a pure 
functionality test. This approach to identifying software not developed 
primarily for internal use furthers the underlying purpose of the 
statute because the benefits from software held for commercial sale, 
lease, or license are likely to be captured by persons other than the 
taxpayer developing the software. Accordingly, it should be eligible 
for the research credit provided the other requirements of section 41 
are met. Similarly, software that enables a taxpayer to interact with 
third parties or allows third parties to initiate functions or review 
data on the taxpayer's system does not solely benefit the taxpayer 
developing the software, and therefore it is appropriate to exclude 
such software from the definition of internal use software.
    Accordingly, these proposed regulations provide that software is 
not developed primarily for internal use 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. Examples of software developed to enable 
a taxpayer to interact with third parties or to allow third parties to 
initiate functions or review data include software developed for third 
parties to execute banking transactions, track the progress of a 
delivery of goods, search a taxpayer's inventory for goods, store and 
retrieve a third party's digital files, purchase tickets for 
transportation or entertainment, and receive services over the 
internet. For purposes of these rules, third parties do not include any 
persons that use the software to support a taxpayer's general and 
administrative functions that facilitate or support the conduct of the 
taxpayer's trade or business.
    Whether software 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, the improvements will be 
considered separate from the existing software and will not be 
considered to be 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

[[Page 2627]]

third parties to initiate functions or review data, but later makes 
improvements to the software with the intent to use the software in 
general and administrative functions, the improvements will be 
considered developed primarily for internal use. Any improvements to 
the existing software will be considered separate from the existing 
software and the application of the internal use software rules will be 
made solely to the improvements to the software. Additionally, software 
that is intended to be developed for commercial sale, lease, or license 
will not be considered internal use merely because the taxpayer tests 
the software by using it internally.

Dual Function Computer Software

    The Treasury Department and the IRS recognize the need to provide 
guidance on whether computer software is developed ``primarily'' for 
internal use if a taxpayer develops software that serves both general 
and administrative and non-general and administrative functions. These 
proposed regulations balance administrative and compliance concerns 
with the need to provide substantive rules appropriate to the purposes 
of the research credit. To further these objectives, the proposed 
regulations provide that dual function computer 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 computer software that only 
enables a taxpayer to interact with third parties or to allow third 
parties to initiate functions or review data (third party subset). The 
proposed regulations provide that if the taxpayer can identify the 
third party subset, the portion of research expenditures allocable to a 
third party subset of the dual function computer software may be 
eligible for the research credit, provided all the other applicable 
requirements are met.
    Moreover, the proposed regulations provide taxpayers with a safe 
harbor to apply to dual function computer software if a third party 
subset cannot be identified or to the remaining subset of dual function 
computer software after the third party subset has been identified 
(dual function subset). 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. The proposed regulations provide that taxpayers 
must use an objective, reasonable method to estimate the computer 
software's use by third parties or by the taxpayer to interact with 
third parties and such use of the dual function computer software is 
estimated at the beginning of software development. The proposed 
regulations contain a facts and circumstances approach to determine a 
taxpayer's intent at the beginning of computer software development and 
provide several examples illustrating these rules. In the Request for 
Public Comments section of this preamble, the Treasury Department and 
the IRS request comments on the administrability of certain objective, 
reasonable methods of measuring third parties' reasonably anticipated 
use as well as other appropriate, objective standards that can be used 
to measure third parties' reasonably anticipated use.

Computer Software and Hardware Developed as a Single Product

    Based upon the 1986 legislative history, these proposed regulations 
retain the exception for computer software and hardware developed as a 
single product and provide that internal use software does not include 
a new or improved package of computer software and hardware developed 
together by the taxpayer as a single product that is used directly by 
the taxpayer in providing services in the taxpayer's trade or business. 
These proposed regulations provide an example illustrating this rule.

Computer Software as Part of a Production Process

    Several commenters asserted that computer software supporting the 
delivery of goods or services to third parties is not internal use 
software because the software is part of a production process within 
the meaning of section 41(d)(4)(E)(ii). Thus, for example, computer 
software that is used to track a taxpayer's inventory of goods would 
not be internal use software because the tracking of inventory supports 
the taxpayer's ability to deliver goods to third parties, which is a 
final step in the taxpayer's production process.
    The Treasury Department and the IRS do not agree that computer 
software supporting the delivery of goods or services to third parties 
is part of a production process within the meaning of section 
41(d)(4)(E)(ii). To the contrary, the delivery of goods and services to 
third parties is a post-production activity. Nonetheless, under rules 
provided in these proposed regulations and described previously in this 
preamble, computer software supporting the delivery of goods or 
services to third parties may not be within the definition of software 
developed primarily for internal use to the extent that the software 
enables a taxpayer to interact with third parties or allows third 
parties to initiate functions or review data.

High Threshold of Innovation

    The high threshold of innovation test is derived from the 
legislative history of section 41(d)(4)(E). The Conference Report 
states:

    The conferees intend that these regulations will make the costs 
of new or improved internal-use software eligible for the credit 
only if the taxpayer can establish, in addition to satisfying the 
general requirements for credit eligibility, (1) that the software 
is innovative (as where the software results in a reduction in cost, 
or improvement in speed, that is substantial and economically 
significant); (2) that the software development involves significant 
economic risk (as where the taxpayer commits substantial resources 
to the development and also there is substantial uncertainty, 
because of technical risk, that such resources would be recovered 
within a reasonable period); and (3) that the software is not 
commercially available for use by the taxpayer (as where the 
software cannot be purchased, leased, or licensed and used for the 
intended purpose without modifications that would satisfy the first 
two requirements just stated).

    See H.R. Conf. Rep. No. 841, at II-73.
    Prior guidance reflects the 1986 legislative history by requiring 
that, in addition to satisfying the general requirements for the 
research credit, internal use software must meet the high threshold of 
innovation test to qualify for the credit. The high threshold of 
innovation test, described in this section of the preamble, is intended 
to limit credit eligibility of software developed primarily for 
internal use to software development that meets a higher standard than 
other business components. At the same time, it is clear that Congress 
intended that some software developed primarily for internal use would 
meet the high threshold of innovation test. Accordingly, the 
requirements should not be so restrictive as to make the test 
impossible to meet. The proposed regulations provide rules of 
application with respect to the high threshold of innovation test that 
reflect this purpose.

Innovation

    The 1986 legislative history requires that the software result in a 
reduction in

[[Page 2628]]

cost or improvement in speed that is substantial and economically 
significant. The 1997 proposed regulations contained an objective 
definition consistent with the 1986 legislative history. The 2001 final 
regulations modified the application of the innovation component of the 
high threshold of innovation test to require a comparison of ``the 
intended result with software that is within the common knowledge of 
skilled professionals.'' As described previously in this preamble, the 
2001 proposed regulations proposed a new definition of innovation that 
departed from the 1986 legislative history in that it required that the 
taxpayer intended the software to be unique or novel and that the 
taxpayer intended it to differ in a significant and inventive way from 
prior software implementations or methods. Most commenters requested 
that the definition reflect the more mechanical and quantitative 
approach in the 1986 legislative history and the 1997 proposed 
regulations.
    Consistent with the 1986 legislative history, these proposed 
regulations provide that 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. The 
innovativeness test does not require that the software development 
actually be successful, but assuming the software development would 
have been successful, the test requires that it would have resulted in 
such an improvement. This approach is measurable and objective, and 
should reduce the potential for controversy.

Significant Economic Risk

    These proposed regulations, consistent with the 1986 legislative 
history, require that the software development involve significant 
economic risk, which exists if the taxpayer commits substantial 
resources to the development and there is substantial uncertainty, 
because of technical risk, that such resources would be recovered 
within a reasonable period. These proposed regulations do not 
incorporate the ``common knowledge of skilled professionals'' 
comparative assessment of uncertainty and technical risk that was 
adopted in the 2001 final regulations. As provided in these proposed 
regulations, the significant economic risk test is applied to the level 
of uncertainty involved at the outset of the development rather than 
the degree of innovation represented by the end result.
    Section 1.41-4(a)(3) of the current regulations, which establishes 
the criteria for establishing whether research is undertaken for the 
purpose of discovering information, provides that ``uncertainty exists 
if the information available to the taxpayer does not establish the 
capability or method for developing or improving the business component 
or the appropriate design of the business component.'' Under Sec.  
1.41-4(a)(3), uncertainty must relate to the capability or method for 
developing or improving the business component, or the appropriate 
design of the business component. For purposes of defining 
``substantial uncertainty'' to determine if there is significant 
economic risk with respect to the high threshold of innovation test, 
the use of the word ``substantial'' indicates a higher threshold of 
uncertainty than that required for business components that are not 
internal use software.
    Therefore, these proposed regulations provide 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. Internal 
use software research activities that involve only uncertainty related 
to appropriate design, and not capability or methodology, do not 
qualify as having substantial uncertainty for purposes of the high 
threshold of innovation test. The requirement that the uncertainty 
relate to the capability or method, but not the appropriate design of 
the business component creates the higher threshold for eligibility 
that Congress intended for certain internal use software, while 
creating a logical relationship with the general requirements under 
Sec.  1.41-4(a)(3). Additionally, the reference to known, previously 
defined terms reduces potential controversy arising from the use of new 
undefined terms.
    There has been some controversy regarding whether the significant 
economic risk test concerns technical risk or economic risk. The 
Treasury Department and the IRS interpret the significant economic risk 
test to require both technical and economic risk. It requires technical 
risk because there must be uncertainty that is technological in nature, 
as defined in Sec.  1.41-4(a)(4) of the current regulations. However, 
it also requires economic risk because the taxpayer must devote 
substantial resources to the development and, by virtue of the 
technical risk, there must be uncertainty regarding whether the final 
result can be achieved within a timeframe that will allow those 
resources to be recovered within a reasonable period.

Commercially Available for Use

    The proposed regulations reflect the 1986 legislative history and 
are consistent with all prior regulations regarding the commercially 
available for use standard. The proposed regulations provide that 
internal use software may only satisfy the high threshold of innovation 
standard if 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 innovation and significant economic risk requirements.

Addition of Process of Experimentation Examples for Computer Software

    The 2004 final regulations provide that experimentation with 
respect to technological uncertainty qualifies as a process of 
experimentation under section 41(d)(1)(C). However, none of the 
examples in the 2004 final regulations involved the development of 
computer software. These proposed regulations provide examples of how 
the process of experimentation test is applied to computer software. 
The examples also illustrate that certain types of web design and the 
installation of enterprise resource planning software generally do not 
qualify as a process of experimentation under the 2004 final 
regulations. Additionally, these proposed regulations illustrate 
computer software development that does qualify as a process of 
experimentation, and in particular, software development in which the 
taxpayer has technological uncertainty regarding the appropriate 
design.

Comments and Public Hearing

    Comments are requested on all aspects of these proposed 
regulations. Specifically, the Treasury Department and the IRS invite 
comments that provide information on:
    1. 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,
    2. For purposes of the dual function computer software safe harbor, 
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

[[Page 2629]]

software user interface screens, and number of third party initiated 
functions, as well as other objective, reasonable methods to measure 
the dual function computer software's reasonably anticipated use by 
taxpayers to interact with third parties and by third parties to 
initiate functions or review data, and whether the regulations should 
include specific reasonable methods and examples, and
    3. Facts and circumstances, other than those factors enumerated in 
the legislative history, to be considered in determining whether 
internal use software satisfies the three prongs of the high threshold 
of innovation test.

Proposed Effective/Applicability Date

    The Treasury Department and the IRS requested comments in the 2004 
ANPRM on whether final regulations relating to internal use software 
should be effective retroactively. Some commenters requested that the 
rules apply retroactively back to 1986, while other commenters 
requested that the regulations be prospective only. After careful 
consideration, and in light of the length of time that has passed since 
1986, as well as the developments with respect to computer software, 
the Treasury Department and the IRS have decided that these proposed 
regulations, once finalized, will be prospective only. The rules 
contained in these regulations are proposed to apply to taxable years 
ending on or after the date of publication of the Treasury decision 
adopting these rules as final regulations in the Federal Register. 
Notwithstanding the prospective effective date, the IRS will not 
challenge return positions consistent with these proposed regulations 
for taxable years ending on or after the date these proposed 
regulations are published.
    The rules in these proposed regulations are not, and should not be 
viewed as, an interpretation of prior regulatory guidance or of the 
1986 legislative history. For example, software not developed for 
internal use under these proposed 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.

Withdrawal of the 2004 ANPRM

    The 2004 ANPRM provides that with respect to internal use software 
for taxable years beginning after December 31, 1985, and until further 
guidance is published, taxpayers may continue to rely upon all of the 
provisions in the 2001 proposed regulations, or alternatively, all of 
the provisions in the 2001 final regulations. As a consequence of the 
publication of these proposed regulations, and to provide guidance with 
respect to the application of internal use software rules contained in 
regulations issued prior to these proposed regulations, the Treasury 
Department and the IRS withdraw the 2004 ANPRM effective for taxable 
years beginning on or after the date of issuance of these proposed 
regulations. For taxable years ending before the date these proposed 
regulations are published in the Federal Register, taxpayers may choose 
to follow either all of the internal use software provisions of Sec.  
1.41-4(c)(6) in the 2001 final regulations or all of the internal use 
software provisions of Sec.  1.41-4(c)(6) in the 2001 proposed 
regulations.

Special Analyses

    It has been determined that this notice of proposed rulemaking is 
not a significant regulatory action as defined in Executive Order 
12866, as supplemented by Executive Order 13563. Therefore, a 
regulatory assessment is not required. Additionally, this notice of 
proposed rulemaking does not impose a collection of information.
    An initial regulatory flexibility analysis has been prepared for 
this notice of proposed rulemaking under 5 U.S.C. 603. The analysis is 
set forth under the heading ``Initial Regulatory Flexibility 
Analysis.'' Pursuant to section 7805(f) of the Code, this notice of 
proposed rulemaking has been submitted to the Chief Counsel for 
Advocacy of the Small Business Administration for comment on its impact 
on small business.

Initial Regulatory Flexibility Analysis

    These proposed regulations affect taxpayers engaged in research 
activities involving computer software. The reasons for promulgation of 
these regulations, and their legal basis, are set forth in this 
preamble under the heading ``Summary of Comments and Explanation of 
Provisions.'' 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 objective of these proposed 
regulations is to provide a narrower exclusion of software from 
qualified research than provided in prior regulatory guidance.
    The types of small entities to which these regulations may apply 
are small corporations and partnerships, and other small businesses, 
covering all areas of industry. Therefore, the Treasury Department and 
the IRS have determined that these proposed regulations will have an 
impact on a substantial number of small entities. Because these 
proposed regulations provide a narrower definition of internal use 
software, the research credit will be available to a greater number of 
small entities than was previously available under prior guidance. 
Therefore, the Treasury Department and the IRS have determined that 
these proposed regulations will have a positive economic impact on a 
substantial number of small entities.
    These proposed regulations do not impose any additional reporting, 
recordkeeping, or other compliance requirements aside from the record 
keeping requirements under Sec.  1.6001-1 that are generally applicable 
to all persons subject to tax. Section 1.6001-1 requires the keeping of 
records ``sufficient to establish the amount of * * * credits * * * 
required to be shown * * * in any return of such tax * * *.'' The 
Treasury Department and the IRS determined that the rules generally 
applicable under section 6001 provide sufficient detail about required 
documentary substantiation for purposes of the research credit, and 
thus no additional record keeping or reporting is required.
    Comments are requested on the nature and extent of the economic 
burden imposed on small entities by these proposed regulations and on 
alternatives that would be less burdensome to small entities.
    The Treasury Department and the IRS are not aware of any 
duplicative, overlapping, or conflicting federal rules.

Comments and Public Hearing

    Before these proposed regulations are adopted as final regulations, 
consideration will be given to any written comments (a signed original 
and eight (8) copies) or electronic comments that are submitted timely 
to the IRS. Comments are requested on all aspects of these proposed 
regulations. All comments will be available at www.regulations.gov for 
public inspection and copying.
    A public hearing has been scheduled for April 17, 2015, beginning 
at 10 a.m. in the IRS Auditorium, Internal Revenue Building, 1111 
Constitution Avenue NW., Washington DC. Due to building security 
procedures, visitors must enter at the Constitution Avenue entrance. In 
addition, all visitors must present photo identification to enter the 
building. Because of access restrictions, visitors will not be admitted 
beyond the immediate entrance area more than 30

[[Page 2630]]

minutes before the hearing starts. For information about having your 
name placed on the building access list to attend the hearing, see the 
FOR FURTHER INFORMATION CONTACT section of this preamble.
    The rules of 26 CFR 601.601(a)(3) apply to the hearing. Persons who 
wish to present oral comments at the hearing must submit electronic or 
written comments and an outline of the topics to be discussed and the 
time to be devoted to each topic (a signed original and eight (8) 
copies) by March 23, 2015. A period of 10 minutes will be allotted to 
each person for making comments. An agenda showing the scheduling of 
the speakers will be prepared after the deadline for receiving outlines 
has passed. Copies of the agenda will be available free of charge at 
the hearing.

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.

Withdrawal of Advance Notice of Proposed Rulemaking

    Accordingly, under the authority of 26 U.S.C. 7805, the advance 
notice of proposed rulemaking that was published in the Federal 
Register on January 2, 2004 (69 FR 43) is withdrawn.

Proposed Amendments to the Regulations

    Accordingly, 26 CFR part 1 is proposed to be amended as follows:

PART 1--INCOME TAXES

0
Paragraph 1. The authority citation for part 1 is amended by adding 
entries in numerical order to read 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-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 could 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

[[Page 2631]]

systematic trial and error testing of several newly designed data 
caching algorithms to eliminate synchronization problems.
    (ii) Conclusion. Substantially all of X's activities of 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 computer 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 software satisfies the requirements of section 41(d)(1);
    (B) The software is not otherwise excluded under section 41(d)(4) 
(other than section 41(d)(4)(E)); and
    (C) One of the following conditions is met--
    (1) The taxpayer develops the software for use in an activity that 
constitutes qualified research (other than the development of the 
internal use software itself);
    (2) The taxpayer develops the software for use in a production 
process to which the requirements of section 41(d)(1) are met; or
    (3) The software satisfies the high threshold of innovation test of 
paragraph (c)(6)(v) of this section.
    (ii) Computer software and hardware developed as a single product. 
This paragraph (c)(6) does not apply to the development costs of a new 
or improved package of computer software and hardware developed 
together by the taxpayer as a single product (or to the costs to modify 
an acquired computer 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. Computer 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--(A) In 
general. Computer software is not developed primarily for the 
taxpayer's internal use if either--
    (1) The software is developed to be commercially sold, leased, 
licensed, or otherwise marketed to third parties; or
    (2) The software 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.
    (B) Time and manner of determination. For purposes of paragraph 
(c)(6)(iv)(A) of this section, whether software is developed to be 
commercially sold, leased, or licensed, or to enable a taxpayer to 
interact with third parties or to allow third parties to initiate 
functions or review data depends on the intent of the taxpayer and the 
facts and circumstances at the beginning of the software development. 
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 for commercial sale, lease, or 
license, or to allow third parties to initiate functions or review data 
using the improved software, the improvements will be considered 
separate from the existing software and will not be considered internal 
use. Alternatively, 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, 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.
    (C) Computer software developed for both internal use and to enable 
interaction with third parties--(1) Presumption of development 
primarily for internal use. Unless paragraph (c)(6)(iv)(C)(2) or (3) of 
this section applies, computer 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 computer software) is presumed to be developed primarily 
for a taxpayer's internal use.
    (2) Identification of a subset of elements of computer software 
that only enables interaction with third parties. To the extent that a 
taxpayer can identify a subset of elements of dual function computer 
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)(iv)(C)(1) of this 
section

[[Page 2632]]

does not apply to such third party subset, and such third party subset 
is not developed primarily for internal use under paragraph 
(c)(6)(iv)(A)(2).
    (3) Safe harbor for expenditures related to computer software 
developed for both internal use and to enable interaction with third 
parties. If, after the application of paragraph (c)(6)(iv)(C)(2) of 
this section, there remains a subset of elements of dual function 
computer software (dual function subset), a taxpayer may include 25 
percent of the qualified research expenditures of such dual function 
subset in computing the amount of the taxpayer's credit. This paragraph 
(c)(6)(iv)(C)(3) applies only if the taxpayer's research activities 
related to the development or improvement of the dual function computer 
software constitute qualified research under section 41(d), without 
regard to section 41(d)(4)(E), and the dual function subset's use by 
third parties or by the taxpayer to interact with third parties is 
reasonably anticipated to constitute at least 10 percent of the dual 
function subset's use. An objective, reasonable method must be used to 
estimate the dual function subset's use by third parties or by the 
taxpayer to interact with third parties and such use is estimated at 
the beginning of the computer software development.
    (4) Illustration. The following examples illustrate provisions 
contained in this paragraph (c)(6)(iv)(C):
    Example 1. Dual function computer software; identification of a 
third party subset--(i) Facts. Taxpayer develops computer software 
that Taxpayer uses in general and administrative functions that 
facilitate or support the conduct of Taxpayer's trade or business 
and that allows third parties to initiate functions. Taxpayer is 
able to identify the third party subset. Taxpayer incurs $50,000 of 
research expenditures for the computer software, 50% of which is 
allocable to the third party subset.
    (ii) Conclusion. The computer software developed by Taxpayer is 
dual function computer software. Because Taxpayer is able to 
identify the third party subset, such third party subset is not 
presumed to be internal use software under paragraph 
(c)(6)(iv)(C)(1) of this section. If Taxpayer'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), the $25,000 of the 
computer software research expenditures allocable to the third party 
subset may be included in computing the amount of Taxpayer's credit, 
pursuant to paragraph (c)(6)(iv)(C)(2) of this section. If, after 
the application of paragraph (c)(6)(iv)(C)(2) of this section, there 
remains a dual function subset, the Taxpayer may determine whether 
paragraph (c)(6)(iv)(C)(3) of this section applies.
    Example 2. Dual function computer software; application of the 
safe harbor--(i) Facts. The facts are the same as in Example 1, 
except that Taxpayer is unable to identify a third party subset. 
Taxpayer uses an objective, reasonable method at the beginning of 
the computer software development to determine that the dual 
function computer software's use by third parties to initiate 
functions is reasonably anticipated to constitute 75% of the dual 
function computer software's use.
    (ii) Conclusion. The computer software developed by Taxpayer is 
dual function computer software. The computer software is presumed 
to be developed primarily for internal use under paragraph 
(c)(6)(iv)(C)(1) of this section. Although Taxpayer is unable to 
identify a third party subset, Taxpayer reasonably anticipates that 
the dual function computer software's use by third parties is at 
least 10% of the dual function computer software's use. If 
Taxpayer's research activities related to the development or 
improvement of the dual function computer 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), Taxpayer may include $12,500 of 
the computer software research expenditures of the dual function 
computer software in computing the amount of Taxpayer's credit 
pursuant to paragraph (c)(6)(iv)(C)(3) of this section.
    Example 3. Dual function computer software; safe harbor 
inapplicable--(i) Facts. The facts are the same as in Example 1, 
except Taxpayer is unable to identify a third party subset. Taxpayer 
uses an objective, reasonable method at the beginning of the 
computer software development to determine that the dual function 
computer software's use by third parties to initiate functions is 
reasonably anticipated to constitute 5% of the dual function 
computer software's use.
    (ii) Conclusion. The computer software developed by Taxpayer is 
dual function computer software. The computer software is presumed 
to be developed primarily for Taxpayer's internal use under 
paragraph (c)(6)(iv)(C)(1) of this section because Taxpayer is 
unable to identify a third party subset, and Taxpayer reasonably 
anticipates that the dual function computer software's use by third 
parties is less than 10% of the dual function computer software's 
use. Taxpayer may not include any of the computer software research 
expenditures of the dual function computer software in computing the 
amount of Taxpayer's credit unless Taxpayer's research activities 
related to the dual function computer software meet the requirements 
of paragraph (c)(6)(i) of this section.
    Example 4. Dual function computer software; identification of a 
third party subset and the safe harbor--(i) Facts. Taxpayer develops 
computer software that Taxpayer uses in general and administrative 
functions that facilitate or support the conduct of Taxpayer's trade 
or business and that allows third parties to initiate functions and 
review data. Taxpayer is able to identify a third party subset 
(Subset A). The remaining dual function subset of the computer 
software (Subset B) allows third parties to review data and provides 
Taxpayer with data used in its general and administrative functions. 
Taxpayer is unable to identify a third party subset of Subset B. 
Taxpayer incurs $50,000 of research expenditures for the computer 
software, 50% of which is allocable to Subset A and 50% of which is 
allocable to Subset B. Taxpayer uses an objective reasonable method 
at the beginning of the computer software development to determine 
that the third party use of Subset B is reasonably anticipated to 
account for 50% of the use of Subset B.
    (ii) Conclusion. The computer software developed by Taxpayer is 
dual function computer software. Because Taxpayer 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)(iv)(C)(1) of this section. If Taxpayer'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 computer software research expenditures 
allocable to Subset A may be included in computing the amount of 
Taxpayer's credit pursuant to paragraph (c)(6)(iv)(C)(2) of this 
section. Although Taxpayer is unable to identify a third party 
subset of Subset B, 50% of Subset B's use is reasonably anticipated 
to be attributable to the use of Subset B by third parties. If 
Taxpayer'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), 
Taxpayer may include $6,250 (25% x $25,000) of the computer software 
research expenditures of Subset B in computing the amount of 
Taxpayer's credit, pursuant to paragraph (c)(6)(iv)(C)(3) of this 
section.

    (D) Third party. For purposes of paragraph (c)(6)(iv) 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)(A)(2) of this section, third parties do not 
include any persons that use the software to support the general and 
administrative functions of the taxpayer.
    (v) High threshold of innovation test--(A) In general. Computer 
software satisfies this paragraph (c)(6)(v) 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)(v)(A)(1) and (2) of this 
section.

[[Page 2633]]

    (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. 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. 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. Technical risk arises from 
uncertainty that is technological in nature, as defined in Sec.  1.41-
4(a)(4).
    (D) Application of high threshold of innovation test. The high 
threshold of innovation test of this paragraph (c)(6)(v) of this 
section takes into account only the results attributable to the 
development of new or improved software independent of the effect of 
any modifications to related hardware or other software. It 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. Although the implementation of existing technology, no matter how 
complex, is not evidence, by itself, of innovation, the use of existing 
technologies in new ways could be evidence of a high threshold of 
innovation if it resolves substantial uncertainty as defined in 
paragraph (c)(6)(v)(C) of this section.
    (vi) 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. 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 sale. The software does not enable X to interact with 
third parties or allow third parties to initiate functions or review 
data.
    (ii) Conclusion. The software is developed primarily 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 primarily for use in a general and 
administrative function.
    Example 2. 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 sale. The 
software module does not enable X to interact with third parties or 
allow third parties to initiate functions or review data.
    (ii) Conclusion. The employee access software module is 
developed primarily 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 primarily for use in a general and administrative 
function.
    Example 3. Internal use software; support services--(i) Facts. 
X, a restaurant, develops software for a Web site that provides 
general information about the restaurant such as items served, 
price, location, phone number, and hours of operation. At the 
beginning of the development, X does not intend to develop the Web 
site software for sale. The software does not enable X to interact 
with third parties or allow third parties to initiate functions or 
review data.
    (ii) Conclusion. The software is developed primarily 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 primarily for use in a general and administrative 
function.
    Example 4. Not internal use software--(i) Facts. X, a 
manufacturer of various products, develops software for a Web site 
that allows third parties 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 sale.
    (ii) Conclusion. The software is not developed primarily for 
internal use because the software allows third parties to initiate 
functions or review data as provided under paragraph 
(c)(6)(iv)(A)(2) of this section.
    Example 5. Internal use software; third party interaction 
exclusion--(i) Facts. X develops software to interact electronically 
with its vendors to improve X's inventory management. The software 
enables X to interact with vendors and to allow vendors to initiate 
functions or review data. 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 sale.
    (ii) Conclusion. Under paragraph (c)(6)(iv)(D) of this section, 
X's vendors are not third parties for purposes of paragraph 
(c)(6)(iv)(A) of this section. While X's software allows vendors to 
initiate functions or review data, the software is not excluded from 
internal use software as set forth in paragraph (c)(6)(iv)(A)(2) of 
this section because vendors use the software to support X's 
inventory management which is a general and administrative function 
of X.
    Example 6. Internal use software; third party interaction 
exclusion--(i) Facts. X is a popular web destination that offers 
various free services to users. 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 
services 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 development, X 
does not intend to develop either software for sale.
    (ii) Conclusion. The users of free services and the advertisers 
are third parties for purposes of paragraph (c)(6)(iv)(A) of this 
section. Both the software for uploading and modifying photographs 
and the advertising software are excluded from internal use software 
under paragraph (c)(6)(iv)(A)(2) of this section, because the 
software allows third parties to initiate functions.
    Example 7. Internal use software--(i) Facts. X, a multinational 
manufacturer with different business and financial systems in each 
of its divisions, undertakes a software development project aimed at 
integrating the majority of the functional areas of its major 
software systems (Existing Software) into a single enterprise 
resource management system supporting centralized financial systems, 
human resources, inventory, and sales. X purchases software (New 
Software) upon which to base its enterprise-wide system. X has to 
develop software (Developed Software) that transfers data from X's 
legacy financial, human resources, inventory, and sales systems to 
the New Software. At the beginning of the development, X does not 
intend to develop the software for sale. The software does not 
enable X to interact with third parties or allow third parties to 
initiate functions or review data.
    (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

[[Page 2634]]

Software is internal use software because it is developed primarily 
for use in general and administrative functions.
    Example 8. 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, such 
as the ability 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 computer 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, and eligibility for the 
research credit is determined by examining the combined software-
hardware product as a single product.
    Example 9. 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 sale. The 
software does not enable X to interact with third parties or allow 
third parties to initiate functions or review data. 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 primarily for use in general and administrative 
functions. However, the improvements to the software are not 
developed primarily for internal use because the improved software 
was developed to be commercially sold, leased, licensed, or 
otherwise marketed to third parties under paragraph (c)(6)(iv)(A)(1) 
and (c)(6)(iv)(B) of this section.
    Example 10. 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 was uncertain 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 sale. The software did not enable X to 
interact with third parties or allow third parties to initiate 
functions or review data.
    (ii) Conclusion. The software is internal use software because 
it is developed primarily for use in a general and administrative 
function. However, the software satisfies the high threshold of 
innovation test set forth in paragraph (c)(6)(v) 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 11. 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 sale. The 
software does not enable X to interact with third parties or allow 
third parties to initiate functions or review data.
    (ii) Conclusion. The software is internal use software because 
it is developed primarily for use in a general and administrative 
function. X's activities do not satisfy the high threshold of 
innovation test of paragraph (c)(6)(v) of this section. Although the 
software meets the requirements of paragraphs (c)(6)(v)(A)(1) and 
(3) of this section, X's development activities did not involve 
significant economic risk under paragraph (c)(6)(v)(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 12. 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 
whether it was capable of developing a server application that could 
schedule and distribute the jobs across thousands of PCs and 
workstations, as well as handle all the error conditions that occur 
on a user's machine. X commits substantial resources to the project. 
X undertakes a process of experimentation to attempt to eliminate 
its uncertainty. At the beginning of the development, X does not 
intend to develop the software for sale. The software does not 
enable X to interact with third parties or allow third parties to 
initiate functions or review data.
    (ii) Conclusion. The software is internal use software because 
it is developed primarily for use in a general and administrative 
function. However, the software satisfies the high threshold of 
innovation test as set forth in paragraph

[[Page 2635]]

(c)(6)(v) 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 13. Internal use software; application of the high 
threshold of innovation test--(i) Facts. X, a multinational 
manufacturer, wants to install 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 sale. The software does not enable X to interact 
with third parties or allow third parties to initiate functions or 
review data.
    (ii) Conclusion. The software is internal use software because 
it is developed primarily for use in a general and administrative 
function. X's activities do not satisfy the high threshold of 
innovation test of paragraph (c)(6)(v) of this section. Although the 
software meets the requirements of paragraphs (c)(6)(v)(A)(1) and 
(3) of this section, X's development activities did not involve 
significant economic risk under paragraph (c)(6)(v)(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 ending on or after the date of publication of the 
Treasury decision adopting these rules as final regulations in the 
Federal Register. Notwithstanding the prospective effective date, the 
IRS will not challenge return positions consistent with these proposed 
regulations for taxable years ending on or after the date these 
proposed regulations are published. For taxable years ending before the 
date these proposed regulations are published in the Federal Register, 
taxpayers may choose to follow either all of the internal use software 
provisions of Sec.  1.41-4(c)(6) in TD 8930 or all of the internal use 
software provisions in the 2001 proposed regulations.

John Dalrymple,
Deputy Commissioner for Services and Enforcement.
[FR Doc. 2015-00690 Filed 1-16-15; 8:45 am]
BILLING CODE 4830-01-P