AI Is Writing More Software. CodeROI Has Built for the Tax Record That Has to Keep Up.

Software companies can spend millions building products and still struggle to prove which work qualifies for an R&D tax credit. The credit applies to specific research activities and related costs, so companies need evidence of what work was done and which part of the business it supported. And that is where the problem gets more complicated: the claim may be broader than the evidence underneath it.

In 2023, Little Sandy Coal lost a federal appeals case after treating entire vessels as the business components for its R&D claim. The court found that this broad approach prevented judges from testing whether smaller parts of the vessels might qualify separately. 

That issue is becoming harder to ignore. For tax years beginning after 2025, many US companies must report research spending by business component on Form 6765. At the same time, AI is also taking on more software development, making evidence harder to piece together.

That is the problem CodeROI is trying to tackle. Its R&D tax credit software captures development activity as software is built. So, what happens when that trail meets the tax rules? 

The Tax Rules Already Have a Way to Look Below the Whole Product

Tax rules allow an R&D analysis to move below a broad product when only part of the work may qualify. The mechanism is called the “shrinking-back” rule.

If a business component fails the tests, the analysis can move to a smaller subset and test that work instead. Little Sandy Coal could not use that route because it chose the vessels themselves and pursued the claim at that level. That choice proved costly. The court noted that some smaller components might have involved qualifying experimentation, but the taxpayer had not structured its claim around them.

In Little Sandy Coal, the scope came up when the IRS challenged the claim. Form 6765 now requires more of that detail upfront. Filers completing Section G must report at least 80% of qualified research expenses by business component, and they generally report no more than 50 individual components.

For software companies, that raises a practical question: how small should a business component be?

Akshay Shrimanker, founder and CEO of Shay CPA, recommends defining software components closer to the feature or module level. He also advises preserving records that distinguish experimental activity from routine development.

That sounds straightforward on paper. In practice, though, those records have to exist before anyone starts reconstructing the claim. CodeROI’s claim is that a company should already have those records by the time that question comes up.

CodeROI Starts Collecting Evidence While Software Is Being Built

The company formally introduced its R&D tax credit platform in July. It connects to engineering systems such as GitHub and records development activity while software is being built. The company then structures that activity for R&D tax credits and other financial reporting.

Taylor Meadows spent years in tax and audit before founding CodeROI. He saw the same gap across his tax and audit work, with accountants asking for detail that engineers had no reason to keep. 

You see the mismatch: the people building the software are focused on getting the work done, while the tax team may need to reconstruct that work months later. 

He told SaaSTake:

The IRS has warned about weak evidence for years. Its audit guidance tells examiners to scrutinize claims built heavily from interviews, surveys, and estimates. It also emphasizes records created around the time the research actually happened.

CodeROI is trying to move more of that evidence gathering into the engineering workflow. Its website says the platform captures activity directly from development systems rather than asking engineers to recreate it later.

That may solve part of the evidence problem. Still, it does not, however, settle the tax question itself. Whether the activity qualifies is a separate judgment, and it stays with the tax adviser.

AI Makes the Evidence Trail More Complicated

AI is already routine inside software development. Vibe coding is pushing that shift further, making it possible to generate working software from natural-language instructions. 

A 2025 survey of nearly 5,000 technology professionals found 90% were using AI, and a separate 2026 survey found AI-agent use had risen from 31% to 59%.

That changes the evidence problem in a fairly basic way. An engineer can be asked what they worked on, but an AI agent cannot explain its work in the same way, and the same agent may be used for several unrelated kinds of work. Meadows put it this way:

Using AI does not automatically make software development eligible for an R&D credit. In fact, the technology involved is not the deciding factor. The question still turns on what the work involved.

Shrimanker recommends treating the activity and the spending as separate questions, since qualifying development does not automatically make the AI bill behind it claimable. That separation becomes more important as AI usage creates a higher variable cost for software companies. 

He also argues that shrinking back becomes more useful with AI-assisted development. A broad feature can contain qualifying experimentation alongside routine implementation, so looking at smaller parts of the work can become more important.

That is where R&D tax credit automation could help. The company extended its approach on September 2 with a new AI Agent, which it says separates AI development from other AI use and connects that activity to projects and code changes.

A Code Change Still Has to Become a Tax Claim

This is where the engineering record runs into its limit. A code change can show that development happened, but it does not tell a tax adviser what the IRS business component should be, and it does not prove the work qualifies as research.

The Form 6765 instructions say the identifier for a business component should align with the company’s supporting books and records.

That leaves a step between engineering evidence and the tax return because the two organize the work differently. One feature might involve hundreds of changes, while a single change might touch several parts of a product. So even a detailed engineering trail still has to be interpreted before it becomes part of a tax claim.

The company says its system organizes engineering activity into evidence that tax teams can review. But it explicitly says it does not replace the CPA or tax adviser. Those professionals still decide what belongs in the filing and defend that position if challenged.

That distinction is important as stronger records make a claim easier to explain, but they cannot turn routine software work into R&D.

Better Evidence Can Mean Claiming Less

CodeROI’s website prominently markets potential tax savings and includes a calculator estimating credits and other financial benefits. Yet more detailed evidence does not guarantee a larger R&D claim.

Meadows adds:

That creates a real trade-off for companies. Better records may uncover qualifying work that an annual survey missed. The same records may also exclude activity that a rough estimate would have included. After all, that tension is easy to miss when software R&D tax credits are viewed mainly as a calculation rather than an evidence exercise.

In other words, stronger evidence can sometimes produce a smaller number.

That matters because the value of a tax credit does not end when the return is filed. A company may later have to explain how the figure was calculated and what evidence supports it. So, the record behind the number matters too.

For CodeROI, that shifts the sales argument away from finding the biggest possible credit. The stronger claim is that companies should know exactly what sits underneath the number they sign.

The Financial Record Is Moving Closer to the Code

For years, software companies built first and explained R&D later. That worked poorly when evidence had to be recreated from projects, estimates, and memory.

Now the pressure is coming from both directions. The IRS wants more detail about where qualified research happened. Meanwhile, AI is making software development faster and harder to reconstruct through human memory alone. So, the timing of evidence collection has become part of the problem itself.

CodeROI has built around that shift by capturing development activity while the work is still happening. Tax professionals still decide what qualifies, but they can start with a record of the work rather than recreate one later. In fact, that is the key change here.

The R&D record can now start closer to the work itself. And as more software is built with AI, that shift becomes harder to ignore. After all, the code can change in an instant. The record behind it has to keep up.