The R&D Tax Credit Is Hard Until You Build Documentation Like This - Episode 08

The 3-Folder R&D Tax Credit Documentation System (Built for IRS Audits + Form 6765 Section G)

The episode explains why many R&D tax credit studies fail audit scrutiny because they produce only a form number without substantiating documentation or coordination with the company CPA, using a pre-revenue tech company example where a $50,000 “study” delivered $0 benefit and missed a true ~$150,000 credit by understating qualified wages. It introduces a simple three-folder (or tag) system built from documentation companies already have—Jira, architecture docs, Slack, emails—to meet the IRS four-part test: (1) conceptualization/design for permitted purpose, (2) technical challenges for technical uncertainty and process of experimentation, and (3) testing/validation to close the loop. It also previews tax year 2026 Form 6765 changes adding Section G requirements (project disclosures, supervision/support breakdowns, and expense category detail), outlines what an audit/IDR process looks like, and stresses that proper contemporaneous documentation reduces risk, interest, and penalties.

Transcript

SPEAKER_00 0:00

Most RD credit studies I review weren't built to survive a real audit. I see this thing showing up again and again and again. The company has a number on a form, but ultimately there's nothing there to back it up. In this video, I'm going to walk you through the three-folder system that ultimately fixes that problem. And I'm going to show you exactly how this maps directly to what the IRS is asking for. Let me show you what this looks like in practice. A tech company came to me this year. They were pre-revenue and they had about 1.7 million in US payroll. They had about 17 engineers, and what they were doing was building hardware that was really kind of genuinely groundbreaking. Before they came to me, they had used two cookie cutter RD providers in the two previous years, and both providers just ultimately spit out a tax form. Think about it, that's it. They just got a tax form and nothing else. So that form had a number on it, and that was $50,000, but it was just an empty form. Because here's the really big issue. That form never made it on the tax returns. Think about it, nobody had coordinated with the company's CPA, nobody had verified that the credit got claimed, they paid for the study and walked away with a PDF that produced ultimately zero dollars of benefit for the company. So what we did is we dug into the underlying work, and what we found was that the real credit number was closer to $150,000. So those first providers had captured less than $500,000 in qualified wages. The actual amount of qualified wages was closer to $1.5 million. The whole engineering team was doing qualified work. And ultimately, that cookie cutter approach missed almost a million dollars in qualified spend. So ultimately, the bigger problem wasn't the missed credit. It was that even the credit that they did calculate, that credit had no documentation behind it. Think about it, there was no audit defense or any sort of substantiation. So what I want to get to is that the IRS has a phrase for this. They call it contemporaneous documentation. Contemporaneous documentation is captured in real time while the engagement team is performing the work. And guess what? It's mandatory to have this on file. So here's the part that frustrates me all the time. I see most companies already have about 90% of what they need to substantiate the credit, but they just don't know how to organize it. I mean, you have the Jira tickets already there, you have the architecture documents stored in the folder, you have the Slack threads, you have the emails going back and forth, you have all that conversation about the debugging, the architecture, the design, the process, the testing, but nobody told them that the work they were already doing in the tools that they were already using was the documentation to substantiate the credit. Almost all teams think that documentation means doing something completely different. And look, it doesn't mean that at all. And that's the whole point of this video and what I want to talk through. Quick aside while you watch this, if your last credit claim looked anything like the tech company I just talked about, there's a link to a free credit snapshot in the description below. If you want us to take a closer look at your situation specifically, go ahead and use that link. Now let's get back to the documentation system I was talking about. So here's what I do with every new client in week one. I don't ask them to build a new documentation process. I ask them to install a simple tagging system on top to the documentation that they have already. You can use a three-folder system or a three-tag system, whatever is easiest for you. What's most important is that it's a simple system and the structure is what matters and it's not so much the tool that you use. Let's start with folder one. Folder one is going to have the conceptualization and design documents. This is where you drop in anything related to why a project exists and what you're trying to build. Think about like architecture documents, wireframes, kickoff meeting notes, business requirements gathered from customer calls, maybe the reasoning behind the feature. What it does is that this folder maps directly to the first part of the IRS four-part test, which the IRS calls the permitted purpose test. Why are you building this? What's new about it, and what functional improvement are you trying to go for or improve? So that's folder one. Let's talk about folder two. These are the technical challenges folder. This is where the engineering teams thought about those difficult issues that came up during the development. Those bug reports with the root cause analysis, the performance and regression documentations, that Slack thread where someone says we tried compound indexes, but that didn't work, and then we tried materialized views and that didn't work either. Finally, they landed on some hybrid approach. That's this folder. This folder is doing double duty as well. It covers the third and the fourth part of the test, technical uncertainty and process of experimentation. The IRS wants to see you didn't know how to solve something at the start, and you used a real iterative approach of process experimentation to figure it out. That's already in your tickets and the logs that you have already. All you have to do is just tag it. Finally, folder number three. This is going to be testing and validation. Think QA scripts, A B test results, beta program notes, load test outcomes. This closes the loop by showing what worked and what didn't, how complex things were built, and just adding additional support for that process of experimentation test. Now, the fourth part of the test you must be asking about, that's technological in nature. So we don't need a folder all by itself. It's just a simple sentence saying what tech stack you used in order to build the product. Super simple and it doesn't need its own folder. Now you have a system that documents the work that you are doing, and it's a simple tag or a folder system that you apply to the work you're already performing. Oftentimes, what a lot of providers ask is they ask their clients to write a detailed narrative at year end or almost more than a year later than when the work was performed. And this can be extremely cumbersome. The narratives, they're fine, but oftentimes it's too disjointed and too much time has passed since the work was actually completed. What this does is the audit defense becomes extremely weaker. The change that we're trying to make is that when I realized that the four-part test wasn't an afterthought, but rather it's a filter that you apply to what's already happening in your repository. Once you implement that system, everything clicks into gear. It just hums along like a well-oiled machine in the background so that when it comes time to file, you have the documentation that you need. Let's pause here for a quick second. So if that mapping clicks with you and you would rather have help installing it instead of trying to do it yourself during tax filing, there's a link to a free credit snapshot in the description below, and I'm happy to take a look. Now let's talk about what's on the horizon in tax year 2026. You're probably wondering, Chris, why are you talking about all this documentation and substantiation stuff? Look, well, it matters more now in Tax Year 2026 and going forward. The IRS changed the form 6765. That's the form where you claim the RD tax credit. And what they did is that they added a whole new section. And this section is called Section G. And what this Section G does is takes the questions an IRS auditor would normally ask during an audit and puts it directly on the form itself. This is before you ever even file your tax claim. So think about that. That's quite a bit of info that you need to provide ahead of time. There's three new things on this new form that weren't there before. Number one, project level disclosure. You have to identify and describe each business component, think project on which you're claiming credits. For example, you have 12 features, means you have to write 12 different write-ups. Now, number two, direct supervision and direct support breakdowns. The IRS wants to see how much credit comes from the supervisory and support layers versus the core engineering. The whole point of this is that this question is to ensure that at least 80% of the qualified expenditures are coming from core development work, not supervisory and support layers. Let's talk about number three. This is the expense category breakdowns at the form level. So what I mean by that is that wages, supplies, contractors, computer rental, all of these expenses need to be broken out per business component, and then they need to tie directly back to the calculation. I know that that's a lot, and trust me, I get it. It completely is. A few things I want you to keep in mind. There's a small business exception. So if you have under 1.5 million in qualified expenditures and under 50 million in gross receipts, you may not have to fill out this section G just yet. So let's tie all of this back to the three-folder system we talked about at the beginning of the video. If you have this system in place, Section G is a 15-minute summary exercise. And if you don't, look, this is going to be a multi-week scramble through old tickets, emails, JIRA, confluence notes, and that's not going to be super fun. Quick word on audits before we move forward because I know that's a real fear for a lot of folks watching this video. The reality of an audit is a bit calmer than the actual fear of the audit. What happens is that when you're audited, the IRS is going to send you an IDR or an information document request. Basically, this is a list of items they want to see, and you and your team or your CPA gather what's already in the folders and then you submit it. They come back with follow questions, maybe you answer them, you get on a quick call, and depending on timing, a resolution lands somewhere between 6 and 18 months. If you have proper documentation, the credit is usually sustained. Sometimes there's minor adjustments, but it's rarely going to be a full denial if you do it correctly. Your engineering team almost never has to talk to anyone at the IRS. The IRS doesn't look at your source code. What they really want is just a clean bridge between the credit, the projects, the activities, and ultimately the expenses that were claimed. That's it. What's the cost of getting this wrong? Well, number one, it's a lost credit, which is really just cash. So think of the credit as cash. But there's also interest and there's also penalties. So think on a $100,000 credit, maybe on three years of returns. You can compound that into real big money really fast. So that's exactly what was on the table for the tech company we talked about a little bit before. The cost of getting it wrong is extremely high, and the cost of getting it right is extremely low. It's just one tagging convention or file system. You apply this across the tools you already use, and maybe you have a 30-minute conversation per quarter with your developers to see what was the new work that was being done. If you've been claiming the credit and you don't have a system in place that produces a Section G summary in 15 minutes, you have a documentation and substantiation issue. If by any chance you would like my honest take on it, there's a link in the description that goes to a free credit snapshot. Well, we'll look into what you have and we'll tell you what's missing. Hopefully this was helpful and laid out two paths that you and your team can go from here. One path is you can take what I walked through, install the three-folder system on maybe the tools that you already use. You can run a quick 30-minute quarterly check-in and you have it hum in the background with ease. Or if you would rather have help installing it and tying it to your CPA's filing, the snapshot link is in the description below. Now, we'll go ahead and take a look and set it up for you if that's something that you'd like to do. A quick note before we wrap up everything I covered is educational content based on how the RD credit generally works. So every situation is different and the exact credit amounts and timing depends on your specific fact pattern. This isn't individual tax advice, so please work with your own tax advisor for your specific situation.