The R&D Tax Credit is back! Find out how the Big Beautiful Bill Act can fund your R&D. Learn More
%201.svg)
.svg)
.svg)
.svg)
Last Updated: October 2026
Software development can qualify for the R&D tax credit when the work involves developing or improving software through a process that meets the requirements of Internal Revenue Code Section 41. Qualifying projects can include building new functionality, improving performance or scalability, developing APIs, testing system architectures, strengthening security, optimizing databases, and solving other technical challenges where the solution is not readily known.
But writing code does not automatically qualify as R&D.
The IRS looks at what the development team was trying to accomplish, what technical uncertainty existed, and how the team evaluated alternatives to resolve it. Routine maintenance, cosmetic changes, straightforward configurations, and other work without technical experimentation may not qualify. Internal-use software can also face additional requirements.
For software companies, the key is separating ordinary development work from the technical experimentation that meets Section 41.
Yes. Software development can qualify for the R&D tax credit when the underlying activities satisfy the Section 41 requirements for qualified research.
The credit is not limited to companies inventing entirely new technologies. Research intended to improve the function, performance, reliability, or quality of existing software can also potentially qualify.
That can make the credit relevant to companies developing:
Eligibility depends on the activities, not whether the business describes itself as a software or technology company.
A manufacturer developing proprietary production software, for example, may perform software R&D even though its primary business is manufacturing.
Software development generally needs to satisfy the same Four-Part Test that applies to other forms of qualified research.
The research should relate to a new or improved function, performance, reliability, or quality.
For software, that could mean improving processing speed, creating new functionality, increasing scalability, improving system reliability, or strengthening security.
Software development commonly relies on computer science or engineering principles.
But simply using technology does not satisfy this requirement. The research itself needs to rely on technological principles.
At the beginning of the research, the development team should face uncertainty about the capability, method, or appropriate design of the software.
For example: Can the existing architecture process the required transaction volume without unacceptable latency?
That is different from: How should we change the color of this button?
Both require development work, but only the first presents an obvious technical question.
The Company needs to evaluate alternatives to resolve the uncertainty.
Software experimentation can include:
The IRS applies the Four-Part Test separately to each business component, so a company should not simply classify its entire software department as R&D.
Potentially qualifying software activities usually involve solving a technical problem where the appropriate solution is uncertain.
Here are some common examples:
The activity itself matters more than the label.
"API development," for example, is not automatically qualified research. Implementing a well-documented API using a known method may involve little technical uncertainty.
Developing an integration where the team must test several approaches to meet difficult performance, security, or interoperability requirements presents a different fact pattern.
Routine software work generally does not become qualified research simply because developers perform it. Activities less likely to qualify can include:
Section 41 specifically excludes research after the beginning of commercial production, adaptation of an existing business component to a particular customer's requirements, duplication, certain surveys and studies, foreign research, and certain internal-use software.
The line is not always "new development versus maintenance."
A project involving an existing product can still contain qualified research if engineers encounter a new technical uncertainty and conduct experimentation to resolve it.
Sometimes. Refactoring is not automatically qualified or excluded.
Routine cleanup that follows an established approach may not involve the technical uncertainty required under Section 41.
But technical debt projects can become more interesting when engineers need to experiment with different approaches to solve problems involving:
For example, reorganizing code solely to make it easier to read presents a very different case from rearchitecting a legacy application because the existing system cannot support required transaction volumes.
The second project may involve engineers testing several architectures, migration approaches, database structures, and performance strategies before determining what works.
Yes. SaaS companies can perform qualified research while developing or improving their platforms.
Potential projects can involve:
A SaaS company continually releases features, however, does not automatically mean all engineering costs qualify.
The Four-Part Test still applies to the underlying development activities.
TaxTaker already has a SaaS-specific resource covering how the credit applies to SaaS companies.
API and integration development may qualify when it involves technical uncertainty and experimentation rather than straightforward implementation.
Suppose a development department is required to connect its platform with another system.
If the external API is well documented and engineers simply follow established instructions, the project may involve little technical uncertainty.
Now consider a situation where the systems use incompatible data structures, existing integration methods cannot meet latency requirements, and the development team needs to test several approaches for data transformation, caching, and synchronization.
That presents a stronger R&D fact pattern.
Again, the technology being used does not determine qualification. The development process does.
Yes, performance and scalability work can potentially qualify when developers face technical uncertainty and systematically evaluate alternatives.
Examples might include:
Imagine a SaaS platform needs to support ten times its existing transaction volume.
The Company might evaluate several database architectures, caching strategies, asynchronous processing methods, or infrastructure configurations.
Testing those alternatives against defined performance requirements can provide evidence of experimentation.
Simply adding additional server capacity using an established configuration, however, may present much less technical uncertainty.
Cybersecurity development may qualify when the project involves developing or improving technology and resolving technical uncertainty. Potential examples include:
Routine security patching, installing commercially available security software, or applying known configuration changes generally presents a different case.
The key question remains: Did the team know the technical solution at the beginning, or did it need to experiment to find one?
Some cloud infrastructure and DevOps work may qualify, particularly when it is part of resolving a broader technical uncertainty. Potential examples include experimenting with:
Routine deployments, standard cloud migrations, ordinary server administration, and established infrastructure configurations may not involve qualified research.
This is another area where companies should avoid assuming that every engineering activity qualifies simply because it is technically complex.
Database work can potentially qualify when developers experiment to resolve technical uncertainty around performance, architecture, scalability, or functionality.
For example, a Company may need to determine how to structure a large dataset so an application can return complex queries within a defined response time.
Engineers might compare:
If the appropriate design is uncertain and the team systematically tests alternatives, those activities may support a qualified-research analysis.
Routine database administration or implementation using an established design generally presents a weaker case.
AI and machine learning development can qualify, but using AI does not automatically qualify a project as R&D.
The underlying development still needs to satisfy Section 41. Potentially qualifying AI work might involve experimentation with:
A company integrating an existing AI API using well-documented methods may have a very different qualification profile from a team experimenting with multiple architectures and retrieval strategies to achieve an uncertain technical performance requirement.
It can, but this is one of the most important distinctions in software R&D.
Software developed primarily for a taxpayer's internal use can be subject to additional requirements beyond the standard qualified-research rules.
Under current IRS guidance, internal-use software generally needs to satisfy the normal qualified-research requirements and the High Threshold of Innovation, or HTI, test.
The HTI test requires the taxpayer to establish that:
But not all software a company uses internally is automatically treated as internal-use software for these purposes.
The IRS generally focuses internal-use treatment on software developed for general and administrative functions that facilitate or support the taxpayer's business.
Examples can include software supporting functions such as:
By contrast, the current Form 6765 instructions explain that software is not developed primarily for internal use when, for example, it is developed to be commercially sold, leased, licensed, or otherwise marketed to third parties.
Software developed to allow third parties to interact with the taxpayer or initiate functions or review data on the taxpayer's system can also fall outside internal-use treatment, subject to the applicable rules.
This distinction matters because a SaaS company's customer-facing platform and another company's internally developed accounting system may face different qualification standards.
Dual-function software serves both internal business functions and third-party functions.
For example, a system might support internal administration while also allowing customers to submit information or interact directly with the company. The software rules include specific treatment for dual-function software, including circumstances where a third-party subset can be identified and a safe harbor may apply.
The current Form 6765 instructions even require taxpayers completing Section G to classify software business components using categories that include:
Because these distinctions can materially affect qualification, companies developing software for both employees and external users should identify the software's intended functions early in the analysis.
Once qualifying software activities have been identified, the company needs to determine which costs are Qualified Research Expenses.
For software businesses, potentially relevant QRE categories can include:
Wages may qualify for employees performing, directly supervising, or directly supporting qualified research. Potential roles might include:
The employee's title does not determine qualification. The activities actually performed do.
Certain payments to U.S.-based contractors performing qualified research may be included subject to the contract-research rules.
Software companies tend to have fewer physical supply QREs than manufacturers, but certain tangible supplies consumed during qualified research can potentially qualify.
Certain costs for computers rented or leased for qualified research can potentially qualify. Form 6765 separately identifies computer rental or lease costs in its QRE reporting.
Some cloud computing costs may potentially qualify, but software companies should avoid treating the entire AWS, Azure, or Google Cloud bill as an R&D expense.
The analysis depends on the nature of the expense and how the computing resources are being used.
Development or testing environments used directly in qualified research can present a stronger case than ordinary production hosting serving customers after development is complete.
Companies should therefore consider separating:
This is also an area where detailed cloud billing and project records can be useful.
Software companies calculate the federal research credit under the same Section 41 framework as other businesses.
The credit is based on QREs, not total software-development spending.
A company may use the applicable Regular Research Credit method or the Alternative Simplified Credit (ASC). Under the ASC, the calculation generally compares current-year QREs with 50% of the average QREs from the previous three tax years and applies the statutory calculation in Form 6765.
That means two software companies with identical engineering payroll can generate very different credits depending on:
Potentially, yes.
A software startup does not need to be profitable to generate an R&D tax credit. Certain companies that meet the Qualified Small Business requirements can elect to apply up to $500,000 per year of research credit against qualifying employer payroll taxes.
This can make the credit particularly relevant for software startups that have substantial engineering payroll while still operating at a loss.
Section 174A and Section 41 deal with related but different aspects of R&D tax treatment.
Section 41 governs the R&D tax credit.
Section 174A addresses the treatment of domestic research or experimental expenditures. Following the 2025 legislative changes, domestic R&E expenditures generally can once again be deducted currently for tax years beginning after December 31, 2024, with an election available to capitalize and amortize qualifying domestic costs instead. Foreign research expenditures remain subject to different treatment.
This is especially important for software businesses because software-development costs can fall within the research-expenditure rules even when the underlying activity does not generate a Section 41 credit.
In other words:
An expense being an R&E expenditure does not automatically mean it is a QRE.
Software companies should coordinate the two analyses rather than treating Section 174A and the R&D tax credit as interchangeable.
Software companies often already create much of the documentation needed to support an R&D credit during normal development.
Useful records can include:
The goal is to connect four things:
Technical uncertainty → experimentation → people performing the work → expenses claimed
A Git commit alone does not prove qualified research. But source-control history, technical tickets, test results, payroll data, and project documentation together can create a much clearer record of what happened.
Form 6765 is used to calculate and claim the federal research credit.
For tax years beginning after 2025, many taxpayers are also required to complete Section G, which reports information by business component. The current instructions use an 80%/Top 50 methodology for taxpayers required to complete this section.
Software companies have an additional detail to consider.
When the business component reported in Section G is software, the form requires a software classification. Current categories include internal-use software, dual-function software, software excepted from internal-use treatment, and non-internal-use software.
That makes it increasingly useful to organize development records around identifiable products, platforms, systems, or other business components instead of maintaining one broad annual category called "software development."
Potentially. Many states offer research incentives in addition to the federal R&D credit.
For software companies with remote or distributed development teams, employee location can be especially important because state credits generally focus on research conducted within the applicable state.
A company headquartered in California but employing engineers in Texas, New York, and Colorado should not assume all federal QREs belong in one state's calculation.
The company needs to consider where the qualified research was actually performed and the rules of each applicable state.
Software companies with distributed teams can review TaxTaker's R&D credit guidance for research conducted in California, Texas, and New York.
The biggest mistake is assuming all software development is R&D.
It is not. Other common problems include:
A better approach starts with the individual software projects and asks:
What were we trying to improve? What did we not know? What alternatives did we test? What did those experiments cost?
Do not ask developers to become tax professionals.
Instead, build the R&D process around information the engineering team already creates.
A lightweight quarterly workflow might look like:
This approach is generally more reliable than asking an engineering leader twelve months later to remember how everyone spent their time.
Coding alone does not automatically qualify. Software development needs to satisfy the Section 41 requirements for qualified research, including technical uncertainty and a process of experimentation. Routine coding using an established solution may not meet those requirements.
Routine bug fixes generally present a weak R&D case because the solution may already be known. A debugging project can be different when engineers face a genuine technical uncertainty and systematically test alternative approaches to identify and resolve the underlying problem.
SaaS development can qualify when the underlying activities satisfy Section 41. Developing new functionality, testing architectures, improving scalability, and solving technical performance problems are examples of activities that may warrant further evaluation.
Certain internal-use software can qualify, but it may need to satisfy the High Threshold of Innovation test in addition to the normal qualified-research requirements. The HTI test considers innovation, significant economic risk, and commercial availability.
Certain computing costs used in qualified research may potentially be included, depending on the nature of the arrangement and use. Software companies should distinguish development and experimental computing from ordinary production hosting rather than treating the entire cloud bill as qualified.
Certain contract research expenses can be QREs when the underlying work and contractual arrangement meet Section 41 requirements. Companies should retain contracts, statements of work, invoices, and technical records showing what the contractor actually performed.
Start with the projects where your engineering team had to figure something out.
Look for development where the team did not know the appropriate architecture, method, algorithm, configuration, or technical design at the beginning. Then identify the alternatives it evaluated and the tests it performed to find a solution.
From there, connect the qualifying activities to employee wages, contractors, computing costs, and other potential QREs.
That creates a much stronger foundation than simply taking total engineering spend and applying an "R&D percentage."
TaxTaker helps software companies identify qualified research, calculate QREs, document technical projects, and prepare the R&D credit in coordination with their CPA.
Book a call with TaxTaker to see which parts of your software development may qualify.
.png)
Rachel Darrough is a Sr. R&D Manager with nearly 10 years of experience conducting federal and state R&D tax credit studies across various industry types, e.g., manufacturing, software, engineering, and construction. Rachel received a Bachelor's Degree in Managerial Finance and brings a strong technical foundation to evaluating qualified research activities, technical uncertainty, and experimentation under IRC §41. At Tax Taker, Rachel manages R&D engagements by collaborating with technical and finance teams to identify qualified expenditures, substantiate eligibility, and optimize credit outcomes. She applies an analytical approach to documentation and methodology while ensuring compliance with IRS guidance. Rachel is committed to helping clients leverage innovation-driven incentives to reduce tax liability and reinvest in continued R&D.
.svg)
