IRS Gives R&D Guidance on Internally Developed Software– January 30, 2015

The IRS issued new proposed regulations on January 20, 2015. These regulations are intended to provide guidance on how internally developed software applies to the R&D tax credit.

Generally in regard to the R&D credit, research with respect to computer software developed by the taxpayer primarily for internal use is not considered qualified research. However, it can qualify if the software meets certain conditions. The proposed regulations continue to stress (and further expand on) these conditions, but the proposed regs also further define internal use software and provide rules and a safe harbor for dual-function software.

Overview of Proposed Regulations

Software qualifies for the R&D credit if it meets ONE of the following conditions:

  • Developed for use with a qualified research activity
    • Find detailed information on what constitutes a qualified activity at R&D Credit: Why Your Business May Qualify.
  • Developed for use in a production process
    • Any plant process, machinery or technique for commercial production of a business component)
    • The proposed regulations add that software supporting the delivery of goods or services to third parties cannot be considered used in a production process, because this is a post-production activity
  • Meets the high threshold of innovation test
    • Software is unique or novel and is intended to differ in a significant and inventive way from prior software (must result in a reduction in cost or an improvement in speed)
    • Development involves significant economic risk – both technical and economic (i.e. committing resources and having uncertainties of success), and
    • Software is not commercially available for use by the taxpayer

Under the proposed regulations, internal use software is defined as software “developed by the taxpayer for use in general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business.” General and administrative functions include:

  • Financial management functions
    • Involve the financial management of the taxpayer and the supporting recordkeeping
  • Human resource management functions
    • Manage the taxpayer’s workforce
  • Support services functions
    • Support the day-to-day operations of the taxpayer

Non-internal use software is defined as software that 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.

Software is considered dual-function if it serves both general and administrative, and non-general and administrative functions. This type of software is presumed to be developed for internal use. However, if the taxpayer can prove that the software includes third-party functions, that portion of the software may be eligible for the credit. A safe harbor is provided if a third-party subset cannot be identified. It allows a taxpayer to include 25% of the qualified research expenditures of the dual function subset when calculating the credit, providing these research activities are considered qualified research and the third-party functions are reasonably anticipated to constitute at least 10% of the dual function subset’s use.

The following example is provided in the proposed regulations to illustrate how software developed for internal use can still qualify for the credit:

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.

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

Moving Forward

The good news is that these proposed regulations, as they now stand, are consistent with Cohen & Company’s existing treatment of internal software as it relates to the R&D credit. But if you have specific questions, please contact a member of your service team or Teri Grumski at tgrumski@cohencpa.com.

The IRS is also requesting comments on these proposed regulations to be submitted (either written or electronic) by March 23, 2015. Comments can be sent electronically through www.regulations.gov or via mail to:

CC:PA:LPD:PR (REG-153656-03)
Room 5205
Internal Revenue Service
PO Box 7604
Ben Franklin Station
Washington, DC 20044

We want to hear from you! We encourage you to comment below on this blog post or share it on social media.

This communication is published by Cohen & Company for our clients and professional associates. Cohen & Company is not rendering legal, accounting or other professional advice. Any action taken based on information in this publication should be taken only after a detailed review of the specific facts and circumstances.