There’s been a ton of talk around the new reporting requirements for the R&D credit (Form 6765) starting in 2026.

So basically, at a high level, what the IRS is asking for makes sense.

They are trying to move R&D claims toward a few things:

1) more consistent reporting, 2) a clearer link between people, work, and costs, and 3) ultimately reducing aggressive claims from cookie-cutter or automated providers.

I think these are all reasonable goals, and I think most folks would agree. So that’s 𝙬𝙝𝙖𝙩 they’re trying to do.

Now let’s look at 𝙝𝙤𝙬 they’re trying to do it.

Basically, they want taxpayers to:

1) define the business components, 2) tie the qualifying costs to those components, and 3) show how the uncertainty and experimentation actually happened

Theoretically, sure, that makes sense. All of that reporting would create a cleaner and more defensible claim.

The issue I have with this (and a lot of other practitioners do too, there were even recent discussions with over 100 research credit practitioners from firms of all sizes, and a lot of the same issues came up) is that it works in theory, but not always in real life.

In real life, companies are not:

• categorizing time into direct research, supervision, and support

• organizing work into tax-defined business components

• documenting everything through a specific tax lens while building products

The reality is companies are moving fast, building, experimenting, and trying to find product-market fit while technology and competition move at lightning speed.

Look, I get that the IRS is asking for structured, categorized outputs, and that’s great in an ideal world... but in reality, companies have messy, best-as-they-can-make-it inputs. As such, you’re seeing that gap between what the IRS is asking for and what real life looks like - and it's creating a lot of friction.

On top of that, the IRS hasn’t done a great job providing clear interpretations of some of the information they’re asking for (e.g. “new categories of expenses” - what does that actually mean?)

The underlying direction of where they’re going is good and important. I agree that more alignment between the work performed and the claim is a good thing.

I just think the path there might look more like helping companies connect the data they already have - design docs, test cycles, tickets, commits, etc. - into a framework that aligns with how companies actually operate.

I get that this is a bit idealistic, and the IRS isn’t exactly known for being flexible. But to give them credit, they have been open to feedback. They pushed the mandatory requirement from 2025 to 2026, which was the right move, and they’ve continued asking for input on how to make this more practical.

I think they are moving in the right direction by continuing that conversation. Until then, I think companies should prepare like these changes, as currently drafted, are going into effect in 2026.

I don’t think you need to redesign how your entire team works or add a bunch of admin overhead.

But it is worth starting to document, even in a simple way:

• what you were trying to build

• what didn’t work the first time

• what resources were involved

Even if it’s just a folder called “Tax R&D Stuff.”

Because ultimately, whatever the final version of the form looks like, the IRS is still going to want to understand (and see!) that bridge.