QRE stands for qualified research expense. It is the portion of an expense that qualifies for the R&D tax credit under IRC Section 41. For software teams, wage QREs often come from eligible development, supervision, or support activity.

IRS Form 6765 Section G: Complete 2026 Compliance Guide

Section G is the part of Form 6765 that asks companies to break down R&D tax credit expenses by business component.

Instead of only reporting high-level qualified research expense totals, companies must show which products, projects, software modules, tools, or other business components generated the qualified research expenses, also known as QREs.

For software companies, think of this as project-level R&D tax credit reporting.

That does not mean every project automatically qualifies. It means eligible R&D dollars need to be tied back to the software work that created them.

In plain English:

Section G asks companies to explain where their R&D tax credit numbers came from, at a much more detailed level than before.

Cherry Bekaert described the finalized instructions as “the IRS’s move to a project-specific disclosure approach.” For software companies, that is the practical shift: the R&D credit can no longer live only at the company-wide total level.

Section G is optional for tax years 2025 and earlier. The new section G requirement becomes mandatory for the 2026 tax year.

That means 2025 is the dry run and 2026 is when most companies need to be ready.

The IRS generally requires Section G filers to report at least 80% of total QREs by business component, but no more than 50 business components individually. Remaining components can generally be reported in aggregate.

Plante Moran’s guidance is practical: “Starting now can help transform burdensome Section G reporting from a last-minute compliance exercise” into a better-supported R&D process. That is especially true for software companies, where the right evidence needs to be captured while the work is happening.

Why should companies care about Section G?

Section G is a major increase in the level of detail required to claim and defend R&D tax credits.

This is not just another tax form update. It raises the documentation bar.

Companies need to be able to explain:

What was built
Which business components generated QREs
Who performed the qualified work
Who supervised it
Who supported it
How those costs were calculated
How the totals tie back to Form 6765

What is the risk with new Section G changes?

If the IRS challenges the credit, the taxpayer ultimately owns the risk. Weak support can lead to denied credits, repayment obligations, penalties, interest, and audit stress.

For software companies, this matters even more because the evidence exists. Commits, pull requests, reviews, QA results, approvals, tickets, and releases already create a detailed record of how software was developed. The problem is capturing that data and translating it into tax-ready support.

Section G changes how companies claim credits, is your company ready?

Grant Thornton put it plainly: “The Form 6765 requires new qualitative and quantitative information, significantly increasing the reporting requirements.” For companies claiming software R&D tax credits, that means the old level of documentation may no longer be enough.

Anchin described the impact directly, noting that “considerable additional time and effort” will still be required to complete the revised form. That extra lift is exactly why companies should not wait until filing season to figure out whether their data is good enough.

Section G may sound simple: break out QREs by project or business component.

But to do that correctly, you first need to understand QREs at the individual level.

If one developer worked across five projects during the year, you need to know:

Which of that person’s work was R&D eligible
Which projects that work supported
How much of that person’s wage cost should be allocated to each project
Which portion belongs in direct research, direct supervision, or direct support

In other words:

You cannot accurately calculate project-level QREs if you cannot first calculate and allocate individual-level QREs.

That is the hidden lift inside Section G. It is not just project reporting. It is individual activity allocation, mapped to projects, converted into QRE dollars, and reconciled back to the tax return.

For software development, this is where code repository data becomes critical.

Section G includes qualified research expense dollars, not raw hours and not every engineering dollar.

A QRE, or qualified research expense, is an expense that qualifies for the R&D tax credit. For wages, Section G separates wage QREs into three categories:

For wages, Section G separates wage QREs into three categories:

Section G wage category	Meaning
Direct research wages	Wages for people directly performing qualified research
Direct supervision wages	Wages for first-line supervisors directly supervising qualified research
Direct support wages	Wages for people directly supporting qualified research
Total qualified wages	Direct research + direct supervision + direct support

Simplified:

Section G = eligible QRE dollars by business component, with wage QREs split into direct research, direct supervision, and direct support.

Baker Tilly summarized the practical impact well: organizations must provide “more transparency on wages, software and contract research.” For software companies, that means wage support needs to be specific, classified, and tied to the right business component.

A business component is the thing being developed or improved.

For software companies, that may be a:

Product, Platform, Module, Feature set, Internal tool, Customer-facing app, or a Major software project

For technical teams, the easiest way to understand this is to look at how work is already organized in Jira, Linear, Notion, GitHub Projects, or another planning system. If your engineering team already tracks work by project, product area, or major module, you may already have a strong starting point for identifying business components.

A business component does not always equal a project. But for many software companies, project-level reporting is the most practical way to understand business-component-level reporting.

For software teams, the challenge is not just calculating total R&D wages. It is classifying those wages correctly.

A developer writing eligible code is different from a manager approving a pull request. A QA reviewer supporting eligible pre-launch development is different from someone doing routine post-launch maintenance.

A pull request, or PR, is a proposed code change submitted for review before it is merged into the main codebase.
QA means quality assurance.
PPV means post-production verification. In this framework, PPV is eligible only if performed pre-launch. Once the product is live, PPV should generally not be treated as eligible activity for this mapping.

The key nuance: Section G does not include every activity dollar. It only includes QRE dollars. If an activity is mapped to direct support but is not R&D eligible, it should not flow into Section G.

MGO highlights the same operational challenge: businesses need to “classify wages” and find qualifying activities using “better tracking systems.” For software companies, that tracking system should start where the work happens: the code repository and development workflow.

Section G is difficult because finance, tax, and engineering teams do not usually organize data the same way. Engineering teams think in terms of projects, pull requests, tickets, QA, releases, and sprints. Tax teams need QREs by business component, wage category, activity type, and eligibility.

That creates a translation problem.

Engineering data	Tax reporting need
Projects	Business components
Commits	Development activity
Pull requests	Review and supervision support
QA results	Support activity
Developer wages	Wage QRE dollars
Project work	Business-component allocation

If this data is not captured while the work happens, companies are forced to reconstruct the story later using interviews, spreadsheets, estimates, and incomplete records.

That is the risk Section G exposes. Plante Moran specifically emphasizes “capturing information while it’s current.” For software teams, that points directly to the development workflow, where the evidence is created in real time.

CodeROI is a patented software platform that automates R&D tax credit documentation and Section G reporting for software development activity. It connects to the code repository and analyzes development metadata, including commits, pull requests, reviews, approvals, QA events, and related workflow activity.

CodeROI does not need to inspect or understand the customer’s proprietary source code. It analyzes metadata about how the code was developed, not the intellectual property inside the code itself.

What is Section G?

Section G is the business-component-level reporting section of IRS Form 6765. It requires companies to report qualified research expenses by business component, including wage QREs split into direct research, direct supervision, and direct support.

When does Section G become mandatory?

Section G is optional for tax years beginning before 2026. It becomes required for most filers for tax years beginning after 2025, subject to limited exceptions.

What is a business component for IRS Form 6765 Section G?

A business component is the product, process, software, technique, formula, or invention being developed or improved. For software companies, this may align to a product, platform, major module, internal tool, feature set, or project.

Is a business component the same thing as a project?

Not always. But for many software companies, projects are the easiest practical starting point because engineering work is already organized that way in systems like Jira, Linear, Notion, or GitHub Projects.

What is a QRE?

QRE stands for qualified research expense. It is the portion of an expense that qualifies for the R&D tax credit. For software teams, wage QREs often come from eligible development, supervision, or support activity.

Why do individual-level QREs matter?

Project-level Section G reporting depends on individual-level allocation. If an employee works across multiple projects, the company needs a reasonable way to determine that person’s eligible QREs and assign them to the correct business components.

Does Section G include every engineering dollar?

No. Section G should include qualified research expense dollars, not every engineering dollar. If an activity is not R&D eligible, it should not flow into the Section G amounts.

Can CodeROI automate Section G for all types of R&D?

CodeROI focuses on software development. For software R&D, CodeROI automates evidence capture, activity classification, QRE support, and Section G-ready reporting. For non-software R&D, companies may still need advisors or other processes.

Final takeaway

Section G does not change the basic idea of the R&D tax credit. Software companies can still claim credits for eligible development work. But Section G significantly raises the documentation bar.

Companies need to show which business components generated the QREs, which individuals performed the work, how that work was allocated across projects, and how the dollars tie back to the tax return. For software companies, that evidence already exists inside the development workflow.

CodeROI automates the process by analyzing software development metadata, mapping activity to projects and individuals, converting eligible work into QRE support, and producing Section G-ready reporting.

Are you ready?

IRS Form 6765 Section G is here, are you ready?

So what is Section G?

Access the IRS Form Here

What is the timeline for Section G?

Why should companies care about Section G?

What is the risk with new Section G changes?

Section G changes how companies claim credits, is your company ready?

The hidden complexity: project-level QREs require individual-level QREs

What goes into calculating Section G?

Section G includes qualified research expense dollars, not raw hours and not every engineering dollar.

What is a business component for software development?

Want help on Section G?

How do software activities map to the Section G wage buckets?

Why is Section G challenging for software companies?

How CodeROI automates Section G for software development

Frequently Asked Questions

Section G Raises the Documentation Bar

Final takeaway

Products

Who We Serve

Company