What is R&D in software development?
R&D software development is the part of building software that involves genuine technical research — resolving uncertainty about whether or how something can be built, through design, experimentation and testing, rather than routine coding of a known solution. It covers new algorithms, novel architectures and hard integrations, and it is exactly the work the US R&D tax credit and Section 174 rules are built to reward when it meets the IRS four-part test.
R&D software development is the research-heavy portion of building software: the work where the team does not yet know whether, or how, something can be built, and has to find out through design, experimentation and testing. It sits apart from routine development — wiring up a known pattern, styling a screen, fixing a defect — because its defining feature is technical uncertainty at the start. When engineers prototype a new algorithm, redesign an architecture to hit a scale it has never reached, or make two systems talk in a way no documentation covers, that is R&D in software development, not just coding.
This distinction is not academic. The experimental work at the heart of building new or improved software is the same work that governments single out for tax relief, which is why "R&D" appears on engineering roadmaps and finance spreadsheets alike. For most product teams it is simply how ambitious features get built — the same experimental loop that runs through our software product engineering services, where uncertainty is resolved with spikes, prototypes and measurement before a feature is committed to. Recognising that loop as R&D is the first step to claiming the credit that rewards it.
It also helps to say what R&D in software development is not. It is not every hour an engineer spends at a keyboard. Configuring an off-the-shelf tool, entering data, writing marketing copy, or applying a solution the team already knows well are all real work, but they carry no technical uncertainty and are not research. Drawing that line clearly — which activities involved genuine experimentation and which were routine execution — is the single most important habit for both good engineering hygiene and a defensible tax position.
What is the R&D tax credit for software development?
The R&D tax credit for software development is a US federal tax incentive — the Credit for Increasing Research Activities under Internal Revenue Code (IRC) Section 41 — that reduces a company's tax bill dollar-for-dollar for qualifying research, including much of what software teams do. Because it is a credit rather than a deduction, every qualified dollar is worth far more than a simple expense: broadly, a company can recover on the order of 6–10% of its qualified research expenses in federal credit, with many US states offering their own credit on top.
It is not limited to labs, patents or big enterprises. Any US company that develops new or improved software and takes on technical risk to do so can be eligible — from a venture-backed startup building its first platform to an established firm modernising a legacy system. Startups in particular should not skip it: a qualified small business can apply up to $500,000 of the credit against payroll taxes each year (raised from $250,000 for tax years beginning after 31 December 2022), so even a pre-profit company with no income tax to offset can turn qualifying R&D into cash. If you are pricing that early build, our software development for startups guide pairs naturally with this one.
One clarification worth making early, because the terms are constantly confused: the R&D tax credit (Section 41) is different from the R&E deduction rules (Section 174) that govern how you write off the same costs. They are separate provisions that interact, and the rest of this guide keeps them clearly apart — first what qualifies, then how the two provisions work together in 2026.
Does software development qualify for the R&D tax credit?
Software development qualifies for the R&D tax credit when it passes all four parts of the IRS test under Section 41 — and a large share of real engineering work does. The four-part test is the gate every activity must clear, and each part must be satisfied for the related costs to count as qualified research expenses (QREs). The four parts are:
- Permitted purpose. The work aims to create or improve the functionality, performance, reliability or quality of a business component — here, software. Functional improvement counts; purely cosmetic or stylistic change does not.
- Elimination of uncertainty. At the start, it was uncertain whether or how the result could be achieved, or how it should be designed. Routine work where the solution is already known fails this part.
- Process of experimentation. The team used a systematic process — modelling, prototyping, trial and error, testing alternatives — to resolve that uncertainty.
- Technological in nature. The process relied fundamentally on principles of computer science, engineering or another hard science, not on aesthetics, economics or opinion.
Because the test rewards the process rather than the result, R&D does not have to succeed to qualify. A spike that proves an approach won't work, a prototype that is thrown away, an integration that is abandoned after two weeks — all can generate qualified research expenses, provided there was real uncertainty and a systematic effort to resolve it. For software teams, where discarded approaches are a normal and healthy part of finding the right one, this is a crucial point: failure is not disqualifying, undocumented work is.
Which software activities qualify (and which don't)
The clearest way to apply the four-part test is to sort your actual work into qualifying and non-qualifying buckets, because the same project almost always contains both. A new product release includes hard architectural decisions (likely R&D) and routine screen styling (not R&D); only the qualifying portion counts. The table below maps common software activities to how they usually fall — always as a starting point for judgement, not a substitute for it.
| Usually qualifies | Usually does not qualify |
|---|---|
| Designing and developing new applications or features with technical unknowns | Cosmetic or stylistic UI changes with no functional gain |
| Developing new or improved algorithms and data models | Routine bug fixes and ongoing maintenance |
| Architecting for performance, scalability or security under real uncertainty | Configuring or customising off-the-shelf software to spec |
| Building non-trivial integrations where the approach is not documented | Data entry, content population and migration of known data |
| Prototyping, spikes and systematic testing to resolve technical questions | Debugging after release for defects, and quality control alone |
| Developing internal-use software that meets the higher innovation and risk bar | Market research, marketing, training and administration |
Two edge cases trip up software companies most often. First, internal-use software — tools built for your own operations rather than to sell — must clear an additional, higher three-part test (it must be innovative, involve significant economic risk, and not be commercially available), so it qualifies less readily than customer-facing product work. Second, funded research does not count: if a client pays for the work and bears the financial risk and keeps the rights, the developer generally cannot claim the credit on it. Reading your development contracts for who carries the risk is part of the analysis, which is why it connects to the terms covered in our software development contract guide.
Section 174 vs Section 41: expensing vs the credit
Section 174 and Section 41 are two different provisions that people constantly merge, and keeping them apart is the key to understanding the 2026 landscape. Section 174 governs how you deduct research and experimental (R&E) expenditures — including software development costs — from taxable income. Section 41 is the separate R&D tax credit that reduces the tax itself, dollar-for-dollar. One is about the size of your deduction; the other is a direct discount on your bill. Most software costs that qualify as R&E under 174 are also the raw material for a 41 credit, but you must treat them under both rule-sets.
The two provisions are deliberately linked so the same dollar is not benefited twice. Under IRC Section 280C, a company that claims the Section 41 credit must either reduce its Section 174 deduction by the amount of the credit, or elect a reduced credit — historically around 79% of the full amount (reflecting the top corporate tax rate). Which choice is better is a modelling question for your tax adviser, but the principle is fixed: claim the credit and you give something back on the deduction side. Treating 174 and 41 as one thing is how companies either miss the credit entirely or double-count and invite a challenge.
What OBBBA changed for software R&D in 2026
The biggest recent change is that immediate expensing of domestic software R&D is back. The One Big Beautiful Bill Act (OBBBA), signed on 4 July 2025, added new IRC Section 174A, which restores and makes permanent the immediate deduction of domestic research and experimental expenditures — reversing the unpopular 2022 rule (from the 2017 Tax Cuts and Jobs Act) that had forced companies to capitalise and amortise those costs over five years. For software teams that had watched a year of engineering salaries turn into a slow write-off, this is a material cash-flow improvement from the 2025 tax year onward.
Two conditions matter for planning. First, the relief is for domestic work: software development performed in the United States can be expensed immediately, while foreign R&E remains subject to 15-year amortisation, and teams split across borders must allocate costs between the two. Second, there are transition rules for the capitalised 2022–2024 costs: businesses can deduct the remaining unamortised domestic R&E in full in 2025, or spread it across 2025 and 2026. A separate retroactive election let small businesses (average annual gross receipts of $31 million or less) amend 2022–2024 returns, but that filing window closed on 6 July 2026 — so for most companies the live decisions now are about 2025 and 2026, not amendments.
Two things did not change, and it is worth stating them plainly to avoid a common misconception. The Section 41 credit and its four-part test are unchanged — OBBBA reshaped the deduction under 174, not the credit under 41. And this is a US federal picture; other countries run their own, quite different schemes (for example the UK's merged R&D relief), so a multinational should analyse each jurisdiction separately rather than assume the US rules travel.
How is the R&D tax credit calculated?
The R&D tax credit is calculated from your qualified research expenses (QREs) using one of two methods, and for most software companies the qualified expenses are dominated by people. QREs fall into four categories: wages for employees performing, supervising or supporting qualified research (usually the largest by far for software); contractor costs for qualified work (claimable at 65% of the amount paid); supplies consumed in research; and, since a 2015 change, certain cloud and hosting costs for computing rented to run the R&D. Rent, capital equipment, travel and general overhead do not count.
There are two ways to turn those QREs into a credit. The Regular Research Credit is 20% of QREs above a base amount tied to a company's historic research intensity — powerful for consistent long-term R&D spenders, but complex and data-hungry. The Alternative Simplified Credit (ASC) is 14% of the QREs that exceed 50% of the average QREs from the previous three years (and 6% of current QREs if there were none in the prior three years) — far easier to compute and the common choice for younger software companies. You may compute both and claim the larger, but the ASC's simplicity usually wins for teams without a long, well-documented research history.
Because the credit scales with qualified spend, the size of a claim tracks the size of the engineering investment — which is why it is worth reading alongside real cost figures. Our software development cost benchmark for 2026 gives the underlying salary and build ranges that most QREs are made of, so you can sanity-check the order of magnitude of a potential credit.
How to claim the R&D credit for software development
You claim the R&D credit by documenting qualifying work as you do it and filing the right form with your tax return — the process is systematic, and the companies that get it right treat documentation as an engineering habit, not a year-end scramble. The steps below are the standard path.
- Identify qualifying projects and activities. Walk your roadmap and separate the work with genuine technical uncertainty from routine execution, applying the four-part test to each activity, not each project as a whole.
- Gather contemporaneous documentation. Tie the work to evidence already produced during delivery — tickets, design docs, pull requests, test results, architecture notes and time tracking. Records made as you build are far stronger than reconstructions.
- Calculate qualified research expenses. Total the qualifying wages, 65% of qualified contractor costs, research supplies and eligible cloud costs, allocating partial time where engineers split between R&D and routine work.
- Compute the credit. Run the Regular and Alternative Simplified Credit methods and take the larger, or the simpler ASC if you lack a long research history.
- File IRS Form 6765. Attach it to your business tax return; note that recent Form 6765 revisions ask for more project-level and business-component detail, so granular records matter more than before.
- Elect the payroll-tax offset if you qualify. Eligible small businesses can apply up to $500,000 of the credit against payroll taxes — the route that makes the credit valuable to pre-profit startups.
Two practical cautions. The rules are technical and the documentation standard is real, so most companies work with a specialist R&D tax adviser rather than attempting a first claim alone — this article is a map of the terrain, not tax advice for your specific facts. And the strongest thing an engineering organisation can do is make the evidence a by-product of how it already works: clear tickets, recorded design decisions and honest time allocation turn a stressful claim into a straightforward one.
Common R&D tax credit mistakes
Most weak or contested R&D claims fail in a handful of predictable ways, and each is avoidable with a little discipline during the year rather than at filing time.
- Assuming you're too small — or not "innovative enough." The credit is not for labs and patents only; ordinary product engineering with technical uncertainty qualifies, and startups can monetise it against payroll tax before they are profitable.
- Claiming whole projects instead of activities. A project mixes qualifying and non-qualifying work. Claiming 100% of a release invites challenge; claiming the experimental portion, cleanly separated, holds up.
- Reconstructing documentation after the fact. Contemporaneous records — tickets, PRs, test logs, time tracking — are far stronger than a year-end narrative written from memory.
- Confusing Section 174 with the Section 41 credit. They are different provisions with a Section 280C interaction; treating them as one thing leads to missed credits or double-counting.
- Ignoring the domestic-versus-foreign split. Only US work gets immediate 174A expensing; offshore R&E is amortised over 15 years, and mixed teams must allocate.
- Overlooking funded and internal-use limits. Client-funded work where the customer bears the risk generally can't be claimed, and internal tools face a higher bar — check before you count them.
The healthiest sign of a claim-ready engineering organisation is that none of this is special: the team already writes clear tickets, records why it chose one approach over another, and tracks time honestly — so the R&D story is simply true, and easy to show.
FAQ
What is R&D software development?
R&D software development is the part of building software that involves genuine technical research — resolving uncertainty about whether or how something can be built, through design, experimentation and testing, rather than routine coding of a known solution. It covers work such as new algorithms, novel architectures, performance or scalability breakthroughs, and integrations where the outcome is not certain at the outset. The term matters commercially because this kind of work is what the US R&D tax credit and Section 174 rules are designed to reward, provided it meets the IRS four-part test.
Does software development qualify for the R&D tax credit?
Software development frequently qualifies for the R&D tax credit when it meets all four parts of the IRS test under IRC Section 41: a permitted purpose (creating or improving the functionality, performance, reliability or quality of software), technical uncertainty at the start, a process of experimentation to resolve it, and reliance on principles of computer science or engineering. Building new features, improving performance or scalability, and integrating systems in non-obvious ways can qualify; cosmetic UI changes, routine bug fixes, configuration and simply deploying known solutions generally do not.
What is the difference between Section 174 and the Section 41 R&D tax credit?
Section 174 governs how you deduct research and experimental (R&E) expenditures, including software development costs, while Section 41 is the separate R&D tax credit that reduces tax dollar-for-dollar. After the One Big Beautiful Bill Act (OBBBA) of July 2025, new Section 174A restored immediate expensing of domestic R&E costs. The two interact through Section 280C: if you claim the Section 41 credit you must either reduce your Section 174 deduction by the credit amount or elect a reduced credit of roughly 79%, so the same dollar is not benefited twice.
Which software development activities qualify for the R&D tax credit?
Qualifying software development activities typically include designing and developing new applications or features, developing new or improved algorithms, architecting for performance, scalability or security in the face of technical uncertainty, building non-trivial integrations, and systematic testing and experimentation to resolve those uncertainties. Non-qualifying activities generally include cosmetic or stylistic UI changes, routine maintenance and bug fixes, configuration of off-the-shelf software, data entry, and post-release marketing or administrative work. Only the portion of work that survives the four-part test counts as qualified research.
How do you claim the R&D tax credit for software development?
To claim the R&D tax credit for software development you identify qualifying projects and activities, gather contemporaneous documentation (project notes, tickets, design records and time tracking), calculate qualified research expenses — mainly wages, contractor costs and cloud or supply costs tied to the work — and compute the credit using either the Regular or the Alternative Simplified Credit method. You then file IRS Form 6765 with your business tax return. Qualified small businesses can also elect to apply up to $500,000 of the credit against payroll taxes. Because the rules are technical, most companies work with a specialist adviser and keep documentation as they build, not after.
Does R&D need to be successful to qualify for the credit?
No. The R&D tax credit rewards the process of experimentation, not the outcome, so a project that fails or is abandoned can still generate qualified research expenses as long as there was genuine technical uncertainty and a systematic effort to resolve it. What matters is that the four-part test is met and that the work is documented. This is important for software teams, where prototypes, spikes and discarded approaches are a normal and qualifying part of resolving uncertainty.
Last updated 22 August 2026. This article explains US federal R&D rules (IRC Sections 41, 174/174A and 280C) as widely reported in 2026, including changes made by the One Big Beautiful Bill Act; credit percentages, thresholds and dates are directional and can change. It is general information, not tax or legal advice — confirm your position with a qualified R&D tax adviser for your specific facts.
