No company is a stranger to R&D tax credits. They are widely discussed and yet, they are consistently underclaimed, especially by tech companies that do qualify.

Processing Content

In my experience, the reason depends on where the company is in its lifecycle.

Early-stage startups often miss the credit because nobody has told them it exists, and founders are busy shipping out the product. Mid-stage companies understand it exists, but the benefits feel too far off if credits are accumulating while the business is still in net operating losses. Large companies face a different challenge altogether. The process gets big enough that it has to be turned into an internal function, or it gets postponed year after year.

Across all three, the fear of failing the audit remains the same. Audit risks are higher now than they were before, and companies usually discover the weakness in their documentation when they are already under examination.

One reason claims fall apart is that businesses misread what qualifies.

A product can be genuinely impressive and still fail the legal definition. The IRS looks for technological or scientific uncertainty and a process of experimentation to resolve it. They're not interested in commercial uncertainty about whether a product will sell or not.

This distinction might sound academic until you notice the narrative in the audit file. If it is built around features and market novelty, chances are it will collapse under scrutiny. But when it is built around the underlying technology constraints, failed approaches and what changed technically as a result, it holds up better.

The federal government treats the R&D credit as a major tax expenditure. The Treasury's fiscal year 2025 tax expenditure report estimates the revenue effect of the credit for increasing research activities at roughly $28.2 billion in 2024, rising to about $32.6 billion by 2028. 

That sum hides the tightening scrutiny around the process.

The Form 6765 is the biggest indicator of this document shift. The December 2025 instructions state that if you report QREs on line 48, you must complete Section E. They also lay out a new business component reporting section, Section G. It is optional for tax years beginning before 2026, but required for tax years beginning after 2025, with specific thresholds and an 80% top 50 approach to reporting business components.

The same instructions around the amended returns add another pressure point. The IRS instructions explicitly note that refund or credit claims on amended returns that include a Section 41 credit must include specific information to be considered valid. 

All of this illustrates the increasing expectation of traceability. And the work goes beyond just a year-end write up. 

Tax or finance teams might be overseeing the R&D claims, but most of the work falls on engineers, and this presents an incentive mismatch.

Engineers have a backlog, deadlines and no personal upside from the credit. They also hold the key details, the technical decisions, the false starts, the moments of uncertainty and the experiments that resolved it. When the process is run as a year-end chase, it becomes a feat of coordination, and the final narrative ends up missing the substance engineers would have written themselves.

This is why retrospective substantiation is risky. Six months later, teams only remember the final solution, not the failed prototypes, the test results or the exact hypothesis they were trying to prove. That missing detail is often what is needed to be surfaced for the four part test.

The fix is not to turn engineers into tax professionals. Instead, capture a small amount of the right context while the work is happening.

In practice, three changes help immensely:

1. Define business components early, then keep them stable. Whether you call them projects, modules, services or product components, decide on a structure your team can stick to. This becomes the backbone for the story you will need later, especially as Section G becomes required for more filers.
2. Derive uncertainty and experimentation from the systems teams already use. Most of the evidence is usually already there, scattered across tickets, pull requests, commit messages and technical notes. The missing piece is a consistent way to single out uncertainty and experimentation.
3. Stop reconstructing time allocations from memory. Even a lightweight approach is better than a year-end guessing exercise. Build a defensible allocation starting from artifacts created during development, and not from interviews conducted after the fact.

Here's a simple test: If the strongest evidence for the claim lives in someone's head, the claim is fragile. If the evidence lives in systems and can be traced, the claim is easier to defend.

There is real substance to AI in this workflow, but only when the problem is defined correctly.

Engineering teams leave a large digital footprint as they work. Historically, no one could process such vast amounts of data. But with modern large language models, we can consolidate scattered artifacts into a coherent narrative, identify likely qualifying work, and reduce the burden of coordination substantially.

That does not mean that AI replaces judgment. Someone still needs to review the output and stand behind it, because the liability sits with the taxpayer. AI's value lies in shrinking the busywork portion of the process so technical and tax expertise can focus on the parts that actually require judgment.

1. Know the payroll tax option vs. the regular credit. If you qualify, payroll tax offset can matter even before profitability. You must elect it on the original return filed on time (extensions count). You cannot fix it later with an amended return
2. Use the records you already have. GitHub, Jira, PRs, internal notes. Even messy records are better than rebuilding the story from memory later.
3. Stay conservative and beware of the advisors who inflate numbers. The company carries the risk in an audit. A smaller claim you can defend is better than a big one that falls apart.

The administrative approach to R&D credits needs to shift away from the current once-a-year scramble within companies. The work is simply too technical, while the recordkeeping horizon is too long. To top it off, the standard is rising.

The carryforward rules alone create a long tail. The IRS audit techniques guide notes the research credit carryback is one year and the carryforward is 20 years. That is a long time to rely on memory and scattered artifacts.

The better model is ongoing capture, clearer technical narratives and a workflow that places engineering systems at the forefront of the process rather than an afterthought.

Albeit simple, so far companies were able to brush off the necessity of such processes. But with mounting scrutiny, that behavior needs to change. Luckily, the solution just needs a bit of follow-up but rewards companies tenfold by making their claims easier to defend.