R&D Tax Credit for Software Development: The IRS Audit Guide’s Risk Tiers for Coding Work

The R&D tax credit for software development is a dollar-for-dollar federal credit under IRC §41, and yes, software development can qualify, provided it passes the four-part test in §41(d). It’s been permanent since the PATH Act of 2015 (before that it kept expiring and getting revived, which sounds exhausting), and the qualified research expenses you can count are real money: wages, supplies, and contract research. But here’s the part that should make you sit up before you map your entire engineering payroll onto it: the IRS’s own software audit guide shows that most routine coding activity, including maintenance releases, vendor selection studies, and porting, usually fails the test. That guide is the closest thing we have to the IRS’s actual grading rubric for our work, and it grades harder than most founders expect.

I went down this rabbit hole recently, reading the audit guide the way I’d read a spec someone handed me at code review, and honestly it’s kind of fascinating. The IRS has opinions about debugging. It has opinions about whether choosing between WebLogic and WebSphere is research (spoiler: it is not). Over the next several sections I’ll walk you through the four-part test, the uncertainty taxonomy that decides everything, the IRS’s three risk tiers, the internal-use software trap, and why documentation now decides more claims than activity selection does.

How the R&D tax credit for software development works: the four-part test

The process of experimentation test is the main gate your dev work has to pass: under I.R.C. § 41 and Treas. Reg. §1.41-4(a)(5), substantially all of your activities must be elements of a process of experimentation aimed at creating new or improved function, performance, reliability, or quality of a business component. Note the “substantially all.” That’s a high bar, and it’s the first place sloppy claims fall over.

The full four-part test looks like this:

1. Permitted purpose: the work aims at a new or improved business component.
2. Technological in nature: the process must fundamentally rely on physical or biological sciences, engineering, or computer science. For us, computer science counts. That’s the hook for this whole audience, and it’s genuinely good news.
3. Elimination of uncertainty: you’re resolving uncertainty about capability or method (more on which uncertainties count shortly).
4. Process of experimentation: an evaluative process, applied per business component.

Two pieces of genuinely good news get buried too often. First, the test applies to each business component, and software that’s new to your company, even if it already exists elsewhere, can qualify. You don’t have to invent the next big thing; you have to run your own honest experiment. Second, you don’t need uncertainty about whether something is possible at all.

Uncertainty about the right design at the outset can be enough. If you’re design-heavy, that’s a real advantage.

The process of experimentation requirement

So what does the IRS think experimentation means? The 1986 legislative history (H.R. Conf. Rep. No. 99-841) is the origin story: experimentation means evaluating more than one alternative when the path forward isn’t yet known.

In practice that looks like a loop you already know: form a hypothesis, test it (modeling, simulation, systematic trial and error), refine or toss it. That is, almost literally, a normal dev loop. The IRS describing your dev loop back to you and calling it a tax test is one of the more delightful things I found in this document.

Here’s the checklist you can actually map work onto:

• Identify the uncertainty: what don’t you know about how this component should work?
• Identify the alternatives: could you have built it more than one way? If there was only ever one way, that’s a flag.
• Run an evaluative process: modeling, simulation, systematic trial and error, and keep the record.

What T.D. 9104 says about proving experimentation

This is the decisive legal point, and it’s where a lot of claims quietly die. T.D. 9104 (January 2, 2004) clarified the treatment of uncertainty, and the preamble’s point is blunt: merely demonstrating that uncertainty was eliminated is insufficient. The taxpayer bears the burden of showing the process, the evaluative one, the alternatives weighed. “We figured it out” is not the bar. “Here’s how we compared options” is.

And no activity, software development included, automatically counts as a process of experimentation. Writing code isn’t the test. How you wrote it is. Mere uncertainty about a component doesn’t make every hour spent on it experiment hours, even if the component itself qualifies, and claiming the wrong hours is exactly what costs people money in an audit.

Which uncertainty counts? Development vs. business vs. project

Only one kind of uncertainty counts, and it’s the load-bearing wall of this entire topic: uncertainty about what the software business component can actually do. Can this thing do what we need it to do, functionally, technically. Not “will customers like it,” not “does it fit the roadmap,” not “can we ship by Q3.”

The guide’s illustration is my favorite part of the whole document. Ask ten engineers to write a payroll program and you’ll likely get ten completely different programs. That’s real: software is design decisions all the way down. But design multiplicity alone doesn’t make something experimentation. What counts is evaluating alternatives.

Multiplicity is the condition; the evaluative process is the evidence. And configuration uncertainty by itself proves nothing: the activities you undertake to resolve it are what the IRS grades, not the vibe of uncertainty.

So before you talk to anyone about a claim, run this diagnostic on your own uncertainty list. For each one, ask what kind it is. If it’s about what the software can do, it might count. If it’s about whether customers react favorably or whether you’re competitive, that’s business uncertainty. Staff training, schedule, budget?

Project uncertainty. Neither kind meets §41(d). The IRS isn’t grading your sprint planning. Painful, but clarifying.

Why hard projects fail, and why troubled teams are often the least likely to qualify

Here’s the inversion nobody expects: the IRS’s guide, citing the Standish Group’s classic 1994 CHAOS study, concedes that most software projects fail for business and project management reasons, not because anyone failed to eliminate technical uncertainty. Incomplete requirements, no user involvement, no resources, unrealistic expectations, no executive support, no planning, sometimes the project just wasn’t needed. Sound familiar?

That means the loudest, most troubled projects, the death marches, the fire drills, are often the least likely to qualify, because their defining uncertainty was never technical in the §41 sense. The quiet team shipping an architecture nobody outside the org has tried might be sitting on a real claim while the heroic rescue project isn’t.

Some context the guide itself gives, which reads like it was written by someone who has lived this: software doesn’t wear out and can last years or decades (your COBOL is immortal, apparently). Requirements are rarely complete at the start, often conflict, and change during development, forcing redesign. And technology churn, the guide names the Internet, Java, XML, and Web Services, means developers adopting newer tech need learning time. Iteration is normal.

None of that is a red flag. None of it, alone, qualifies you either.

How real software development maps to the test: lifecycle, iteration, and the bug-fix paradox

No, routine bug fixes, maintenance releases, and enhancements generally don’t qualify, and this is the verdict that matters for anyone whose sprint board is mostly post-release tickets. But the label on the ticket is not determinative, and that nuance saves some legitimate claims. The guide is grading what you actually did, so if your pre-release bugs came up while testing hypotheses inside a genuine experimentation process, those hours may count even though the ticket says “bug fix.” Routine post-release debugging is different: the guide puts it at high risk, because it’s verification, confirming the software does what was intended, not discovery.

The lifecycle the IRS actually evaluates

The guide walks the full software lifecycle: requirements specification, design, coding, testing, performance tuning, release, maintenance, and bug fixing, with iteration. Nobody runs a clean waterfall, and the IRS knows it. Its own example: a new competitive requirement lands mid-testing and forces a redesign of already-written, already-tested code. Every dev has lived that.

The guide’s conclusion is the friendly one: iteration doesn’t disqualify you. The work inside the loop still gets graded on its own merits.

It also lists methodologies, Waterfall, Iterative, RAD, SEI, ISO 9000, Extreme Programming, Object-Oriented, to make a simple point: every project follows some approach, structured or not. Even “we just started coding” is a methodology. Methodology isn’t the test either. It maps the common-activities taxonomy (planning, requirements gathering, specs, programming, tuning and benchmarking) onto the test, and where experimentation might live inside each.

Do bug fixes and maintenance releases qualify?

Here’s the reconciliation you actually need, anchored on version numbers: a 1.1 patch is usually corrective, adaptive, or perfective maintenance reusing the same architecture and technologies, which means no new uncertainty and high risk of failing. A 2.0 that changes the architecture is a different story, and I’ll get to that in the moderate-risk section. The “1.1 vs 2.0” framing is a useful first pass, but resist turning it into a bright-line rule. The guide treats post-release fixes as a judgment call on the facts, and the ticket label doesn’t decide anything.

What was uncertain, and how did you evaluate alternatives? That’s the question.

The §41(d)(4) exclusions: why the risk tiers exist

The statute carves out whole categories from qualified research under the I.R.C. § 41(d)(4) exclusions, and the software risk tiers are mostly these exclusions wearing developer clothing. Once you see the mapping, the high-risk list stops feeling arbitrary.

• Commercial production: research after the business component reaches the point of use, meaning it meets its basic functional and economic requirements, is excluded (Treas. Reg. §1.41-4(c)(10), Examples 1 and 2). The deemed post-production activities include preproduction planning, tooling up, trial production runs, troubleshooting production equipment, accumulating production data, and debugging flaws. Yes, your launch-week firefighting doesn’t count. Once it ships, the clock changes.
• Adaptation to a particular customer’s need: customizing an existing component for a specific customer’s requirement is excluded (Examples 3 and 7). The nuance matters: building something for a specific customer alone doesn’t trigger the exclusion. The real question is narrower: did you adapt something existing, or did you solve genuine uncertainty? That’s what explains porting.
• Duplication: reproducing an existing component from physical examination, plans, detailed specs, or publicly available information isn’t research (Example 8). Clone work isn’t research. Evaluating a competitor while building your own, though, is fine; competitive analysis doesn’t automatically make your work duplication.
• The grab bag: efficiency surveys, management functions (financial data prep, training, org plans), market research including advertising and promotions, routine data collection, routine quality control, and social sciences (economics, business management, behavioral sciences, arts, humanities). The business side of the house doesn’t count, and the test wants hard science, which for us includes computer science.

So: adaptation explains why porting fails, duplication explains why reverse engineering fails, commercial production explains why post-release maintenance fails. Most high-risk categories are these exclusions in a hoodie.

The IRS’s own risk tiers: how to pre-assess your release roadmap before claiming

The guide ranks software activities into three tiers so examiners can focus limited audit resources. High risk means activities that usually fail to constitute qualified research under §41(d). Moderate risk means activities that often fail. Low risk means activities that rarely fail.

It’s triage, a priority queue for where the IRS spends its limited audit time. Understanding the reviewer’s priorities isn’t gaming the system; it’s reading the rubric before the exam, which is just good practice.

Now the honest caveats, because this guide is a well-documented fan theory, not canon. It carries no legal authority, so you can’t cite it as law. It doesn’t address the internal-use software exclusion under §41(d)(4)(E), pointing instead to the Advance Notice of Proposed Rulemaking REG-153656-03. Nothing in it stops an examiner from proposing any proper adjustment, even one tied to an activity the guidelines don’t flag as high risk.

And the whole ranking is facts-and-circumstances assistance, not a per se rule. It’s a heuristic, not a lookup table, and a screening tool, not a safe harbor.

The reader move that makes this useful: before claiming a dollar, take your actual release roadmap and locate it on the IRS’s map of software development tax rules. Is this cycle mostly 1.1 patches? That’s high risk. A 2.0 that touches architecture?

Moderate. Something that required new algorithms or a new architecture from scratch? Low risk, the good bucket. Run the mapping yourself first, and you’ll know roughly what an examiner sees.

High-risk activities: the seventeen coding activities that usually fail the IRS test

No, these seventeen activities usually fail the qualified-research test under §41(d), and the pattern to internalize up front is this: work that locates, adapts, verifies, or integrates existing capability is not experimentation, no matter how skilled it is. That’s the unifying pattern; everything below is a variation. In practice, claims built the other way look like this: a company maps an entire engineering payroll to the credit by labeling sprint work as experimentation, and the ticket history matches this catalog almost exactly. I’m not naming anyone, because the pattern is common enough that nobody needs naming.

Red flag: Mapping an entire engineering payroll onto the credit by labeling sprint work as experimentation, with no recorded qualified research expenses, is the pattern that gets challenged.

Maintenance releases

The 1.1s and 1.2s of the world: corrective maintenance (debug, diagnose, fix), adaptive maintenance (regulatory or competitive changes), and the like, with critical patches arriving more frequently for bugs and security issues. The tell is that maintenance reuses the same architecture and technologies, so there’s no new uncertainty. Analysis, debugging, reverse engineering, and testing can all be involved, and it’s real work, but it generally isn’t aimed at resolving development uncertainty through an evaluative process grounded in computer science.

Application configuration

Defining the chart of accounts, setting user counts, access privileges, picking vendor-defined options, tweaking vendor defaults with the vendor’s own tooling. Clicking through the admin panel isn’t R&D. The vendor already solved the hard part.

Reverse engineering

Examining existing programs, databases, and files to figure out how an application works, like reverse engineering a legacy app’s data interface for a new application. This feels like genuine detective work, because it is. It’s just not qualified research, per Treas. Reg. §1.41-4(c)(10), Example 8.

Vendor selection studies

Choosing between database management systems (Oracle vs. DB2), computer manufacturers (H-P, IBM, Dell), ERP suppliers (SAP, Oracle, PeopleSoft), or web portal platforms (WebLogic or WebSphere). Your bake-off spreadsheet isn’t R&D. These studies are routine due diligence; the vendors already built the things.

Debugging and routine testing

Detecting flaws and bugs is verification and validation: confirming the software was built as intended and works. It’s not directed at resolving development uncertainty, per §41(d)(4)(A) and Treas. Reg. §1.41-4(c)(2), and yes, this one stings.

Standards, device, and platform compliance

Modifying software to comply with standards, devices, or vendor platforms: code review, documentation review, reverse engineering, debugging, and, for vendor platforms, running the vendor’s validation test suite and debugging the failures. Conformance testing, not discovery.

Me-too products

Analyzing existing marketplace products for functions, features, and UI screens and building substantially similar ones. Feature-parity sprints. The technologies, training, and skills are generally available, so a skilled team has no §41 uncertainty to resolve.

Upgrades and vendor fixes

Installing new releases or hardware following vendor instructions. Even failed installs that turn into debugging the install or calling the vendor aren’t resolving development uncertainty. Following the install guide isn’t research, even when the install guide is wrong twice.

Re-hosting, porting, and language rewrites

Mainframe to PC, Windows to UNIX, COBOL rewritten in C++. Rewrites involve reverse engineering existing code for requirements and algorithms, maybe splitting large components. Hard work, known destination: generally no new architecture, and no development uncertainty in splitting programs or converting languages.

Device drivers

Vendors document device capabilities and commands (think hard disk read/write commands), and driver work targets those documented interfaces. Implementing against a spec isn’t resolving uncertainty about the spec.

Data quality and cleansing

Designing software to validate and clean data fields and keep them consistent across databases and apps. Translating EBCDIC to ASCII between a mainframe and a UNIX server, converting mm/dd/yy to mm/dd/yyyy. Date-format hell is real but known. Format-selection decisions are business uncertainties, not development ones.

Suite bundling

Building a single shared interface that launches existing apps and sets configuration or runtime options. The individual products generally aren’t modified, and the interfaces draw on available information, so there’s nothing uncertain to resolve. Wrapping existing apps in a launcher isn’t research.

Acquired-product modification

A database company acquires financial software and modifies it to run only on its own database: reviewing code for database references, reading both products’ docs, possibly reverse engineering, then modifying. The guide compares this to Y2K work: finding places to modify, not resolving uncertainty. Migrating customers and data into new structures lands here too.

Interfaces

Electronic interfaces exchanging data (inventory to warehouse, or business-to-business) and user interfaces (adding a browser front end to an existing PC tax-calculation app). You define data and transaction requirements on each end, possibly reverse engineering, then write software to match. Real work, defined destination.

Y2K program changes

The period piece: finding two-character year fields, expanding them to four characters, fixing date calculations, then running extensive testing to verify the compliant software produced the same answers as the original. Same answers is the goal, which is verification by definition (see Rev. Proc. 97-50).

Vendor extensions via user exits and APIs

Writing the calculation the spreadsheet doesn’t provide, customizing a report format, filling gaps in vendor functionality. The vendor provides well-defined interfaces, user exits and APIs, and your code must conform. Reading the docs and following them generally isn’t resolving development uncertainty.

GUI screen design

Deciding which data items and graphics appear on each screen and where. Those are business and project uncertainties (will users find it usable, does it fit the plan), and there’s typically no development uncertainty about the appropriate design or the capability and method for building the screens. The tooling is known.

Moderate-risk and qualifying counterexamples: where the facts decide

Plain porting, mainframe to PC, COBOL to C++, Windows to UNIX, usually fails: it’s adaptation, excluded under §41(d)(4). But migration that changes the architecture is where qualification becomes possible, because architecture change is precisely the kind of technical uncertainty the credit rewards. The product category never decides; whether computer-science uncertainty was resolved by evaluating alternatives does.

Functional enhancements: 2.0 releases vs. architecture changes

Major releases, the 2.0s and 3.0s and “Product 2004/2005” of the world, typically add features within the same architecture, technologies, and tools. That’s why this category often fails. The qualifying signal: if the underlying architecture or technologies must be modified, uncertainty is more likely, and this is the hinge for the whole moderate tier.

The IRS’s paired examples make this concrete. In the same income tax product, updated tax tables and modified tax forms fail, while developing or modifying data encryption algorithms to protect e-filed returns can qualify. For anti-virus software, screens for scheduling automatic scans fail, while heuristic algorithms to detect new threats may qualify. Same product, different uncertainty.

Embedded software and when it qualifies

Embedded applications in cell phones, automobiles, and airplanes generally use existing software, architectures, languages, tools, and methodologies, so they generally fail too. The guide’s example: caller ID display on a cell phone generally doesn’t qualify. But tight constraints can create real uncertainty: very small screen sizes, failsafe requirements, or new communication protocols may require qualifying experimentation. Constraints are where the interesting problems live.

And here’s the good-news bucket, delivered with actual enthusiasm, because the low-risk tier is where the fun stuff lives: new architectures, new algorithms, new database management techniques, system software like operating systems and compilers, specialized technologies including image processing, speech recognition, and AI, data recovery utilities that recover deleted files using reused disk space, and migrating mainframe workloads to grid computing. This is a heuristic, not a guarantee; each case’s facts and circumstances have to be weighed, and your mileage genuinely may vary. But if your roadmap has this kind of work on it, that’s where a claim has legs.

Internal-use software: the three-part heightened test most claimants miss

Yes, the R&D tax credit can apply to internal-use software, but only when the development passes the three-part heightened test on top of everything else, and this is the trap that catches otherwise solid claims. The R&D tax credit for software development splits by who uses the thing: external-use software, sold, leased, licensed, or otherwise marketed, is evaluated under the standard four-part test, while internal-use software must also clear a heightened threshold of innovation test: innovation, significant economic risk, and not commercially available. The October 4, 2016 final regulations govern this regime, and the IRS committed to not challenging taxpayers for positions consistent with those regulations for tax years ending after January 20, 2015.

Classification turns on the taxpayer’s intent and on the circumstances as they stood when development began, which makes early documentation of intent a qualification-critical act, not paperwork hygiene. Connectivity software’s status depends on its function. Third-party interaction doesn’t make software internal use, the guide’s example being a FedEx-style package tracking feature on a public website. And dual-function software gets a safe harbor allowing 25% of improvement expenses to be included, but note that’s for improvement expenses only, not a blanket pass for all internal-use software.

The Salt Lake City billing system case is the illustration: only the client-facing modules qualified. In practice, people misread this in both directions: a customer-facing tool isn’t automatically external-use, and a back-office dashboard isn’t automatically excluded. Intent at the outset controls, and it’s the thing nobody wrote down.

Quick test: If intent at the start of development wasn’t documented, classify using the facts and circumstances from that date, not from filing time.

Credit mechanics: QREs, calculation, and the payroll tax offset for startups

Passing the four-part test tells you which activities qualify; this section is about what those qualifying hours are worth. The mechanics run in three steps: first, identify your qualified research expenses (QREs); second, run the credit calculation, either the regular credit or the alternative simplified credit; and third, for startups without income tax liability, check whether the payroll tax offset can apply the credit against FICA instead. Each step has its own traps, so we’ll take them in order.

What counts as a QRE

Qualified research expenses are in-house research expenses, wages for qualified services, supplies, and computers used in qualified research, plus contract research at 65% of payments to third parties (a 35% haircut, equivalently). The wage rule that matters: if at least 80% of an employee’s services, “substantially all,” are qualified research, their full annual wages count.

The layer people miss: eligibility follows actual activities, not job titles. The daily one-hour scrum between a coder and a direct supervisor makes both claimable, because first-line supervision of qualified research counts. An executive assistant typing up test results qualifies as direct support. Even a monthly AWS reservation used as a test environment is partially claimable. In practice the credit lands at roughly 6-10% of qualifying expenditures, which is why those small line items add up. There’s a fuller line-by-line breakdown of QREs for software teams if you want the wage and contract-research details in one place.

Regular credit vs. ASC

The regular credit equals 20% of the QREs that exceed your base amount. The base comes from a fixed-base percentage drawn from 1984-1988 QREs and gross receipts, capped at 16%, multiplied by average gross receipts for the prior four years, and the whole base amount is capped at 50% of your QREs. Startups formed after 1988 use a flat 3% for their first five years. The ASC is simpler: 14% of QREs exceeding 50% of the prior three-year average, or 6% if you had no prior QREs.

Run the numbers on $250,000 of QREs with a $50,000 three-year average baseline and the ASC lands in the low tens of thousands. The guide’s own examples span $3,000 on $50,000 of QREs to $24,500 on $250,000. Credits carry forward up to 20 years, and there’s a §280C(c) election letting you take a reduced credit in exchange for full deductibility, which is a cash-flow call more than a correctness one.

The payroll tax offset

Two statutes matter here. The PATH Act of 2015 created the startup payroll offset (the same law made the credit permanent; it had been temporary since 1981). Then the Inflation Reduction Act of 2022 raised the cap from $250,000 to $500,000 per year. Qualified small businesses, under $5 million in gross receipts and within five years of their first revenue, can elect to apply up to that $500,000 against FICA taxes via Form 941, on a five-year election made on a timely return.

For a pre-revenue startup with no income tax liability, this is the difference between the credit being theoretical and being actual payroll relief. PATH also let eligible small businesses under $50 million in average gross receipts offset AMT.

Why the credit is separate from deductibility: Section 174, 174A, and the 2025 changes

The R&D tax credit is completely independent of deductibility under I.R.C. § 174 and I.R.C. § 174A: being able to deduct costs has never made them credit-eligible. Write off your dev costs all you want; that says nothing about whether they pass §41(d). Conflate the two tests and you can end up over-claiming or under-claiming.

The chronology, reconciled: the Tax Cuts and Jobs Act required capitalization and amortization of Section 174 research expenditures beginning in 2022, five-year amortization for domestic research, fifteen-year for foreign. That was the rule until the One Big Beautiful Bill Act, enacted July 4, 2025, created §174A and restored immediate domestic expensing beginning in 2025, including transition treatment for domestic costs not yet fully amortized and retroactive elections available for eligible small businesses amending their 2022 through 2024 returns. Foreign research remains subject to fifteen-year amortization.

What doesn’t change with any of that: the credit still has its own test. Coordinating the credit with expensing, including whether to make the Section 280C(c) reduced-credit election, is a cash-flow planning decision, not a single yes/no question. We cover the deductibility side in depth in our breakdown of software development costs under OBBBA if you want the other half of the picture.

Documentation and the convergence of scrutiny: why substantiation now decides claims

Documentation, not activity selection, is now the decisive variable in whether a software R&D credit claim survives, and that’s not a rhetorical flourish. Administrative, legislative, and judicial developments have all converged on the same requirement: component-level, contemporaneous substantiation.

What the revised Form 6765 requires

Starting with tax year 2025, Form 6765’s Section G asks taxpayers to sort the software development they’re claiming into its type at filing. The revised form, finalized in early 2025 after an initial 2023 proposal, also requires business-component-level detail for tax years after 2025: at least 80% of QREs must be reported at that granularity, with a maximum of 50 components. That ends the old practice of grouping sprints and releases under one broad component label, which was exactly the reporting style the riskiest claims favored.

The records the IRS expects

The IRS expects contemporaneous records: time-tracking payroll data, project write-ups stating technical objectives, source code commit logs, records of the uncertainties addressed, job descriptions, performance evaluations, and third-party contracts. Audit risk areas include owner-operator hands-on involvement and reasonable compensation for highly compensated partners. Recent case law shows what happens without this: Moore v. Commissioner (T.C. Memo. 2023-20, affirmed by the Seventh Circuit in 2024) rejected wage-based claims because executive time wasn’t shown to be qualified research.

Phoenix Design Group (T.C. Memo. 2024-113) denied credits because the taxpayer failed to show objective uncertainty alongside a documented experimental process, and Smith v. Commissioner (T.C. Memo. 2026-50) analyzed projects and contractual arrangements individually rather than accepting a blended claim.

Here’s the setup gap I keep noticing: a typical engineering team already generates qualifying documentation every day, commit logs, tickets in JIRA or Asana, design review notes, but nobody maps any of it to the four-part test until a retrospective study happens. The after-the-fact reconstruction is exactly what examiners flag. The fix is unglamorous: capture the uncertainty and the alternatives considered while the work is happening, at the component level. Your existing tooling already produces the evidence; the only missing step is the mapping.

Conclusion

The R&D tax credit generally yields roughly 6-10% of qualifying expenditures by practitioner rule of thumb, most states offer conforming credits, and billions are claimed yearly, with billions more unclaimed due to taxpayer or preparer unawareness. That’s real money for work you’re already doing, if the work actually fits the test.

So here’s the decision path, in order. Sort your uncertainties: functional, business, or project, and keep only the functional ones. Locate your release roadmap on the IRS’s risk map: 1.1 patches high, 2.0 architecture changes moderate, new architectures and algorithms low. Check your internal-use classification, and write down the intent at the outset this time. Then substantiate at the component level, contemporaneously, using the records you already generate.

What I find genuinely interesting, having read the guide cover to cover, is that the IRS isn’t examining whether you succeeded. It’s examining the process: what was uncertain, what the alternatives were, and how you evaluated them. The release roadmap and the commit history are the evidence. The process was the point all along, which, if you think about it, is the most engineer-friendly thing the tax code has ever done.

People Also Ask