Internal-Use Software: The High Threshold Test

Software you build for your own back office can still earn the R&D credit, but it has to clear a higher bar than the product you sell. Under Treas. Reg. §1.41-4(c)(6), software developed primarily for your own general and administrative functions - finance, HR and support services - is internal-use software (IUS). It qualifies only if it passes the four-part test and a three-part high threshold of innovation test: the software must be innovative, its development must involve significant economic risk, and it must not be commercially available. Software you sell or license, or build so customers and other third parties can interact with you, is not internal-use software at all.

The current rules were finalized in October 2016 (T.D. 9786) and apply to tax years beginning on or after October 4, 2016. Here is how they work, using the regulation’s own examples.

What counts as internal-use software

The test is about function. Software is developed primarily for internal use if it is developed for use in general and administrative functions that facilitate or support the conduct of your business. The regulation names three groups:

Financial management - accounts payable and receivable, inventory management, budgeting, cost accounting, financial reporting, general ledger, internal audit, risk management and tax.
Human resources management - recruiting, hiring, training, assigning personnel, personnel records, payroll and benefits.
Support services - data processing, facility services, graphic services, marketing, legal, government compliance, printing and publication, and security.

Two details catch people out. First, software you build primarily for the internal use of a related company in your §41(f) controlled group counts as internal use too. Second, the classification is fixed by your intent and the facts at the beginning of development. Software is not IUS just because you test it internally before you sell it. If you later improve an internal tool so you can sell it, the improvements are treated as separate software that is not internal use. The reverse also holds.

In the regulation’s examples, a self-insurance reserve tool, an employee pay-stub portal, a restaurant’s informational website (marketing is a support service) and data-migration code for a new ERP system are all internal-use software.

What is not internal-use software

Software is not developed primarily for internal use if it is not built for those functions. The regulation gives two main examples:

software developed to be commercially sold, leased, licensed or otherwise marketed to third parties; and
software developed to let you interact with third parties, or to let third parties initiate functions or review data on your system.

That is why customer-facing SaaS sits outside the IUS rules. In Example 9, a cloud provider’s CRM, sales automation and accounting applications, used online by its customers, are not internal use. Neither is a manufacturer’s website where customers order products and track orders (Example 7), or an ad-funded photo app and the interface advertisers use to bid for placement (Example 8).

One trap sits in the definition of “third party.” A vendor that uses your system to support your own administrative function is not a third party for this purpose. In Example 6, a portal that lets suppliers check your inventory and report shipments is still internal-use software, because it serves your inventory management.

For a software company, then, the IUS question is mostly about the back office: billing and revenue tooling, internal analytics, sales operations and HR integrations. Product engineering is analyzed under the ordinary rules - our SaaS and software industry page and what actually qualifies for SaaS cover that side.

Three cases where the high threshold test does not apply

Even when software is internal, the regulation switches off the extra test in three situations (Treas. Reg. §1.41-4(c)(6)(ii)):

Software for use in qualified research. Internal software developed for use in an activity that itself is qualified research (other than developing the software itself), such as a simulation tool your engineers use in qualifying development.
Software for a qualifying production process. Internal software developed for use in a production process that itself meets the four-part test, such as control software for a new manufacturing process you are developing.
Hardware and software built as one product. A new or improved package of hardware and software developed together, where the software is integral and you use the package directly to provide services. In Example 1, a telecom company’s switching hardware and the software that starts and ends calls are tested as a single product.

These exceptions remove the extra layer, not the base one. The four-part test still applies.

The high threshold of innovation test, part by part

Internal-use software that does not fit an exception must satisfy all three parts of Treas. Reg. §1.41-4(c)(6)(vii):

Innovative. The software would produce a reduction in cost, an improvement in speed or another measurable improvement that is substantial and economically significant if the development succeeded. The regulation calls this “a measurable objective standard, not a determination of the unique or novel nature of the software.” You do not need a first-of-its-kind system. You need an improvement that matters to the business, and a way to measure it.
Significant economic risk. You commit substantial resources, and there is substantial uncertainty, because of technical risk, that those resources will be recovered within a reasonable period. The regulation says this requires a higher level of uncertainty than ordinary research. The question is not whether the result can ever be achieved. It is whether it can be achieved in time to recover the investment. The risk must be technological, and it must exist at the start.
Not commercially available. You cannot buy, lease or license software and use it for the intended purpose without modifications that would themselves be innovative and involve significant economic risk.

Two more rules shape the test. It looks only at the results you anticipated at the beginning of development, apart from any hardware changes. And “the implementation of existing technology by itself is not evidence of innovation,” although using existing technology in new ways can be, if it resolves substantial uncertainty.

Who passes and who fails: the regulation’s examples

The four worked examples at the end of §1.41-4(c)(6) show where the line sits.

Example	Project	Result	Why
15	Merge separate HR applications into one employee-centric system	Passes	No commercial product met the requirements, older technology forced a new database architecture, and the company could not predict whether it would finish in time to recover its investment.
16	Rewrite a legacy mainframe application in object-oriented code on client/server	Fails	Big expected savings and nothing commercial fit, but the company was certain it could overcome the technical problems in a reasonable period. It was only unsure of methodology.
17	Run internal computations on idle employee PCs	Passes	No commercial product did it, the savings were substantial, and scheduling jobs across thousands of machines carried real technical risk to payback.
18	Interface software joining an old system to a new ERP	Fails	No commercial product and an uncertain design, but the company knew that with reasonable time to experiment it would find a design and recover its investment.

The lesson is in the two failures. Uncertainty about design is enough for the ordinary four-part test. It is not enough for internal-use software. The high threshold test wants genuine doubt, rooted in the technology, about whether the project pays back in time. Many ERP rollouts, CRM customizations and internal dashboards will not have that.

Dual-function software and the 25% safe harbor

Some software serves your administrative functions and third parties at once. The regulation calls it dual-function software and presumes it is internal use. There are two ways to recover part of it (Treas. Reg. §1.41-4(c)(6)(vi)):

Carve out a third-party subset. Elements that only let you interact with third parties, or only let third parties initiate functions or review data, are not internal use and skip the high threshold test.
Use the safe harbor for what remains. You may include 25% of the qualified research expenses of the remaining dual-function software without the high threshold test. Two conditions apply. The research must be qualified research under §41(d), setting the IUS exclusion aside. And third-party use must be reasonably anticipated to be at least 10% of the software’s use, estimated with an objective, reasonable method used in your industry, such as processing time, data transfer or the number of user interface screens.

The regulation’s own numbers (Example 14) show the arithmetic. A company spends $50,000 on research, half on a third-party subset and half on a remaining dual-function subset with 15% anticipated third-party processing time. The $25,000 subset can count in full if it qualifies. The other $25,000 contributes 25%, or $6,250. In Example 13, anticipated third-party use is only 5%, so the safe harbor is unavailable, and that software must pass the high threshold test or be left out.

How the IUS rules sit on top of the four-part test

The order of operations matters:

Define the business component. The four-part test applies separately to each one (§41(d)(2)).
Classify the software as of the start of development: not internal use, internal use, dual-function, or excepted.
Apply the right test. Internal-use software needs the four-part test, no other §41(d)(4) exclusion, and the high threshold test.
Compute QREs - wages, supplies, computer rental and contract research - only for what survives.

The classification now shows up on the return. The Instructions for Form 6765 (revised December 2025) ask, for each software business component reported in Section G, whether it is internal-use, dual-function, non-internal-use or excepted. Section G is required for tax years beginning after 2025, with exceptions for qualified small businesses electing the payroll credit and for smaller filers claiming on an original return. Our Form 6765 guide walks through the sections.

What to document before an internal build starts

Every part of the test is measured at the beginning of development, so the evidence you create at kickoff carries the most weight:

Who the software serves and which function it supports, in writing, before the work begins.
The business case, with the expected cost or speed improvement quantified.
A market scan showing why commercial products could not do the job without substantial, risky modification.
The resources committed: budget, headcount and timeline.
A technical risk memo naming what could stop the project from paying back in time.
For dual-function software, the method and estimate behind the third-party share of use.

Then keep the usual engineering record: design documents, tickets, test results and rejected alternatives. In a Ricerca study, software components are screened for internal-use status as part of the §41(d)(4) exclusion review, and R&D experts make the final qualification call. Your CPA or tax preparer signs and files the return.

FAQ

Is our SaaS product internal-use software?

Generally no. Software developed to be sold, leased, licensed or otherwise marketed, or to let customers interact with you, is not internal-use software. The internal tooling around your product may be a different story.

Are internal developer tools internal-use software?

It depends on what they support. Software developed for use in an activity that is itself qualified research falls under an exception to the high threshold test. Tooling that supports general data processing or other administrative functions is internal-use software, and data processing is on the regulation’s list of support services.

Can an ERP or CRM implementation qualify?

Rarely. Configuring commercial software is not research, and custom integration code is internal-use software that must pass the high threshold test. Example 18, an ERP interface project, fails because the company expected to recover its investment in a reasonable time. A project with real technical risk to payback, like Example 15, can pass.

When did these rules take effect?

The final regulations apply to tax years beginning on or after October 4, 2016. Earlier years have transition rules.

For the credit fundamentals, start with the R&D tax credit guide, or put rough numbers through the R&D credit calculator.

Sources

IRC §41 - Credit for increasing research activities (U.S. House, Office of the Law Revision Counsel)
Treas. Reg. §1.41-4 - Qualified research, including §1.41-4(c)(6) on internal use software (eCFR)
T.D. 9786 - Credit for Increasing Research Activities, 81 FR 68307 (October 4, 2016) (Federal Register)
IRS - Instructions for Form 6765 (revised December 2025)

Internal-Use Software and the R&D Credit: The High Threshold Test