Skip to Content

Proposed Rule

Credit for Increasing Research Activities

Document Details

Information about this document as published in the Federal Register.

Enhanced Content

Relevant information about this document from Regulations.gov provides additional context. This information is not part of the official Federal Register document.

Published Document

This document has been published in the Federal Register. Use the PDF linked in the document sidebar for the official electronic format.

Start Preamble

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

Start Further Info

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

End Further Info End Preamble Start Supplemental Information

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 Start Printed Page 2625comments 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.Start Printed Page 2626

Commenters suggested that the definition of internal use software should closely follow the general and administrative examples from the 1986 legislative history. Commenters stated that characterizing services provided to customers as “computer” or “noncomputer” will result in disparate treatment. Commenters recommended that the definition should be based on the function provided by the software and not the overall nature of the end product or service provided to third parties. Commenters noted that a facts and circumstances functionality rule may be more difficult to administer, but it is preferable to a bright-line separately stated consideration rule. In addition, commenters asserted that today's highly integrated nature of software development will not prevent taxpayers from being able to separate software development into functions.

Although the 1986 legislative history indicates that Congress intended internal use software to include software used in noncomputer services, the 1999 legislative history requests that Treasury note the rapid pace of technological advance, especially in service-related industries, when providing rules for internal use software. The role that computer software plays in business activities is very different today than it was when the exclusion for internal use software was enacted in 1986. Today, computer software is used in all aspects of business activity, especially in providing goods and services to third parties, and such software has played a vital role in increasing the productivity of the U.S. economy and in making the U.S. more competitive globally.

Accordingly, these proposed regulations provide that software is developed by (or for the benefit of) the taxpayer primarily for internal use if the software is developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business. Similarly, software that the taxpayer develops primarily for a related party's internal use will be considered internal use software. A related party is any corporation, trade or business, or other person that is treated as a single taxpayer with the taxpayer pursuant to section 41(f). Furthermore, these proposed regulations eliminate the distinction between software developed to deliver computer and noncomputer services.

Under these proposed regulations, general and administrative functions are limited to financial management functions, human resource management functions, and support services functions. Financial management functions are functions that involve the financial management of the taxpayer and the supporting recordkeeping. Human resource management functions are functions that manage the taxpayer's workforce. Support services functions are functions that support the day-to-day operations of the taxpayer, such as data processing or facilities services.

This list of functions that constitute general and administrative functions is intended to target the back-office functions of a taxpayer that most taxpayers would have regardless of the taxpayer's industry. The benefits of software developed by the taxpayer for use in general and administrative functions are likely to be captured only by the taxpayer developing it and therefore exclusion from credit eligibility is more consistent with the purposes for which Congress created the credit. However, the characterization of a function as back-office may depend upon the taxpayer's industry. For example, tax software in the tax services industry is not used by the taxpayer in a general and administrative function, but for taxpayers that do not provide tax services, tax software is used by the taxpayer in a general and administrative function.

Non-Internal Use Software

Some commenters, addressing the 2001 proposed regulations' definition of internal use software, suggested that software that is not developed to be commercially sold, leased, licensed, or otherwise marketed for separately stated consideration should not be presumed to be internal use software. Some commenters also questioned whether the exception for software developed to be commercially sold, leased, or licensed is appropriate given the purposes of the research credit. These commenters suggested that such criteria may not further the purposes of the statute because whether software is held for sale may not be indicative of the software's function. These proposed regulations do not contain a presumption for software that is not developed to be commercially sold, leased, licensed, or otherwise marketed for separately stated consideration, but they do treat software that is developed to be commercially sold, leased, licensed, or otherwise marketed as software not developed primarily for internal use.

The Treasury Department and the IRS have determined that the purpose of the software's development can be indicative of the software's function. In this way, the inquiry of whether software is developed for commercial sale, lease, or license looks to the purpose of the software and serves as an additional test separate from a pure functionality test. This approach to identifying software not developed primarily for internal use furthers the underlying purpose of the statute because the benefits from software held for commercial sale, lease, or license are likely to be captured by persons other than the taxpayer developing the software. Accordingly, it should be eligible for the research credit provided the other requirements of section 41 are met. Similarly, software that enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer's system does not solely benefit the taxpayer developing the software, and therefore it is appropriate to exclude such software from the definition of internal use software.

Accordingly, these proposed regulations provide that software is not developed primarily for internal use if it is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties, or if it is developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system. Examples of software developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data include software developed for third parties to execute banking transactions, track the progress of a delivery of goods, search a taxpayer's inventory for goods, store and retrieve a third party's digital files, purchase tickets for transportation or entertainment, and receive services over the internet. For purposes of these rules, third parties do not include any persons that use the software to support a taxpayer's general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business.

Whether software is not developed primarily for internal use depends upon the intent of the taxpayer and the facts and circumstances at the beginning of the software development. If a taxpayer originally develops software primarily for internal use but later makes improvements to the software with the intent to hold the improved software for commercial sale, lease, or license or to allow third parties to initiate functions or review data, the improvements will be considered separate from the existing software and will not be considered to be for internal use. Likewise, if a taxpayer originally develops software for commercial sale, lease, or license or to interact with third parties or to allow Start Printed Page 2627third parties to initiate functions or review data, but later makes improvements to the software with the intent to use the software in general and administrative functions, the improvements will be considered developed primarily for internal use. Any improvements to the existing software will be considered separate from the existing software and the application of the internal use software rules will be made solely to the improvements to the software. Additionally, software that is intended to be developed for commercial sale, lease, or license will not be considered internal use merely because the taxpayer tests the software by using it internally.

Dual Function Computer Software

The Treasury Department and the IRS recognize the need to provide guidance on whether computer software is developed “primarily” for internal use if a taxpayer develops software that serves both general and administrative and non-general and administrative functions. These proposed regulations balance administrative and compliance concerns with the need to provide substantive rules appropriate to the purposes of the research credit. To further these objectives, the proposed regulations provide that dual function computer software is presumed to be developed primarily for a taxpayer's internal use. However, this presumption is inapplicable to the extent that a taxpayer can identify a subset of elements of dual function computer software that only enables a taxpayer to interact with third parties or to allow third parties to initiate functions or review data (third party subset). The proposed regulations provide that if the taxpayer can identify the third party subset, the portion of research expenditures allocable to a third party subset of the dual function computer software may be eligible for the research credit, provided all the other applicable requirements are met.

Moreover, the proposed regulations provide taxpayers with a safe harbor to apply to dual function computer software if a third party subset cannot be identified or to the remaining subset of dual function computer software after the third party subset has been identified (dual function subset). The safe harbor allows a taxpayer to include 25 percent of the qualified research expenditures of the dual function subset in computing the amount of the taxpayer's credit, provided that the taxpayer's research activities related to the dual function subset constitute qualified research and the use of the dual function subset by third parties or by the taxpayer to interact with third parties is reasonably anticipated to constitute at least 10 percent of the dual function subset's use. The proposed regulations provide that taxpayers must use an objective, reasonable method to estimate the computer software's use by third parties or by the taxpayer to interact with third parties and such use of the dual function computer software is estimated at the beginning of software development. The proposed regulations contain a facts and circumstances approach to determine a taxpayer's intent at the beginning of computer software development and provide several examples illustrating these rules. In the Request for Public Comments section of this preamble, the Treasury Department and the IRS request comments on the administrability of certain objective, reasonable methods of measuring third parties' reasonably anticipated use as well as other appropriate, objective standards that can be used to measure third parties' reasonably anticipated use.

Computer Software and Hardware Developed as a Single Product

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

Computer Software as Part of a Production Process

Several commenters asserted that computer software supporting the delivery of goods or services to third parties is not internal use software because the software is part of a production process within the meaning of section 41(d)(4)(E)(ii). Thus, for example, computer software that is used to track a taxpayer's inventory of goods would not be internal use software because the tracking of inventory supports the taxpayer's ability to deliver goods to third parties, which is a final step in the taxpayer's production process.

The Treasury Department and the IRS do not agree that computer software supporting the delivery of goods or services to third parties is part of a production process within the meaning of section 41(d)(4)(E)(ii). To the contrary, the delivery of goods and services to third parties is a post-production activity. Nonetheless, under rules provided in these proposed regulations and described previously in this preamble, computer software supporting the delivery of goods or services to third parties may not be within the definition of software developed primarily for internal use to the extent that the software enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data.

High Threshold of Innovation

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

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

See H.R. Conf. Rep. No. 841, at II-73.

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

Innovation

The 1986 legislative history requires that the software result in a reduction in Start Printed Page 2628cost 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 Start Printed Page 2629software 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 Start Printed Page 2630minutes 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.

Start List of Subjects

List of Subjects in 26 CFR Part 1

  • Income taxes
  • Reporting and recordkeeping requirements
End List of Subjects

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:

Start Part

PART 1—INCOME TAXES

End Part Start Amendment Part

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

End Amendment Part Start Authority

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

End Authority

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

Start Amendment Part

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

End Amendment Part Start Amendment Part

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

End Amendment Part Start Amendment Part

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

End Amendment Part

The additions and revisions read as follows:

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

(a) * * *

(8) * * *

Example 5.

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

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

Example 6.

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

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

Example 7.

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

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

Example 8.

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

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

Example 9.

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

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

Example 10.

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

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

* * * * *

(c) * * *

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

(A) The software satisfies the requirements of section 41(d)(1);

(B) The software is not otherwise excluded under section 41(d)(4) (other than section 41(d)(4)(E)); and

(C) One of the following conditions is met—

(1) The taxpayer develops the software for use in an activity that constitutes qualified research (other than the development of the internal use software itself);

(2) The taxpayer develops the software for use in a production process to which the requirements of section 41(d)(1) are met; or

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

(ii) Computer software and hardware developed as a single product. This paragraph (c)(6) does not apply to the development costs of a new or improved package of computer software and hardware developed together by the taxpayer as a single product (or to the costs to modify an acquired computer software and hardware package), of which the software is an integral part, that is used directly by the taxpayer in providing services in its trade or business. In these cases, eligibility for the research credit is to be determined by examining the combined hardware-software product as a single product.

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

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

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

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

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

(iv) Software not developed primarily for internal use—(A) In general. Computer software is not developed primarily for the taxpayer's internal use if either—

(1) The software is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties; or

(2) The software is developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer's system.

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

(C) Computer software developed for both internal use and to enable interaction with third parties—(1) Presumption of development primarily for internal use. Unless paragraph (c)(6)(iv)(C)(2) or (3) of this section applies, computer software developed by (or for the benefit of) the taxpayer both for use in general and administrative functions that facilitate or support the conduct of the taxpayer's trade or business and to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data (dual function computer software) is presumed to be developed primarily for a taxpayer's internal use.

(2) Identification of a subset of elements of computer software that only enables interaction with third parties. To the extent that a taxpayer can identify a subset of elements of dual function computer software that only enables a taxpayer to interact with third parties or allows third parties to initiate functions or review data (third party subset), the presumption under paragraph (c)(6)(iv)(C)(1) of this section Start Printed Page 2632does 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.Start Printed Page 2633

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

(C) Significant economic risk. The software development involves significant economic risk if the taxpayer commits substantial resources to the development and if there is substantial uncertainty, because of technical risk, that such resources would be recovered within a reasonable period. This standard does not require technical uncertainty regarding whether the final result can ever be achieved, but rather whether the final result can be achieved within a timeframe that will allow the substantial resources committed to the development to be recovered within a reasonable period. Substantial uncertainty exists if, at the beginning of the taxpayer's activities, the information available to the taxpayer does not establish the capability or method for developing or improving the software. Technical risk arises from uncertainty that is technological in nature, as defined in § 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 Start Printed Page 2634Software is internal use software because it is developed primarily for use in general and administrative functions.

Example 8.

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

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

Example 9.

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

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

Example 10.

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

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

Example 11.

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

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

Example 12.

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

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

Example 13.

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

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

* * * * *

(e) Effective/applicability dates. Other than paragraph (c)(6) of this section, this section is applicable for taxable years ending on or after December 31, 2003. Paragraph (c)(6) of this section is applicable for taxable years ending on or after the date of publication of the Treasury decision adopting these rules as final regulations in the Federal Register. Notwithstanding the prospective effective date, the IRS will not challenge return positions consistent with these proposed regulations for taxable years ending on or after the date these proposed regulations are published. For taxable years ending before the date these proposed regulations are published in the Federal Register, taxpayers may choose to follow either all of the internal use software provisions of § 1.41-4(c)(6) in TD 8930 or all of the internal use software provisions in the 2001 proposed regulations.

Start Signature

John Dalrymple,

Deputy Commissioner for Services and Enforcement.

End Signature End Supplemental Information

[FR Doc. 2015-00690 Filed 1-16-15; 8:45 am]

BILLING CODE 4830-01-P