Internal Use Software R&D Credit Rules: What TD 9786 Changed for SaaS and Startups

Somewhere in the tax code, buried in Section 41, there’s a rule that looks directly at the software your team wrote and asks a surprisingly pointed question: does this code run the company, or does it run the product? That single question decides whether your engineering budget gets a credit worth 6 to 10 percent of qualifying spend, or gets hit with a three-part “high threshold of innovation” test that most teams assume they’ll fail. And here’s the counterintuitive part: for a lot of the software people actually build, that scary test never even applies.

The rules we’re working with are the IRS and Treasury’s final internal-use software regulations, TD 9786, published October 4, 2016. If you’ve read other coverage, you’ve probably come away thinking the IRS built a wall around software credits. The real story is better. The 2016 regs actually narrowed what counts as internal-use software, gave startups a path to turn credits into cash through payroll taxes, and, most underreported of all, flipped who has to prove what.

If your code sits outside three specific back-office buckets, you’re not fighting the innovation test at all. Here’s how to parse it the way an engineering team would: as a classification pass over what you actually shipped, and for whom.

Why internal-use software gets special treatment under Section 41

What changed between the proposed and final internal-use software regulations comes down to three things: a rewritten definition of what’s not internal-use software, a restructure around three situations that fall entirely outside the IUS rules, and a clarification that the economic-risk test cares about the level of uncertainty, not its type. The final regs also dropped a line about “revolutionary discovery,” cleaned up dual-function software rules, and set effective dates with transition relief. That’s the patch list. Everything else is mostly the January 20, 2015 proposed regs (REG-153656-03) carried forward, like a release candidate that shipped with a few targeted fixes instead of a rewrite.

Quick history so the rest makes sense. The research credit itself goes back to the Economic Recovery Tax Act of 1981. Then a 1986 amendment added Section 41(d)(4)(E), which restricts credit treatment for internal-use software unless the software meets extra criteria. That exclusion has been sitting in the codebase for decades like a legacy constraint nobody dares touch, and it’s been controversial the whole time because the IRS guidance around it was vague and occasionally contradictory. It was the regulatory equivalent of debugging with incomplete docs: everyone sort of knew what the function was supposed to do, and everyone got different results.

TD 9786 was the fix. Mostly taxpayer-favorable, and, honestly kind of charmingly, the preamble even acknowledges that software technology moves fast. More on what that means for your commit history below.

What counts as internal-use software, and when the IUS rules don’t apply

Internal-use software is software developed for general and administrative functions that support a taxpayer’s trade or business, including a related party’s internal use. Separately, the IUS rules are entirely inapplicable in three situations: software built for use in qualified research, software for a production process, and hardware/software packages developed together. That’s the whole classification decision in one sentence. If your tooling exists to run R&D experiments, it’s outside IUS. If it runs a production pipeline or the factory floor, it’s outside IUS. And if you developed hardware and its software as one package, the bundle counts as one non-IUS thing, the way you’d evaluate a gadget as a gadget rather than grading its firmware separately. The first two carve-outs trace straight back to the statute, Section 41(d)(4)(E)(i) and (ii).

So what counts as G&A? Here’s the genuinely useful part: the IRS gave us an enum. It’s a closed list of three categories, and if the software’s main job isn’t in one of them, the internal-use rules just don’t reach it.

• Financial management: accounting, procurement, tax planning, investments, bookkeeping, budgeting, reporting
• HR management: talent acquisition, performance analysis, employee development, payroll, hiring, benefits
• Support services: data processing, facilities, incident management, customer service, internal systems, admin tools

That third bucket is the one that catches a lot of dev tooling. Your incident tracker and internal admin panels live here. But notice what’s not on the list: there’s no bucket for “the product.” That’s the point.

One gotcha for contractors and subsidiaries: software built mainly for a related party’s internal use also counts as IUS. The entity structure doesn’t launder the classification.

And a boundary case worth knowing: commenters argued that marketing and inventory software shouldn’t count as G&A when it produces benefits for third parties. The government’s answer was that inventory, marketing, legal, and compliance functions support day-to-day operations no matter the industry, and that any third-party benefits are collateral and secondary. Translation: the customer-facing side effect doesn’t rescue the classification. If your software genuinely does more than back-office work, though, there’s a whole separate framework for that, and it’s better news than you’d expect.

The burden-of-proof shift: software outside G&A functions is simply not IUS

Yes, software development can earn the R&D tax credit when it meets the four-part test, and software not developed for G&A functions is not internal-use software, so the innovation test never applies. That’s the sentence most coverage buries under a paragraph of dread, and it’s the most significant change in the entire final-reg package. The evidentiary question flipped: instead of proving your software was commercialized or used by third parties, you only have to show it wasn’t built for financial management, HR, or support services. That’s a much smaller proof obligation, and a much better default.

Here’s why this matters so much. Under the proposed regs, IRS examiners frequently treated software as IUS unless it was built for commercial sale or third-party interaction. Think about what that default did: your internal build tool, your deployment pipeline, your infrastructure automation, all presumed to be in the expensive category until you could prove otherwise. The final regs killed that exam position outright, which deleted the argument threads that used to eat examination time, whether third parties or employees used the software, and how much interaction happened.

Those questions got deleted, not answered. The preamble states twice, like a changelog entry confirming intent, that the regs narrow what counts as IUS.

The caveat, because there’s always a caveat: the IRS didn’t become powerless. Mixed-use software still gets the dual-function presumption, which we’ll get to below. And the preamble notes the definitions already covered hosted software, so there’s no cloud loophole either, just clarity.

The failure mode here is predictable, and it’s a pattern practitioners commonly see: teams assume customer use automatically escapes IUS, so they skip documenting what the software was actually built for. Then, on examination, there’s no contemporaneous record of intent, and a claim that would have been easy to support turns into a fight. Document the “why” at kickoff. It costs a sprint retro’s worth of effort and buys you the whole classification.

Field note: Write down the software’s purpose and intended users at kickoff — a contemporaneous record of intent is the whole classification defense.

The high threshold of innovation test, prong by prong

The high threshold of innovation test is a three-part requirement in Reg. 1.41-4(c)(6)(vii) that internal-use software must satisfy before its development counts as qualified research: innovative intent, significant economic risk, and software that isn’t commercially available. The final regs kept these standards from the proposed rules and removed a line saying a revolutionary discovery isn’t always necessary, after commenters worried it could be read against taxpayers. And the 18 worked examples in the regs, especially Examples 15 through 18, demonstrate the standard isn’t unreasonably high, including two examples where taxpayers fail the risk prong. Which, honestly, is the most useful kind of test suite: one that shows you what a fail looks like.

But before the three-part test, the baseline. Every software project, IUS or not, must pass the four-part qualified research test: permitted purpose, technological in nature, elimination of technical uncertainty, and a process of experimentation. Four checks for everyone. Three more if the software is internal-use. That’s the whole structure.

Prong 1: Innovative intent. You need a substantial, economically significant, measurable improvement, like a cost reduction or a speed improvement. Note two merciful details: the software doesn’t even have to be completed, and existing technologies applied in new ways qualify. Novel assembly of known parts still counts, which should defuse the we’re not really innovating, we just glued together known things worry. Gluing known things together to resolve real technical uncertainty is exactly the kind of engineering the credit rewards.

Prong 2: Significant economic risk. Substantial resources were committed with substantial technical uncertainty about whether they’d be recovered within a reasonable period. Plainly: you bet real money it might not work. The regs require technical risk and this economic-recovery risk together, you have to check both boxes.

Prong 3: Not commercially available. Nothing could simply be bought, leased, or licensed for the job without major modifications that themselves meet the innovation and risk bars. The gut check is simple: could you have just bought this?

Stakes, for calibration: the credit is worth roughly 6 to 10 percent of qualifying research expenditures as a dollar-for-dollar reduction, unused credits carry forward 20 years and back one, and most states stack their own version on top. If you want the arithmetic on typical percentages and worked examples, that’s covered in our piece on how much the R&D tax credit is worth.

The significant economic risk prong: level, not type, of uncertainty

The final regulations rejected the proposed restriction of substantial uncertainty to capability and methodology, which would have excluded design uncertainty. The government’s stated reason is refreshingly pragmatic: uncertainty types are hard to segregate, so the significant economic risk test should turn on how much uncertainty exists overall, rather than on which category of uncertainty it falls into. That’s a pragmatic call, and a genuinely useful one: the IRS can’t dismiss your claim anymore by asserting you only had design uncertainty, not capability or methodology uncertainty.

But keep it honest, because the bar didn’t vanish. The final regs add new text requiring a higher level of uncertainty and technical risk for IUS than for business components that aren’t internal-use software. And the preamble still cautions that research involving only design uncertainty would rarely qualify. So the bar got higher for IUS specifically, but it can no longer be gamed away from the IRS’s side by relabeling your uncertainty. A fair trade, in my view, and the way a technical team should read it: the level is what you argue, not the category.

The practical consequence is documentation-shaped, as usual. Substantial uncertainty must exist at the beginning of your activities, which means you write down why it was hard while it’s hard. Document the level of uncertainty robustly, not just its flavor. A ticket from kickoff week that says says that they don’t know if X is achievable with Y is worth more than a beautifully argued memo written after the fact.

Dual-function software: bifurcation or the 25%/10% safe harbor?

For dual-function software, the 25%/10% safe harbor lets taxpayers count 25% of the software’s qualified research expenses toward the credit when third-party use is reasonably anticipated at 10% or more, and taking it removes the internal-use presumption, so the innovation test doesn’t apply. Two numbers, one decision. For a startup weighing this against the HTI test, the tradeoff is predictability versus upside, the safe harbor is 25% for sure with no test to pass, while the HTI route can potentially include more QREs but carries the test’s risk. You can’t do both, and the stakes of that choice tie back to the bigger question of whether software development is tax deductible.

First, the setup. Dual-function software is software built for G&A functions that also lets third parties interact with it, initiate functions, or review data. The admin backend with a customer portal bolted on. The intuitive illustration is FedEx package tracking: when a customer interacts with the tracking site, that interaction isn’t internal use. A stranger using your software makes at least part of it, definitionally, not internal.

The default rule is the uncomfortable part: dual-function software is presumed IUS. You beat the presumption by carving it back, the shrink-back approach: identify the third-party subset and treat just that slice as non-IUS. Or you take the safe harbor. The safe harbor can apply to the whole product or just the dual-function subset, which is counterintuitive and useful, but it’s all-or-nothing on whatever it covers. You can’t apply it to a portion of a portion. And note, the government rejected most comments on these dual-function rules and kept them basically unchanged, so there’s no hidden workaround to discover.

If you estimate third-party use, you need an objective, reasonable method within your industry, and the regs name their examples: processing time, data transfer volume, number of UI screens. Delightfully low-tech metrics. No telemetry stack required. And the estimation should happen at the beginning of development, which connects right back to the intent-at-kickoff theme: the IRS wants the measurement timestamped where the classification gets made.

A worked example from practitioner materials, offered as illustrative rather than typical: a Salt Lake City company, operating since 2004, with 4 engineers and $200K in qualified wages, classified a billing system as dual-use and captured only the client-facing features. That yielded $20,000 in federal credits plus $20,000 in Utah credits. The filtering is the point; they didn’t claim the whole system.

The failure pattern practitioners commonly see is the mirror image: teams default to excluding the entire project when bifurcation or the safe harbor would apply. The tell is a credit study listing zero software QREs despite an active dev team. If your claim looks like that, it’s worth a second pass. For the line-by-line on what counts as a QRE in the first place, see our guide to qualified research expenses for the R&D credit.

Timing rules and the experimentation boundary: ERP, vendor selection, and what fails

ERP implementation is generally not qualified research. Configuration, business-process reengineering, and one-to-one data mapping are integration work, not invention. But custom integration software within the same ERP project can qualify as its own business component, and middleware falls under the general IUS rules with no special treatment. That’s the split: the config didn’t qualify, the custom glue code did. And because ERP systems are built to run the business rather than the product, the parts that do qualify still have to clear the internal-use rules.

The kickoff freeze. Whether software is internal-use is fixed by your intent and the facts at the beginning of development. Think of it like a git commit at project kickoff: the initial state is what gets audited. Commenters asked for flexibility or a rebuttable presumption allowing re-determination, and the IRS said no, reasoning that re-evaluating intent mid-project would be inconsistent and burdensome.

The rule is rigid on purpose. There is a symmetric escape hatch: improvements made after a change in use are treated as separate business components with the new classification. Software built for internal use and later improved for non-internal use gets that improvement evaluated as non-internal, and the reverse holds too. Example 10 addresses improvements made to existing software.

What fails and what passes the experimentation test. Many of the regs’ examples conclude there’s no process of experimentation where the taxpayer just evaluated a vendor’s product or picked among features of a chosen one. Comparison shopping isn’t research, however many vendors you demo. What does demonstrate experimentation: designing and systematically testing various algorithms. The quick version:

• Qualifies: software architecture, establishing module relationships, programming and testing, integration and regression testing, feature enhancements
• Doesn’t: routine maintenance, simple configuration, reverse engineering, vendor selection studies, compliance modifications, version upgrades, porting, data cleansing in migration

On the ERP split specifically: the regs’ shrink-back example found that most ERP implementation activities weren’t a process of experimentation, but the taxpayer’s own creation of integration software was. Here’s the pattern practitioners commonly see: a company budgets an ERP implementation, assumes none of it qualifies, and excludes even the custom integration work it paid engineers to write. The honest gaps: the regs provide no middleware-specific rule, and no examples showing how portions of ERP development could qualify, though the third-party interaction exception might let some modules through. Don’t assume ERP work always qualifies; don’t assume it never does. And none of the commenters’ suggested changes to these examples were adopted, so the examples are the examples.

Winners under the final rules, and the startup path to cash

Yes, SaaS and cloud-based software can qualify for the R&D tax credit without the innovation test when the software is developed for customers rather than G&A functions. Under Example 9 of TD 9786, cloud enterprise application software intended for sale, lease, license, or marketing to customers is not internal-use software, because it wasn’t developed for a G&A function. The government added this example after noting its existing terms already covered hosted software; it’s a demonstration, not a loophole.

The most memorable pairing in the whole framework sits right here. Example 9: cloud-based software for customers, not IUS. Revised Example 4: a restaurant’s advertising website, which is IUS, because it was built for advertising, a G&A function. Same “website” label, opposite outcomes. Marketing site equals back-office equals IUS. Function over label, every time.

That logic opened real credit opportunities for banking, insurance, brokerage, fintech, and retail. SaaS or website development that lets customers order products, review accounts, or perform functions may now qualify without the HTI test. If your software touches customers, the classification question is usually “is any of this G&A?”, not “can we survive the innovation test?”

Now the startup path, because this is where the piece pays for itself. The PATH Act of 2015 made the credit permanent and created the payroll tax offset: qualified small businesses, meaning gross receipts under $5M with a five-year claiming limit, can offset up to 50% of payroll taxes via Form 941. The AMT offset became allowed from 2016 as well. One illustrative example from practitioner materials, framed as illustrative and never typical: a pre-revenue S Corp gaming startup founded in 2016 with 15 employees and $2M in qualified wages generated roughly $200,000 in credits, of which $125,000 went toward the payroll tax offset and the rest carried forward.

The trap: the election must be made on a timely filed return. Miss the deadline and you silently forfeit the benefit. Read the requirements before you ship, in the most literal filing sense possible. The mechanics of actually claiming are in our piece on how to think through claiming the R&D credit, and if your software is developed for others, eligibility hinges on the funded-research test, essentially: who’s on the hook if it fails? Contract research counts at 65% of payments, a built-in 35% haircut.

Last, the grab-bag of things you wouldn’t guess count, which is honestly my favorite part of this whole framework. The monthly AWS reserved testing environment is claimable under the computer rent/lease provision. The daily one-hour scrum between a developer and a supervisor can qualify for both people. Even the executive assistant typing up test results counts as direct support.

Standup has a dollar value. There’s even an edge case where a new competitive requirement mid-testing forces redesign of already-tested software, and those expenses may still qualify. Scope change doesn’t automatically kill the claim.

Open questions, effective dates, and documentation strategy

What documentation does a claim need? Contemporaneous records of development purpose, the level of technical and economic uncertainty, and anticipated third-party use, all created at the start of development, because the IUS call is frozen there. Your kickoff docs are the evidence. Not reconstructed memos, not a well-argued position paper written during exam: written-at-the-time records of why the project existed and what was uncertain about it. Like backups, boring until you desperately need them.

On effective dates: the final regs apply to tax years beginning on or after October 4, 2016, with transition relief in the grace window between them: the IRS won’t challenge returns filed under either the final or proposed regulations for tax years that started before October 4, 2016 and ended on or after January 20, 2015. Requests for retroactive application were denied, so no retroactive wins there.

The spec has TODOs, and it’s worth knowing exactly where. The government never defined “substantial resources” or “reasonable time period,” and gave no method for measuring whether an improvement is “substantial” or “economically significant”, it’s all facts-and-circumstances. Undefined terms leave the measurement open, which is exactly what gives you room to argue your case.

There’s also a genuinely unaddressed edge: no guidance on base-period QRE consistency rules, and reclassifying IUS between 2014 and 2015-plus can trigger base consistency adjustment obligations under Section 41(c)(6) and Treas. Reg. 1.41-9(c)(2). Changing classifications has downstream effects the regulations never explain. Add the middleware gap from earlier and you’ve got three known gaps in an otherwise workable spec.

The ways people get this wrong, as a pattern rather than a scolding:

• Treating all internal systems as IUS without checking for third-party interaction
• Overlooking dual functionality and leaving shrink-back or safe-harbor credit on the table
• Failing to document technical uncertainty and economic risk at the time they existed
• Applying the HTI test where it isn’t actually required, leaving credit on the table out of over-conservatism

One lower-confidence flag, practitioner commentary rather than settled regulation: new for 2025, enhanced compliance reportedly requires identifying the type of software when the tax return is filed. Treat it as a new required field on the form; small ask, don’t skip it.

When does a deep-dive IUS analysis actually earn its cost? Three triggers: development spend is significant, systems mix internal and external components, or classification status is genuinely unclear. Doing the analysis properly pays twice: it maximizes credit value and it’s the audit defense.

The one-line version

Was the software built for financial management, HR, or support services? Either answer leads somewhere useful. Outside those three buckets, the innovation test never applies, and a lot of perfectly claimable engineering work has been excluded from claims it belonged in. Inside them, the ambiguity is navigable, the dual-function safe harbor exists precisely for the messy middle, and startups have a payroll-tax path that converts the credit into actual cash.

For significant costs or mixed internal/external systems, bring in a proper analysis and a tax adviser. The rules reward the teams that wrote down what they were building and why, while they were building it. Which, if you think about it, is just good engineering hygiene with a tax refund attached.

Frequently Asked Questions