Which Software Development Activities Qualify for the R&D Tax Credit?

IRC Section 41 does not have a separate standard for software. The same four-part test applies: permitted purpose (the work aims to create a new or improved business component), technological in nature (it relies on computer science, engineering, or a related discipline), technical uncertainty (you did not know at the outset whether the approach would work, how to achieve the desired result, or the appropriate design), and process of experimentation (you systematically evaluated alternatives through modeling, simulation, or trial and error). Software development qualifies when your engineers face genuine technical challenges, not just business requirements.

Building a new product or platform from scratch where the technical approach is unproven almost always qualifies. Developing proprietary algorithms, data structures, or system architectures that go beyond combining existing libraries qualifies. Performance optimization work, where you are trying to meet specific latency, throughput, or scalability targets that require experimentation with different approaches, is eligible. Building integrations with third-party systems where the APIs are poorly documented, the data formats are inconsistent, or the failure modes are unpredictable often involves enough uncertainty to qualify. Developing automated testing frameworks for complex distributed systems is another common qualifying activity.

Routine bug fixes where the solution path is obvious are excluded. UI design work that is aesthetic rather than technical does not qualify. Copying or adapting existing open-source software without meaningful modification is not R&D. Data entry, content creation, and business process configuration using established tools do not meet the bar. Moving an existing application from one platform to another using well-documented migration paths is generally not qualifying unless you encounter significant technical hurdles specific to your system.

Most engineers split their time between qualifying and non-qualifying activities. The IRS expects a reasonable allocation, not 100% across the board. We typically work with engineering managers to estimate the percentage of time each developer spends on qualifying work during each quarter. The right percentage varies by team and by year, and an allocation near 100% invites questions. The allocation should be supportable, meaning you should be able to explain why a particular developer was at 60% rather than 80%. Sprint data, Jira tickets tagged by project type, and time tracking tools like Toggl or Harvest provide the evidence auditors look for.

A hypothetical SaaS company with eight US-based engineers paid $170,000 each shows how allocation turns into a credit.

• Two platform engineers rebuilding the data pipeline for a 10x throughput target spend about 85% of their time on that work. At 80% or more, the substantially all rule lets all of their wages count: $340,000.
• Four product engineers split time between new features with real technical uncertainty (about 50%) and routine work: $680,000 x 50% = $340,000.
• Two engineers on support, bug fixes and on-call spend about 10% on qualifying work: $34,000.
• Development and staging cloud costs: $36,000.

Total QREs: $750,000. If QREs for the prior three years were $400,000, $450,000 and $500,000, the average is $450,000 and half of it is $225,000. The alternative simplified credit is ($750,000 minus $225,000) x 14% = $73,500.

Notice that the company does not claim 100% for anyone outside the platform team. That restraint is what makes the rest of the claim believable.

Software you sell, license or let customers use on your system is not internal-use software, so most SaaS development only needs to pass the standard four-part test. Treasury Regulation §1.41-4(c)(6) treats software as internal-use when it is developed primarily for your own general and administrative functions, such as finance, HR or payroll systems.

Internal-use software can still qualify, but it must also be innovative, involve significant economic risk, and not be commercially available for your purpose. Building a custom billing reconciliation tool for your own finance team usually fails the third prong because commercial alternatives exist.

Mixed projects are common. A SaaS company that builds a new customer-facing analytics feature and an internal admin console in the same quarter should track them as separate business components, because they face different tests.

Agile teams do not need lab notebooks; they need to keep the artifacts they already create and connect them to projects. Records that work well:

1. Epics or projects tagged as research candidates when they are opened, with a one-line statement of the technical uncertainty.
2. Design documents and architecture decision records that list the options considered and why some were rejected.
3. Pull requests and branches for prototypes that were abandoned, not just the code that shipped.
4. Benchmark or load-test results tied to the target the team was trying to hit.
5. A quarterly time allocation by engineer and project, approved by the engineering manager.

Five minutes of tagging when an epic is opened saves hours of interviews when the credit study is prepared.

Pre-profit software companies can use the credit now through the payroll tax election under §41(h). A company with gross receipts under $5 million for the year and no gross receipts before the five-year period ending with that year can apply up to $500,000 a year against the employer share of Social Security and Medicare taxes, for up to five years.

The election is made on Form 6765 with a timely filed return, including extensions, and the credit is claimed on Form 8974 with Form 941 starting the quarter after filing. It cannot be made on an amended return, so decide before the filing deadline.

In the example above, the $73,500 credit would be used against the employer's 6.2% Social Security tax first and then the 1.45% Medicare tax. With $1,360,000 of engineering payroll, employer Social Security tax alone is about $84,320 a year, so the credit would be absorbed within roughly the first year after filing. Remember that the gross receipts tests include interest income on cash you raised.

For tax years beginning after December 31, 2024, domestic research and experimental costs, which expressly include software development, are deductible in the year paid or incurred under new §174A, added by the One Big Beautiful Bill Act. The five-year amortization rule from the 2017 tax law now applies only to domestic costs from 2022 through 2024, and those remaining balances can be deducted in 2025 or split over 2025 and 2026. Research performed outside the United States is still amortized over 15 years.

The credit and the deduction interact through §280C(c): by default the §174A deduction is reduced by the credit, or you can elect a reduced credit (79% of the gross amount) and keep the full deduction. The detailed rules, including the small business retroactive election that closed on July 6, 2026, are in our Section 174 and 174A guide. This is general information as of October 2026, not tax advice for your specific facts.