What Counts Toward the R&D Tax Credit in 2026? - Episode 11

Does Your Software Work Qualify for the R&D Tax Credit? Use the Count/Review/Cut Buckets

This episode explains that the question “Does our work qualify for the R&D tax credit?” is too vague and should be replaced by sorting work and spend into three buckets: count, review, and cut. Using a US software team example, he emphasizes qualifying is based on activities tied to specific business components (projects) involving technical uncertainty and experimentation—not job titles—so engineering payroll starts in review until activities are clarified. He highlights review areas that require fact analysis, including contractors (often limited to 65% and dependent on contract terms), cloud/computer rental tied to development, and separating US vs offshore work (offshore generally excluded). He recommends cutting routine maintenance, “peanut butter” percentage estimates, offshore costs, and customer-funded work where the customer bears risk/owns rights, and suggests documenting business components and technical issues throughout the year.

Transcript

SPEAKER_00 0:00

US software and engineering founders ask me some version of the same question all the time. Does our work count for the RD tax credit? So I'm Chris, I'm a CPA with a master's in taxation, and I've been working in this area for a long time. It's what I do every single day. I help companies sort through what qualifies, what areas need a little bit of a closer look, and what should stay out of the claim entirely. Let's go back to that question. Does our work qualify for the RD tax credit? And really that broad yes or no question won't get you a straight answer anymore. It's too vague to help you get the answer that you're really looking for. Instead, what I want to do in this video is sort your work and your spend into three specific buckets. It's going to be the yes, let's count this bucket. It's going to be the, hey, maybe let's take another look at it, review bucket. And finally, no, this doesn't qualify. Let's completely cut it bucket. So by the end, you should have a much better understanding of the makeup of your costs, and you should be able to answer the question, does our work qualify? So let me go ahead and start by saying, I get why founders ask this question all the time, right? It feels like there should be a simple yes or no answer. But the problem is that the question you're asking, it's changed over the years and it's becoming much more complex to answer. In addition to that, it gives you almost nothing to act on once you know the answer. So honestly, the real answer is almost always going to be look, it depends. Instead, let's go ahead and ask a better question. Which part of our work and which parts of our spend count towards the credit? Maybe which parts need additional review, and which areas should we go ahead and cut entirely. As such, that is the exercise we're going to go through today. We are going to have a count bucket, a review bucket, and ultimately also a cut bucket. Now let's go ahead and make this a little bit more practical and run through an example together. Picture a US software engineering team. You've got a few engineers based in the US. Maybe you have a cloud built, and maybe you have some offshore folks mixed in as well. We are going to walk through together and sort all of the costs for this company into each one of those three buckets. So let's start with the engineering payroll. And here's the part that surprises most people right away. Engineering payroll doesn't automatically start in that, yes, it counts bucket. What we're going to do is we are going to put this in the review bucket. Now I know this sounds a little bit backwards because engineers usually doing most of the technical work are going to qualify. But a payroll report in and of itself only tells you who got paid. It doesn't really tell you what type of qualifying activities or things that they were performing. This is easily one of the biggest areas folks trip up on all the time because some engineer time really does count towards the credit, but some engineer time is also, say, routine maintenance or bug fixes, implementation or customer support, or things that really don't rise to the level of technical qualification under the RD tax credit rules. At the same time, there are people without maybe say the engineer or the technical titles, but they could also have time that counts towards the RD credit. Say, for example, maybe they're doing direct supervision or support of the qualified work. Right there from the start, you're sorting by activity, not job title. This is a key concept I really want you to remember as we go through this because it's really crucial in getting it right from the start. So now what does belong in the count bucket? Generally, you're looking for direct work that's tied to a specific business component. Think project. If there was real technical uncertainty and a process of experimentation, that can include the direct work itself along with the supervision and support that is truly tied to the effort. And if you're wondering what this business component phrase really means, I really want you to get comfortable with it. Essentially means it is a project. And utilizing this and putting the projects into these business component areas, they're going to allow you to take a vague project or overarching story and really turn it into a specific project narrative that you can defend in front of the IRS. So think software development. This is not a project. It's too broad and it's too generic. You need to think of something more specific. Say, for example, you're doing a client-facing feature, a specific workflow, maybe a architecture change, or a new technical process. These are great examples of where you would look for those business components. Say your team had to build a new feature, work through how to structure the data, solve latency issues, maybe test alternatives under massive volume and iterate to get it working. That can be a very clean business component and would be a great example of a qualified project that you want to include. If on the other hand, you're talking about ordinary maintenance, maybe a standard dashboard work or incremental cleanup, those areas we would want to exclude entirely. And we'll talk about that a little bit more in the cut bucket. And a key point to this is that nothing belongs in the count bucket until you have named the work clearly enough to really stand on its own. Remember, the work needs to be tied back clearly to a business component or a project. Quick aside before we move on to the messy middle and review part. If naming your components already feels a little bit tough and fuzzy and not super clear, that's completely normal. And most companies don't naturally organize their work in tax language. It's totally fine, it's very fixable. And if you would rather have someone help you to map it out, there's a link below and we can go ahead and help you with that. Let's go ahead and let's keep going because the review bucket is where a lot of qualification dollars get missed. So now we are in the review middle bucket. This is where you start to slow down, and I want you to take your time here because this is where a lot of dollars often get excluded or oftentimes maybe erroneously get included in that count bucket. Let's keep looking through our example and the company spend. So let's go ahead and start with contractors. A lot of people assume contractor spend either fully counts or fully doesn't, sort of this yes or no. But the actual rule is much narrower and much more nuanced. Even if the underlying contract work is otherwise qualified, you're generally only counting 65% of that expense. So look right away, even a good contractor fact pattern does not come up dollar for dollar every single time. And what you have to review are the facts around the contract itself. Where was the work physically performed? What exactly is the contractor doing? Did your company bear the economic risks? And does your company retain the rights to those results? That is why contractors are going to be in this middle review bucket and not a direct count right away. Because a number or an invoice on its own doesn't answer those questions. If your company paid the contractor regardless of the outcome, and say your company kept the rights to the work of the product, that's often a much stronger starting point for what to include. But say if the contractor only got paid on success, or what you really did was buy a finished result rather than actually funding the research effort, then the answer can change pretty quickly as well. Contractors is almost always going to be in this review bucket and definitely deserves a second look. Now let's talk about another area that a lot of people miss cloud and computer rental. This is one of those areas where founders will often assume it's either obviously included or obviously excluded. And the truth is it's going to be much more nuanced. I know more nuanced, but hey, that's why we're going through this. If you have cloud spend and that specifically ties to a development activity and you can support it, there are absolutely can be a conversation of whether to include those expenses. For example, if you can separate a development environment from a production and that spend is really tied to the qualified US-based research activity, that may be something worth evaluating instead of automatically ignoring. Look, this isn't a simple area. This is not always going to be we have a big AWS bill and let's throw it in the RD tax credit. This is a position you take on purpose and with intent. You gotta have the documentation behind it, and it's one of those areas that should be reviewed carefully with your CPA or tax advisor before it goes anywhere near the final tax return. Still, it's a real area of opportunity, and it's one of those many areas that companies leave on the table simply because no one really stops to look and properly sort it out and look through the fact pattern. Let's talk about offshore work. Because hybrid teams are going to be extremely common nowadays. This is another area where founders can accidentally overcomplicate the issue. For credit purposes, offshore work generally does not belong in the account bucket. You're going to exclude those. That part is pretty straightforward. What people do wrong is they assume that once offshore work exists, the whole project becomes unusable. That's not the right way to think about it. You have to separate it. You keep the US-based pieces that may qualify, and then you carve out the foreign-performed work that does not belong in the credit. So, for example, if your company has US-based technical leadership, US-based design, testing, and oversight, and maybe you have an offshore dev team and QA kind of mixed in there, you don't want to throw the whole project away. You need to go ahead and sort it. That's why this is in the middle review bucket. It's so important for you to look at the facts and what's going on inside of the business to understand where do we put these different expenses. And that's why this is where maybe say a simple calculator or an automated solution can only take you so far. A calculator can only total a number and tell you a number result, but it cannot read the contract. It cannot separate the rights from the risk. It cannot tell you whether cloud spend is tied to qualified development or just mixed in a big operating budget. A person who understands your company and the specific fact pattern has to do that and it'll be super valuable when they do. Let me go ahead and pause here for a second because that contractor and cloud conversation is exactly where a lot of claims either get smarter or you know they tend to get a little bit sloppier too as well. Reading those facts carefully is a big part of what we do. And if you want to have a little bit of help with that, happy to go ahead and do so. There's a link in the bottom. You can go ahead and book a call. Now let's go ahead and move on to that last bucket, which is going to be the cut and exclude bucket. And I know this sounds a little bit backwards at first, but stick with me because people assume that the way to make the claim better is to make it bigger and add more in. But really the opposite is going to be true. I want a stronger claim, and oftentimes that starts with cutting the right things out. There are typically four things that I see land in the cut category all the time, and I definitely want you to start with these first. Okay, first, routine maintenance and brake fix work. We already talked about a little bit in the payroll context, but it belongs here specifically. Just because something is technical doesn't mean it's qualified research. So I want you to take a closer look. If you're not improving or you're building something new, it's really just keep the lights on, maintenance type activity. I want you to cut it out completely. The second thing I see, it's this standard top-down peanut butter spread qualification. And this is the classic 70% of engineering is RD and that's what's qualified. Now, this approach doesn't tie back to the specific business components. Remember, I said you need to get very comfortable with that terminology, but this is where the IRS is going. If they take this peanut butter approach, it's really a kind of estimate that feels super easy to do, but it's going to get extremely uncomfortable later if anybody asks about it. I want you to completely cut out that and look at things from the business component first. Third is going to be the offshore work. And look, I get it, I talk about this all the time. It's an area that you want to exclude, but it's extremely critical. This is a low-hanging fruit for the IRS. They can just look at it and say, hey, this is excluded, and they could do other things to your credit as well. Don't give them the option. If there are things that are offshore, look to where people are physically sitting and exclude their expenses entirely. Now let's go on to number four. Now, this is going to be customer-funded work. If the customer carried the risk and owns the rights to the result, if your company built something under those fact patterns, this is the kind of spend that belongs in this cut area. You do not want to count it at all. You want to exclude all of those costs. If we go back to our example team, the routine maintenance gets pulled out. The offshore implementation, that gets out of there as well. Anything clearly customer funded, also, that's thrown out. Ultimately, the claim becomes much stronger because of it. And that is the part I really want people to understand. A leaner claim is much better than a larger claim because the IRS is moving towards this business component disclosure and support package. If your claim is basically one big number with no real breakdown underneath it, you need to start doing this analysis and you need to start doing it consistently going forward. Some best practices you can start with right away are simply jotting down which business components were worked on during the year and then tie the different individuals and costs related to that work. Provide a one sentence of what the technical issue was, and that's a really good starting point. If you can do that throughout the year, then by the time it gets to the filing season, a lot of the sorting and that difficult work of going back and trying to figure it out is going to be over. Not every company needs a super detailed analysis. Those are the type of analysis that we do. Say, for example, your fact pattern is super clean, your team is super simple in the United States, your contractors are limited and there's no offshore exposure at all. And say you have really good documentation around the type of work that you're doing, then a sharp finance person can often run this and get a really good result, right? Where it starts to get a little bit more complex is when the fact patterns start to get mixed. You have a wage split and you have contractors, you have funded work. That's when things start to get extremely complex. And maybe you want to bring an expert in. To wrap up this video, if I had to boil this entire video down to one takeaway, it would be this run your team and spend through the buckets we just talked about. You have your yes, let's include it. This is the count bucket. Then we have, hey, maybe I don't know, we have a review bucket here, and finally we have eliminate and totally cut this all out. Those are the three different areas that you want to start organizing all of your expenses in. Now, if costs tie back to the business components we talked about, the technical uncertainties, the supportable US-based activity, that could be easily in the count bucket. If the facts are incomplete, it belongs in the review bucket. If it's routine or offshore or customer funded, that goes in the eliminate bucket completely. Now you have all the tools at your disposal. You can run this analysis by yourself, get your CPA involved, maybe your tax advisor, and start organizing your expenses in these different buckets so that you have a cleaner answer of does this work qualified for the RD tax credit? But look, if you would rather have a specialist help you out and walk you through it, there is a link below if you want to take that option. We can jump on a call and I can tell you how to organize your expenses in each one of the buckets. A quick note before we wrap everything I covered here today is educational contact only on generally how the RD tax credit works. Every company and the facts are going to be different. The actual numbers are going to be dependent on your specific situation. This is not individual tax advice for your company, so please check with your own CPA or tax advisor before you do anything and before you file. Thank you for watching, and again, I will see you in the next one.