2624 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

(2) The FCA will use the postmark, 

ship date, electronic stamp, or similar 

evidence as the date of filing the 

reconsideration petition. 

(d) The FCA will notify the named 

contact on the reconsideration petition 

whether the petition was filed on time. 

On the timely receipt of a 

reconsideration petition, the FCA will 

review the petition to determine 

whether it complies with the 

requirements of section 7.9 of the Act. 

Following a determination that the 

petition was timely filed and complies 

with applicable requirements, the FCA 

will give notice to the associations 

involved in the merger or consolidation 

for which the reconsideration petition 

was filed. The associations are not 

entitled to either a copy of the petition 

or the names of the petitioners. 

(e) Following FCA notification that a 

reconsideration petition has been 

properly filed, a special stockholders 

meeting must be called by the 

association(s) to reconsider the merger 

or consolidation vote. The 

reconsideration vote must be conducted 

according to the merger and 

consolidation voting requirements of 

§ 611.1122(d). If a majority of the 

stockholders voting, in person or by 

proxy, at a duly authorized 

stockholders’ meeting from any one of 

the constituent associations vote against 

the merger or consolidation under the 

reconsideration vote, the merger or 

consolidation will not take place. In the 

event that the merger or consolidation is 

approved on reconsideration, the 

constituent associations must use the 

second effective date developed under 

§ 611.1122(g)(1). 

Dated: January 13, 2015. 

Dale L. Aultman, 

Secretary, Farm Credit Administration Board. 

[FR Doc. 2015–00676 Filed 1–16–15; 8:45 am] 

BILLING CODE 6705–01–P 

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 

§ 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 § 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 § 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. 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
2626 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

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-today 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 postproduction 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
2628 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

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 § 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 § 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 

§ 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 § 1.41–4(c)(6) in the 2001 

final regulations or all of the internal 

use software provisions of § 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 § 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
2630 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

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 

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

■ Par. 2. Section 1.41–4 is amended by: 

■ 1. Adding Example 5 through 

Example 10 at the end of paragraph 

(a)(8). 

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

The additions and revisions read as 

follows: 

§ 1.41–4 Qualified research for 

expenditures paid or incurred in taxable 

years ending on or after December 31, 2003. 

(a) * * * 

(8) * * * 

Example 5. (i) Facts. X, a retail and 

distribution company, wants to upgrade its 

warehouse management software. X 

evaluates several of the alternative 

warehouse management software products 

available from vendors in the marketplace to 

determine which product will best serve X’s 

technical requirements. X selects vendor V’s 

software. 

(ii) Conclusion. X’s activities to select the 

software are not qualified research under 

section 41(d)(1) and paragraph (a)(5) of this 

section. X did not conduct a process of 

evaluating alternatives in order to eliminate 

uncertainty regarding the development of a 

business component. X’s evaluation of 

products available from vendors is not a 

process of experimentation. 

Example 6. (i) Facts. X wants to develop 

a new web application to allow customers to 

purchase its products online. X, after 

reviewing commercial software offered by 

various vendors, purchases a commercial 

software package of object-oriented functions 

from vendor Z that X can use in its web 

application (for example, a shopping cart). X 

evaluates the various object-oriented 

functions included in vendor Z’s software 

package to determine which functions it can 

use. X then incorporates the selected 

software functions in its new web application 

software. 

(ii) Conclusion. X’s activities related to 

selecting the commercial software vendor 

with the object-oriented functions it wanted, 

and then selecting which functions to use, 

are not qualified research under section 

41(d)(1) and paragraph (a)(5) of this section. 

In addition, incorporating the selected objectoriented 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 hardwaresoftware 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 dayto-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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
2632 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

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. 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 § 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
2634 Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 

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 objectoriented programming language, and to move 

the new application off the mainframe to a 

client/server environment. Both the objectoriented 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 


rljohnson on DSK3VPTVN1PROD with PROPOSALS
Federal Register / Vol. 80, No. 12 / Tuesday, January 20, 2015 / Proposed Rules 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 

§ 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 

ENVIRONMENTAL PROTECTION 

AGENCY 

40 CFR Part 52 

[EPA–R09–OAR–2014–0781; FRL–9920–53– 

Region 9] 

Revisions to the California State 

Implementation Plan, South Coast Air 

Quality Management District and 

Ventura County Air Pollution Control 

District 

AGENCY: Environmental Protection 

Agency (EPA). 

ACTION: Proposed rule. 

SUMMARY: The Environmental Protection 

Agency (EPA) is proposing to approve 

revisions to the South Coast Air Quality 

Management District (SCAQMD) and 

the Ventura County Air Pollution 

Control District (VCAPCD) portions of 

the California State Implementation 

Plan (SIP). These revisions concern 

volatile organic compound (VOC) 

emissions from delayed coking units 

used in petroleum refining, and sulfur 

dioxide primary emissions from fossil 

fuel combustion. We are proposing to 

approve local rules to regulate these 

emission sources under the Clean Air 

Act (CAA or the Act). 

DATES: Any comments on this proposal 

must arrive by February 19, 2015. 

ADDRESSES: Submit comments, 

identified by docket number EPA–R09– 

OAR–2014–0781 by one of the following 

methods: 

1. Federal eRulemaking Portal: 

www.regulations.gov. Follow the on-line 

instructions. 

2. Email: steckel.andrew@epa.gov. 

3. Mail or deliver: Andrew Steckel 

(Air-4), U.S. Environmental Protection 

Agency Region IX, 75 Hawthorne Street, 

San Francisco, CA 94105–3901. 

Instructions: All comments will be 

included in the public docket without 

change and may be made available 

online at www.regulations.gov, 

including any personal information 

provided, unless the comment includes 

Confidential Business Information (CBI) 

or other information whose disclosure is 

restricted by statute. Information that 

you consider CBI or otherwise protected 

should be clearly identified as such and 

should not be submitted through 

www.regulations.gov or email. 

www.regulations.gov is an ‘‘anonymous 

access’’ system, and EPA will not know 

your identity or contact information 

unless you provide it in the body of 

your comment. If you send email 

directly to EPA, your email address will 

be automatically captured and included 

as part of the public comment. If EPA 

cannot read your comment due to 

technical difficulties and cannot contact 

you for clarification, EPA may not be 

able to consider your comment. 

Electronic files should avoid the use of 

special characters, any form of 

encryption, and be free of any defects or 

viruses. 

Docket: Generally, documents in the 

docket for this action are available 

electronically at www.regulations.gov 

and in hard copy at EPA Region IX, 75 

Hawthorne Street, San Francisco, 

California 94105–3901. While all 

documents in the docket are listed at 

www.regulations.gov, some information 

may be publicly available only at the 

hard copy location (e.g., copyrighted 

material, large maps), and some may not 

be publicly available in either location 

(e.g., CBI). To inspect the hard copy 

materials, please schedule an 

appointment during normal business 

hours with the contact listed in the FOR

FURTHER INFORMATION CONTACT section. 

FOR FURTHER INFORMATION CONTACT: 

James Shears, EPA Region IX, (213) 

244–1810, shears.james@epa.gov. 

SUPPLEMENTARY INFORMATION: This 

proposal addresses the following local 

rules: SCAQMD Rule 1114, Petroleum 

Refinery Coking Operations, and 

VCAPCD Rule 54, Sulfur Compounds. 

In the Rules and Regulations section of 

this Federal Register, we are approving 

these local rules in a direct final action 

without prior proposal because we 

believe these SIP revisions are not 

controversial. If we receive adverse 

comments, however, we will publish a 

timely withdrawal of the direct final 

rule and address the comments in 

subsequent action based on this 

proposed rule. Please note that if we 

receive adverse comment on an 

amendment, paragraph, or section of 

this rule and if that provision may be 

severed from the remainder of the rule, 

we may adopt as final those provisions 


rljohnson on DSK3VPTVN1PROD with PROPOSALS