Software development is one of the activities most commonly asked about in connection with the federal R&D tax credit. The short answer is that software-development activities may relate to the credit when they satisfy the qualified-research requirements under Section 41 of the Internal Revenue Code — but writing software does not automatically qualify. This page explains how software-development work is generally evaluated and where the analysis focuses. It is educational and is not individualized advice. For the foundational framework, see our page on qualified research.
Software Development and the R&D Tax Credit
Under Section 41, the credit is associated with qualified research activities and qualified research expenses that meet the applicable requirements. Software can be a business component — the thing the research is intended to develop or improve — and the costs of certain employees, supplies, and contract research connected to qualifying software activities may be taken into account. But the same requirements that apply to any other activity apply to software: the work must constitute qualified research. For more, see our page on what the R&D tax credit is.
The Four-Part Test Still Applies
Software activities are analyzed under the same four-part test as any other activity. Under Section 41(d) and the Treasury Regulations (§1.41-4), qualified research generally must be undertaken for a permitted purpose, be technological in nature, be intended to eliminate uncertainty, and be conducted through a process of experimentation, all with respect to a business component. There is no separate, relaxed standard for software. Meeting one element is not enough; all four must be satisfied.
Technical Uncertainty in Software Development
The elimination-of-uncertainty element asks whether the work is intended to eliminate a technical uncertainty about the capability, method, or appropriate design of the software business component. Uncertainty about whether a market will adopt a feature, whether a project will finish on time, or whether a product will be profitable is ordinary business uncertainty, not the technical uncertainty this element addresses. For more, see our page on elimination of uncertainty.
Process of Experimentation in Software
The process-of-experimentation element looks for a structured, evaluative process of alternatives — for example, modeling or simulating alternative architectures, benchmarking alternative algorithms, or systematically testing competing approaches to resolve a technical question. Ordinary debugging, routine iteration, or following a known pattern generally is not, by itself, a process of experimentation. For more, see our page on process of experimentation.
Examples of Activities That May Warrant Review
The following are general examples that may warrant review; none automatically qualifies, and each depends on whether all four elements are satisfied:
- evaluating alternative software architectures to resolve a question about whether a system can achieve a target capability or scale.
- developing or evaluating algorithms where the appropriate method or design is uncertain.
- resolving integration uncertainty where combining systems raises a technical question not established at the outset.
- engineering for reliability or security where the appropriate design is uncertain and is evaluated through testing.
- testing competing technical approaches to meet a performance target where the method is not established.
In each case, the question is whether the work is intended to eliminate a technical uncertainty through a technological process of inquiry that fundamentally relies on computer science or engineering principles.
Routine Development vs. Experimental Development
A central distinction is between routine development and experimental development. Routine development — building software to known specifications using established methods, where there is no technical uncertainty about the capability, method, or appropriate design — generally does not, by itself, constitute qualified research. Experimental development — where a team evaluates alternatives to resolve a genuine technical uncertainty — may. The line turns on the specific facts, and not every software project falls on one side or the other.
New or Improved Software as a Business Component
Software can be a business component under Section 41, and the research must relate to developing or improving that business component — for example, a new or improved function, performance, reliability, or quality. Activities that cannot be tied to a specific software business component, or that are described only at a general departmental level, may be harder to evaluate against the four-part test.
Internal-Use Software Considerations
Software developed primarily for the taxpayer's internal use is subject to additional requirements beyond the four-part test. Under the Treasury Regulations (§1.41-4(c)(6)), internal-use software generally must also satisfy a "high threshold of innovation" test. Whether software is internal-use is itself a facts-and-circumstances determination, and software that is developed to interact with third parties, or that is commercially sold, leased, or licensed, may not be internal-use. For more, see our page on internal-use software.
Employee and Contractor Costs
Where software activities may qualify, the costs that may be taken into account are qualified research expenses — certain wages of employees who perform or directly support qualified research, and certain contract research expenses — that meet the requirements of Section 41(b). Not every developer's wages or every contractor invoice automatically qualifies; the costs must be connected to qualified research activities and properly allocated. For more, see our page on qualified research expenses.
Documentation That May Help
Records describing the software business component, the technical uncertainty, the alternatives evaluated, the evaluative process, and the connection between personnel, costs, and activities can help support a software-related credit claim. The IRS has published guidance on the information it expects in connection with research credit claims. For more, see our page on R&D tax credit documentation.
Key Takeaway
Software-development activities may relate to the R&D tax credit when they satisfy the qualified-research requirements — including a permitted purpose, technological nature, elimination of uncertainty, and a process of experimentation — and internal-use software may be subject to additional requirements. Writing software does not automatically qualify, and the analysis turns on the specific facts. Because these determinations are fact-specific, professional review is appropriate before claiming the credit.