Does Software Development Qualify for the R&D Tax Credit?

The R&D tax credit covers software development under the same statute as any other research, but the regulations sort software into categories before the usual test applies. Software you sell, license or host for customers, and software that outsiders use to deal with you, face the ordinary four-part test. Internal use software, built for your own back office, faces an extra three-part test that other software does not have to meet. Cloud computing costs, developer wages and the section 174A deduction each have rules of their own.

This guide works through those rules with the examples the Treasury regulations use for software. The four-part test itself is explained in R&D tax credit requirements, and what the credit is worth is in the R&D tax credit guide.

Which test applies to your software

The first question is what the software is for, judged by your intent and the facts at the beginning of development under Treas. Reg. 1.41-4(c)(6)(v). Later use does not change the answer, except that improvements made later with a different purpose are judged separately.

These categories match the software types Form 6765 asks for in Section G, column 49(e). The December 2025 instructions split them further: dual function software is reported with no third-party subset identified, with a subset identified, or with the 25% safe harbor applied; excepted software is reported by which of the three exceptions applies; and software that is not internal use is reported as marketed to third parties, used internally outside any back-office function, or built to interact with third parties.

What the 2016 final regulations settled

The current internal use software rules come from T.D. 9786, published in the Federal Register on October 4, 2016, and apply to tax years beginning on or after that date. The preamble explains several choices that still decide claims:

• Back office means a closed list. Internal use is limited to financial management, human resources management and support services. Treasury kept inventory management, marketing, legal services and government compliance on that list over objections, saying those functions support day-to-day operations in any industry and that their benefits to outsiders are collateral.
• Hosted software counts as marketed. A commenter asked Treasury to add the word “hosted.” Treasury answered that “otherwise marketed to third parties” already covers software whose functions are provided to customers without transferring a copy, and added Example 9, a cloud provider’s customer applications, to show it.
• Function beats label. Treasury declined to write a special rule for connectivity software or middleware. Software that does not serve a back-office function is not internal use, and software that connects, say, payroll software to a budgeting system is internal use because of what it serves.
• Outsiders are defined narrowly. A third party is anyone outside your controlled group under section 41(f), and vendors who use your software to support your own back-office functions do not count as third parties for this purpose.
• The start of development decides. Commenters asked to judge software by how it is used once released. Treasury refused, reasoning that the credit is meant as an incentive to do research, not an unanticipated reward, and kept the determination at the beginning of development.

How the regulations classify ten software projects

Treas. Reg. 1.41-4(c)(6)(viii) gives 18 examples. These ten decide which side of the internal use line a project falls on. The regulation adds that no inference should be drawn from them about whether the four-part test is met.

Example 4 surprises people. A website that lets the public read general information is still internal use when it was built for advertising, because marketing is a support service. Compare Example 7, where customers search the company’s data, place orders and track them: that site was built so outsiders could start functions and review data, which takes it out of internal use.

Dual function software and the 25% safe harbor, in numbers

Software built for both the back office and outside users is presumed internal use. Examples 11 to 14 of the regulation work through the options on the same facts: $50,000 of research expenditures for one piece of software.

• A third-party subset you can identify. If half the expenditures belong to elements that only serve outside users, that $25,000 escapes the presumption and is tested under the four-part test alone (Example 11).
• No subset, but at least 10% outside use. If the company cannot isolate a subset but, using an objective method at the start of development, expects outside use to be 15% of the software’s use, it may count 25% of the $50,000, or $12,500 (Example 12).
• Under 10% outside use. At an expected 5%, the safe harbor is unavailable, and the software counts only if it passes the high threshold of innovation test (Example 13).
• Both at once. With a $25,000 third-party subset and a remaining $25,000 whose processing time is expected to be 15% outside use, the company may count the $25,000 plus 25% of the other $25,000, or $6,250 (Example 14).

The safe harbor is optional. Treasury described it in the preamble as a benefit for taxpayers who cannot identify a third-party subset, and one that anyone who finds it too burdensome can simply skip, at the price of facing the high threshold of innovation test instead.

The high threshold of innovation test in practice

Internal use software must be innovative, involve significant economic risk, and not be commercially available. In the regulation’s examples, economic risk is the part that decides the outcome. Under Treas. Reg. 1.41-4(c)(6)(vii)(C), it requires substantial resources and substantial uncertainty, because of technical risk, that those resources would be recovered within a reasonable period, and that uncertainty must be greater than the four-part test requires and must exist at the start. The question is not whether the result can ever be achieved, but whether it can be achieved in time to recover the investment. The regulation also says that implementing existing technology is not by itself evidence of innovation, while using it in new ways can be, if that resolves substantial uncertainty.

The failing examples have one fact in common: the company expected to solve the problem and recover its investment within a reasonable time. Uncertainty about the appropriate methodology (Example 16) or the right interface design (Example 18) can satisfy the ordinary uncertainty requirement, but it is not the significant economic risk this test demands.

What makes software work a process of experimentation

Whatever category the software falls in, the development work itself has to be a process of experimentation. Two regulatory points narrow that for software. Using computers to store, process or distribute data does not by itself show that qualified research took place (Treas. Reg. 1.41-4(a)(7)). And six examples in Treas. Reg. 1.41-4(a)(8) separate choosing from experimenting:

Examples 7 and 8 both build load-balancing software. In one, the team picked an approach without evaluating or testing alternatives; in the other, existing algorithms could not handle the environment, so the team designed alternatives and tested them systematically.

Exclusions that hit software teams

• Bugs in released software. Debugging flaws is one of the activities the regulations treat as occurring after commercial production, so defect fixing once a version is ready for use does not count. A new project to build a new or improved version starts fresh as its own business component.
• Customer customization. In Treas. Reg. 1.41-4(c)(10), Examples 3 to 5, a developer adapting its licensed accounting program to one customer’s requirements is doing excluded adaptation. The customer’s payments for that work are not contract research, and if the customer’s own staff do the adapting, their wages do not count either.
• Client-funded builds. A development shop paid for work whether or not it succeeds, with the client taking exclusive rights to the code, is treated as fully funded; the client, not the developer, may count 65% of the fee. The requirements guide covers the funding rules.

Developer wages and other software costs that count

Under section 41(b)(2), developers’ wages count for time spent engaging in qualified research, directly supervising it at the first line, or directly supporting it, using the income tax withholding definition in section 3401(a). A developer whose wages allocated to qualified services are at least 80% of the year’s wages counts in full under Treas. Reg. 1.41-2(d)(2); below that, only the share of wages tied to qualified services counts. A director above the engineering managers who direct the work does not count as a direct supervisor, even with an engineering background.

Outside developers count through contract research: generally 65% of what you pay, if the agreement came before the work, the work is done on your behalf, and you owe the fee whether or not it succeeds. The regulation’s own illustration fits software closely: a company doing in-house research pays a computer services firm $100x to build software for analyzing its research results, and $65x counts because those services would have been qualified services if employees had done them (Treas. Reg. 1.41-2(e)(5), Example 5). Work done outside the United States never counts, and for a contract performed partly abroad only 65% of the U.S. portion does.

For software teams, the supply category is narrow. The IRS audit guide on qualified research expenses notes that license fees are not tangible property and so are not supplies, and computers you buy are depreciable property, which is never a supply. Which costs belong in each category, and how they flow to Form 6765, is covered in qualified research expenses.

Cloud computing and the computer rental rule

The statute has one category for paying someone else for computing power. Section 41(b)(2)(A)(iii) counts, “under regulations prescribed by the Secretary,” amounts paid to another person for the right to use computers in the conduct of qualified research, reduced to the extent you or your controlled group receive payments for renting out substantially identical property. The regulation, Treas. Reg. 1.41-2(b)(4), speaks of time-sharing computers and sets three conditions:

1. The computer is owned and operated by someone other than you.
2. It is located off your premises.
3. You are not its primary user.

The Form 6765 instructions for line 44 and Section G column 55 repeat those conditions in shorter form. Neither the regulation nor the instructions mention cloud services by name, so each arrangement is measured against the three conditions on its facts. Two limits apply regardless. Only use in the conduct of qualified research can count, so the bill for servers running your released product for customers is not research use. And the cost has to be split out: records that tie cloud accounts or tagged resources to the research projects they served are what let a claim include any of it.

Software development costs under sections 174 and 174A

The deduction side is simpler than the credit. Section 174A(d)(3) treats any amount paid or incurred in connection with developing any software as a research or experimental expenditure, and section 174A(a) allows domestic amounts to be deducted in the year paid or incurred for tax years beginning after December 31, 2024. A business can instead elect to amortize them over at least 60 months. That treatment covers all software development, including internal use software that could never pass the high threshold of innovation test. Software developed outside the United States is foreign research, which section 174 still amortizes over 15 years.

The two regimes meet in section 280C(c): unless you elect the reduced credit on a timely original return, the 174A deduction is reduced by the credit. For tax years beginning in 2022 through 2024, software costs were capitalized and amortized over five years (15 if developed abroad); the section 174 guide covers what can be done with those unamortized balances.

Software startups: using the credit before a profit

A software company that is not yet paying income tax can still get value from the credit. A qualified small business, one with under $5 million in gross receipts for the year and no gross receipts before the five-tax-year period ending with that year, can elect to apply up to $500,000 a year of the credit against employer payroll taxes under section 41(h). The election must be made by the due date, including extensions, of the originally filed return. The small business guide covers how the offset works each quarter, and research credit not elected against payroll tax stays an income tax credit that can carry forward, as the carryforward guide explains.

Records a software claim needs

Software claims are judged project by project, so the file should be too. For each business component: whether it was built for sale, for outside users or for the back office, and the evidence of that intent at the start (roadmaps, customer commitments, architecture documents); the technical uncertainty and the alternatives tried, which version control, design documents, tickets and test results can show; and who worked on it and for how long. For tax years beginning after 2025, unless an exception applies, Form 6765 Section G reports each major component’s type, software classification and costs. The documentation checklist lists the records, and established companies that missed the credit in open years can pursue it through Tax Planning.

Sources: 26 U.S.C. 41; 26 U.S.C. 174A; 26 U.S.C. 174; 26 U.S.C. 280C; Treas. Reg. 1.41-4, including the internal use software rules in (c)(6) (eCFR); Treas. Reg. 1.41-2, qualified research expenses (eCFR); T.D. 9786, 81 FR 68299 (October 4, 2016), final internal use software regulations; IRS, Instructions for Form 6765 (Rev. December 2025); IRS, Audit Techniques Guide: Qualified research expenses. Rules and regulation examples checked against these sources on September 25, 2026. This is general information, not tax advice for your situation. Tax services are provided by licensed tax professionals under a separate engagement agreement. BEG does not provide tax advice.