At TCC, we have been lucky enough to meet many interesting and intelligent people. One of these people is now leading a project to replace a tedious manual process with a software tool that incorporates artificial intelligence. Ultimately, it will save the company millions of dollars. But, because they’re not a software company and it’s for internal use, they’ve decided not to pursue the R&D tax credit … despite the fact that this is actually a textbook example of a software project that qualifies.
In our opinion, software development and research-and-development go hand-in-hand, and any project that qualifies should take advantage of the tax credit. But don’t take our word for it – let’s review what the IRS has to say about tax credits for software development.
Officially falling under the “Credit for Increasing Research Activities,” more commonly known as the “R&D tax credit,” the government gives you a dollar-for-dollar tax credit up to a certain percentage of the total expenses for qualifying projects.
What Software Projects Qualify?
Software activities qualify for the tax credit only if they pass a four-part test. Here are the four criteria from a software development perspective:
- You’re creating new software or substantially improving the functionality, performance, quality or reliability of existing software.
- You’re continually working toward “eliminating uncertainty.” For example, you don’t already know the best way to design the database, reports or the user interface to make it intuitive and efficient. The whole point of the project is to figure this out – to eliminate technical uncertainty.
- You’re experimenting. You create a testing plan, test the software, make changes and then repeat the experiment until you get it right or decide to scrap it. Not all experiments succeed.
- You’re relying on the principles of computer science (e.g., programming, abstractions, algorithmic extrapolations, statistics and coding).
Additional Criteria for Internal-Use Software
The IRS defines two types of software:
- External Use: Software you sell, license or lease to customers or clients; or software that enables customers to interact with you. For example, software supporting online sales is considered external use because customers interact with the software to buy goods and services.
- Internal Use: Software you develop for yourself to use internally in the support of your business. This includes software developed to support functions such as financial management, human resources management and support services.
If the software is for internal use, it must meet three additional requirements:
- It cannot be commercially available. Taxpayers cannot purchase or license software without substantial modification, and meeting your requirements cannot be purchased or licensed without substantial modification.
- It must be innovative. The software must provide you with an economically significant reduction in cost, improvement in speed or with another measurable improvement that is targeted by the project
- It must come with significant risk. There must be a significant economic and technical risk, meaning that if the project ultimately fails, you could not recover the costs within a reasonable time.
Which Activities Qualify?
To calculate your tax credit, you must identify the qualifying activities. Make sure you do so at a level of detail that enables you to assign employees to the activities to calculate the associated expense. Important: Any activities performed outside the United States are automatically disqualified.
A common way of identifying and analyzing activities for software projects is to use the company’s Software Development Life Cycle (SDLC). Examples of software development methodologies include the waterfall methodology, agile software development, extreme programming, feature-driven development and others. For example, the waterfall methodology typically has six phases:
- Requirements analysis
- Software design
- Software development
The first five phases may have many qualifying activities. For example,
- Analyzing requirements to create functional specifications,
- Designing the overall architecture and the specific software modules,
- Programming and compiling the software,
- Establishing interfaces among modules or with other systems and
- Developing and executing test plans.
However, when the software is complete, it no longer meets the criteria in the four-part test. As a result, the last phase of the SDLC rarely has qualifying activities. For example, these activities do not qualify:
- Maintaining the software after it’s released, including bug fixes,
- Deploying the software and other production support activities,
- Testing the software after it’s been released as part of regular, ongoing routine quality control procedures and
- Configuring the parameters of a software application to adapt it to your needs.
Finally, it’s not unusual to develop internal-use software with an external component, such as a module for customers to review and update their account information (known as “dual function” software). This software is presumed to be used internally, but if you can identify the external portion of the software (i.e., the elements that only enable third-party interactions), that portion of the software will not be subject to the additional three tests. In addition, the IRS allows taxpayers to claim 25% of development costs if the third-party use is expected to constitute at least 10% of the total use of the software – this is the “safe harbor” alternative.
Cost-Benefit and Risk Analysis
Qualifying software projects for the R&D tax credit – especially internal-use software projects – is not a simple task. However, if your R&D efforts include software development, you should at least perform a cost/benefit analysis. Come up with a range representing the estimated tax credit and compare it to the effort required and the risk associated with being challenged by the IRS. If you live in one of the 37 states that provide similar tax credits, claiming the state tax credit usually doesn’t require much additional effort.
The moral of the story? Don’t decide to not pursue the R&D tax credit simply because it may be complicated – take an honest look using these guidelines before you decide one way or the other. It may be well worth the extra effort.