IRC §41 · R&D Tax Credit

Your code is already R&D.

What does the IRS mean by "business components"?

A business component is the product, process, computer software, technique, or formula your team develops, and the credit is calculated component by component. For U.S.-based AI, SaaS, and technology companies that build the software they own, the federal R&D credit is often the single most valuable incentive available. Below are the 25 business components that qualify most often, plus the exclusions that quietly disqualify the rest.

25 qualifying components · employee roles · audit documentation · §41(d)(4) exclusions
The substantiation chain

What the IRS wants to see connected

A qualified claim isn't a pile of activities, it's a chain of evidence linking people to a component, through uncertainty, to documented experimentation.

01
Employee
02
Technical
activity
03
Business
component
04
Uncertainty
05
Experimentation
06
Documentation

Establish this chain end to end, and you're in a strong position to substantiate the credit in an examination.

A closer look

How to apply Business Components to your activities

Example components, the technical uncertainties they resolve, the roles behind them, and the evidence that defends them.

01

New software platform development

Example components
AI recruiting platformHealthcare SaaSFinTech lending app
Technical uncertainties
How should it scale?Which architecture hits performance?How to structure the data?
Typical roles
CTOSoftware EngineersFull-stackProduct
Audit evidence — Jira stories, GitHub commits, sprint boards, roadmaps, design docs, architecture diagrams, release notes.
02

Proprietary AI / ML features

Example components
Recommendation enginesLLM apps & agentsFraud detection models
Technical uncertainties
Which model architecture wins?How to prepare training data?How to reduce hallucinations?
Typical roles
AI / ML EngineersData ScientistsCTO
Audit evidence — Model performance & evaluation reports, experiment logs, training docs, test datasets, version history, research notes.
03

Significant enhancement of existing software

Example components
Rebuilt onboardingReporting-engine redesignNew billing module
Technical uncertainties
Can it perform at scale?Which design approach works?
Typical roles
Full-stack DevsProductEng. LeadsQA
Audit evidence — Feature specs, sprint docs, user stories, release notes, Git history. Mind the adaptation exclusion and the shrink-back rule.
04

Scalability, reliability & performance

Example components
Monolith → microservicesAPI response-time gainsDatabase optimization
Technical uncertainties
Which architecture supports scale?How to reduce latency?
Typical roles
BackendDevOpsInfrastructureCTO
Audit evidence — Benchmark & load-test reports, infra diagrams, performance dashboards. Routine capacity adds don't qualify.
The full list · 1–25

The 25 activities that most often qualify

Each qualifying activity attaches to a business component the credit is calculated on. Expand any item to see the component it maps to.

Activities vs. components: these are qualifying activities. Each attaches to a business component (product, process, computer software, or technique) that the credit is calculated on.
Wage QRE planning

How much of each role typically qualifies

The bands show the low-to-high range of time that commonly counts as qualified research, by role. Engineering clusters high; product, design, and support are partial and fact-dependent.

0%25%50%75%100%

Illustrative ranges across MainStreet engagements. Actual percentages depend on facts and circumstances and should be supported by interviews, documentation, and a defensible time-allocation method (see Treas. Reg. §1.41-2(d) substantially-all rule). Support roles qualify only for development-linked troubleshooting, not routine customer support.

Screen before you claim

What does not qualify

Even technical-looking work is carved out by §41(d)(4). Screening components against these exclusions before a study is one of the most effective ways to reduce audit exposure.

Research after commercial production

Routine bug fixes, maintenance, and ongoing debugging once a component is release-ready.

Adaptation

Adapting existing software to a particular customer or environment. Hits enhancement (3) and integration (6).

Funded research

Work paid for by a customer or grant with no retained rights and no financial risk. A trap for client work (6).

Duplication & reverse engineering

Reproducing an existing component from inspection or another party's plans.

Style, taste & cosmetic design

Purely aesthetic UI/UX work, only the technical implementation qualifies (8).

Surveys, foreign & social science

Market research, routine data collection, QC testing, non-U.S. research, and the social sciences and arts.

Heightened standard

Internal-use software clears a higher bar

Components built primarily for internal use (items 9, 16, 17, and 25) must pass all three prongs of the high-threshold-of-innovation test under Treas. Reg. §1.41-4(c)(6). It's a frequent audit focus.

Prong 01

Innovative

Would result in a meaningful reduction in cost, improvement in speed, or other measurable economic improvement.

Prong 02

Significant economic risk

Substantial resources committed, with substantial uncertainty that they'd be recovered in a reasonable period.

Prong 03

Not commercially available

Can't be bought, leased, or licensed and used without modifications that would themselves meet the test.

Dual-function software, serving both internal users and third parties, is governed by separate presumption and safe-harbor rules. Document the three-part test for every internal-use component.

Audit defense

The most defensible documentation

The artifacts your team already produces are the same ones that win an examination, if they're connected to the right components.

Engineering artifacts
  • Source-code repos (GitHub / GitLab / Bitbucket)
  • Jira / Linear / Asana tickets
  • Sprint boards & agile artifacts
  • Product roadmaps & release notes
  • CI/CD deployment logs
Technical records
  • Technical design documents
  • Architecture diagrams
  • Technical RFCs
  • Test plans & QA reports
  • Meeting notes & Slack / Teams threads
People & time
  • Employee interviews
  • Org charts & job descriptions
  • Time-tracking records (where available)
Employee → Activity → Component → Uncertainty → Experimentation → Documentation
Who qualifies

Four conditions that open the door

Most AI and SaaS companies meet all four every year, usually without realizing the work counts.

U.S.-based work

The employees performing the development work are located in the United States.

Rights retained

The company keeps substantial rights and IP ownership in the work it funds.

Not third-party funded

The work is not funded or paid for by a customer or grant that bears the risk.

Technical uncertainty

Activities involve real technical uncertainty resolved through experimentation.

Business component — under §41, a product, process, software, technique, formula, or invention held for use in the trade or business that required technical experimentation. The trick is naming the component, not just the activity.
The bottom line

If you ship software, you're probably leaving credit on the table.

The 25 categories above cover the vast majority of qualifying R&D in modern AI and SaaS companies. Claiming it well comes down to four moves.

Define the component, not the activity

Map qualifying work up to a named product, process, or software component for Form 6765 Section G.

Mind the exclusions

Screen for adaptation, funded research, and post-production work before the study, not after.

Hold internal tools to the higher bar

Internal software and AI agents need the three-part high-threshold-of-innovation test documented.

Build the evidence chain

Tie employees and time to components through repos, tickets, and design records.

See if your work qualifies →
MAINSTREET TAX CREDITS

This article is for general informational purposes only and is not tax or legal advice. R&D credit eligibility depends on each company's specific facts and circumstances under IRC §41 and the related Treasury Regulations.