Software your company sells, leases or licenses to customers is tested like any other business component under the ordinary section 41 rules. Software your company builds for its own back-office operations is treated as internal use software and has to clear a second, higher standard on top of those rules, called the high threshold of innovation test. Most disputes in software claims come down to which category a project belongs in, and a good deal of software that companies assume is caught by the harder test is not internal use software at all.
What Counts as Internal Use Software
Software is internal use software if it is developed primarily for use in the company’s own general and administrative functions. Those functions are defined narrowly: financial management, human resource management, and support services such as data processing, facilities, marketing, legal and compliance.
The determination is made at the start of development, on intent. It depends on what the company intended and the facts and circumstances at the beginning of the project, not on how the software ended up being used.
Software developed to be sold, leased or licensed is not internal use software. Neither is software that enables the company to interact with third parties, or that allows third parties to initiate functions or review data on the company’s systems. Customer portals, order interfaces and self-service account tools generally sit outside the definition, so they escape the high threshold test but remain subject to the ordinary section 41 requirements and exclusions, including the four-part test.
One definitional trap is worth knowing. A third party here does not include anyone using the software to support the company’s own general and administrative functions. A vendor logging into an inventory system to manage supply is supporting the company’s operations, so that access does not take the software out of the internal use category.
The Three-Part High Threshold of Innovation Test
Where software is internal use software, the development qualifies only if it satisfies the four-part test and, in addition, all three of the following.
Innovative. The software is intended to deliver a measurable improvement, such as a reduction in cost or an improvement in speed, and that improvement must be substantial and economically significant. The standard is the intended result, not whether it was achieved.
Significant economic risk. The company commits substantial resources to the development and there is substantial uncertainty, because of technical risk, that those resources will be recovered within a reasonable period. Ordinary budget or schedule risk is not enough. The uncertainty has to arise from technical risk and be substantial enough to put recovery of the committed resources in doubt. The company does not have to show it was uncertain whether the result could ever be achieved.
Not commercially available. The software cannot be purchased, leased or licensed and used for the intended purpose without modifications that would themselves satisfy the innovation and economic risk requirements. Buying an off-the-shelf product and configuring it does not qualify. Buying one and rebuilding substantial functionality may.
All three must be met. Two out of three is a failed claim.
Software That Is Excluded From the Definition
Three categories of software are not required to satisfy the high threshold test even though they are used internally. Companies routinely apply the harder standard to these by mistake and abandon claims they could have made.
| Category | Example |
| Software used in an activity that constitutes qualified research | Simulation or modeling tools built to run the company’s own R&D |
| Software used in a production process that itself meets the section 41(d)(1) requirements | Control software for a qualifying manufacturing process |
| Software that is an integral part of a hardware and software package developed together as a single product | Embedded firmware in a device the company uses to deliver services |
The production process exception carries a condition. It reaches software used in a production process to which the section 41(d)(1) requirements are met, so the underlying process has to qualify. Where it does, software written to run that process escapes the high threshold test, a materially easier position than the one applying to an internal accounting system.
Dual Function Software and the Safe Harbor
Much modern software does both jobs. A single platform may run internal workflow and also let customers check their orders. The regulations handle this in a fixed sequence, and the order matters.
First, identify a third-party subset. If a subset of the software’s elements only enables interaction with third parties or allows third parties to initiate functions or review data, that subset is not internal use software and is tested on the four-part test alone.
Second, treat the remainder as internal use. Whatever is left after the third-party subset is carved out is the dual function subset, presumed to be internal use software subject to the high threshold test.
Third, consider the safe harbor. Where the company cannot identify a third-party subset, or has one and still has a dual function subset left over, it may include 25% of that subset’s qualified research expenses, provided the activities are qualified research and third-party use is reasonably anticipated to be at least 10% of the subset’s use.
The safe harbor is an option rather than a requirement, and it is applied after the attempt to identify a third-party subset rather than instead of it. The safe harbor is tested using an objective, reasonable estimate formed at the beginning of development. If reasonably anticipated third-party use is below 10% at that point, the 25% safe harbor does not apply, so the expectation and the method used to estimate it should be documented contemporaneously.
Documenting Innovation, Economic Risk, and Availability
Each limb calls for a different kind of evidence, and none of it is easy to assemble after the fact.
For innovation, keep the business case: the baseline being improved on, the target improvement, and why it was economically significant. A project charter written before development began is worth more than a description written two years later.
For economic risk, record what was technically uncertain at the outset and what resources were committed against it. Rejected design alternatives, failed prototypes and architectural decisions revisited under test are the evidence that matters.
For commercial availability, keep the build-versus-buy analysis. Vendor evaluations and the reasons available products were rejected go to the third limb and usually sit in a procurement file already.
Because the determination is made on intent at the outset, contemporaneous records carry disproportionate weight here. Our guide to documentation for R&D tax credits covers the wider record-keeping picture.
If your company develops software and has not tested which projects fall inside the internal use definition, that assessment usually finds more qualifying work than expected. You can see if you qualify, estimate the credit with our R&D tax credit calculator, or read about our R&D tax credit services.
Frequently Asked Questions
Is software we sell to customers subject to the high threshold test?
No. Software developed to be sold, leased or licensed to third parties is not internal use software, so the high threshold test does not apply. It still has to meet the ordinary section 41 requirements and avoid the other statutory exclusions. The higher standard applies to software developed primarily for the company’s own general and administrative functions.
What counts as a general and administrative function?
Financial management, human resource management, and support services such as data processing, facilities, marketing, legal and compliance. Software supporting these functions is internal use software. Software supporting qualified research, or a production process that itself meets the section 41(d)(1) requirements, is not.
How does the 25% safe harbor work?
Where software serves both internal and third-party purposes, the company first tries to identify a subset that only serves third parties. If a dual function subset remains, 25% of its qualified research expenses may be included, provided third-party use is reasonably anticipated to be at least 10% of that subset’s use.
Does a customer portal count as internal use software?
Generally no. Software that enables the company to interact with third parties, or allows third parties to initiate functions or review data, falls outside the internal use definition. A portal serving only vendors who support the company’s own administrative functions is a different case.
What is the hardest part of the innovation test to prove?
Significant economic risk. It requires substantial uncertainty, arising from technical risk, that the resources committed will be recovered in a reasonable period. Commercial or schedule uncertainty does not satisfy it, though you do not have to show the result might never have been achievable. Contemporaneous records of the technical uncertainty are what carry it.
This article provides general information about federal tax rules and is not tax advice. Speak with your tax adviser about your specific circumstances.
