R&D Credit Fundamentals

Business Components Documentation Guide

What counts as a business component under IRC §41, how to identify and document them, and what the IRS expects to see for each qualifying project.

Last reviewed: June 2026Reviewed by: MainStreet's R&D Tax Credit team (licensed CPAs & Enrolled Agents)

Quick answer

What is a business component for the R&D tax credit?

A business component (IRC §41(d)(2)(B)) is any product, process, computer software, technique, formula, or invention a company develops or improves and either holds for sale, lease, or license, or uses in its business. It is the unit of analysis for the R&D credit: you must show that each business component independently satisfies the four-part test.

Identify components at a meaningful level — a product feature, process improvement, or software module — not so broad that one component covers all of your R&D, and not so granular that every code change becomes its own. For each component, keep documentation of the permitted purpose, the technical uncertainty at the outset, and the process of experimentation used to resolve it. Beginning with 2026 tax years, Form 6765 Section G requires business-component-level detail.

What Is a Business Component?

Under IRC §41(d)(2)(B), a "business component" is any product, process, computer software, technique, formula, or invention which is to be:

Held for sale, lease, or license, or
Used by the taxpayer in a trade or business

The business component is the unit of analysis for the R&D credit. For each business component, the taxpayer must be able to demonstrate that qualifying research activities were conducted — meaning that each of the four prongs of the four-part test was satisfied.

Key Principle: You must identify your business components at the right level of specificity — not so broad that a single component covers all of your R&D, and not so granular that every line of code becomes a separate component. Typically, a business component corresponds to a meaningful product feature, process improvement, or software module.

Identifying Business Components

During the MainStreet study, your Subject Matter Expert (SME) will work through your R&D activities to identify each distinct business component. Consider the following questions:

What were you trying to build or improve?

List each distinct product, feature, process, or software module that your team worked on during the tax year. Think in terms of project names, sprint goals, product roadmap items, or engineering tickets.

Was there a specific technical challenge?

For each item on your list, ask whether there was a genuine technical uncertainty at the outset — something your team didn't know could be done, or didn't know how to do. If yes, it may be a business component.

Did your team experiment to find a solution?

Was there a process of trial and error — testing alternatives, iterating on designs, running experiments? If your engineers simply implemented a known solution, that activity may not qualify.

Did the work have a permitted purpose?

Was the goal to improve functionality, performance, reliability, or quality? Routine maintenance, bug fixes with known solutions, and cosmetic changes typically don't qualify.

Documentation Requirements for Each Business Component

For each business component, you need documentation that walks the IRS through the four-part test. This doesn't require elaborate reports — the goal is to show contemporaneous evidence that qualifying research was actually conducted.

Permitted Purpose Documentation

Project brief or charter describing the intended improvement
Product requirements or design specification document
SME statement describing the goal of the project
Feature or epic ticket descriptions (Jira, Linear, GitHub Issues, etc.)

Technical Uncertainty Documentation

Meeting notes documenting the technical challenge or unknown
Design alternatives considered at the start of the project
Engineering post-mortems that discuss what was tried and failed
Architectural decision records (ADRs) documenting uncertainty

Process of Experimentation Documentation

Sprint retrospectives and iteration logs
Test results and performance benchmark comparisons
A/B test designs and results
Code review comments discussing alternative approaches
Design revision histories (Figma version history, etc.)

Technological in Nature Documentation

Technical specifications, architecture diagrams, or design documents
Evidence the work relied on engineering, computer science, or a hard science
Links to relevant technical research, papers, or frameworks consulted

Examples by Industry

Industry	Example Business Component	Typical Technical Uncertainty
Software / SaaS	New data processing pipeline	Whether real-time throughput targets could be achieved at scale with chosen architecture
Software / SaaS	Machine learning recommendation engine	Whether the model could achieve accuracy thresholds using available training data
Manufacturing	New material formulation	Whether the material could meet tensile strength specs without exceeding cost targets
Engineering / Construction	Custom structural system for unusual site conditions	Whether the proposed design approach could meet code requirements for the specific load conditions
Life Sciences	Novel drug delivery mechanism	Whether the delivery method could achieve the target bioavailability profile
Clean Energy	Battery management algorithm	Whether the algorithm could optimize charge cycles while maintaining safety margins

The Subject Matter Expert Role

A Subject Matter Expert (SME) is a technical employee with firsthand knowledge of the company's R&D work — typically an engineer, scientist, or technical lead. The SME plays a critical role in the MainStreet study process:

Reviews each employee's job duties and certifies the percentage of time spent on qualifying research activities
Identifies and certifies the qualifying business components for the tax year
Provides descriptions of the technical uncertainty and process of experimentation for each component
Signs the SME certification that becomes part of the IRS-ready package

Note: The SME does not need to be the most senior technical person in the company. What matters is that they have direct knowledge of the qualifying R&D work and can credibly certify the business component descriptions. Many companies designate a VP of Engineering or senior engineer as their SME.

Frequently Asked Questions

There is no minimum or maximum. You should identify every distinct product, process, or software project on which qualifying research activities were conducted during the tax year. A company might have 3–5 business components or 50+, depending on the nature and scale of their R&D.

Yes. The IRS expects separate documentation for each business component showing that it satisfies the four-part test. This includes a description of the component, the technical uncertainty involved, and the process of experimentation undertaken.

Yes. In software development, a business component can be an entire application, a module, a feature, or a distinct algorithm — as long as it's a separately identifiable item for which the company conducts qualifying research.

Expenses for abandoned projects can still qualify. The four-part test requires that qualifying research was conducted — not that the project succeeded or resulted in a commercial product.

The company's Subject Matter Expert (SME) — typically a technical employee with direct knowledge of the R&D work — reviews and certifies the qualifying business components. MainStreet facilitates this process during the study.