Five Myths That Keep Technology Consulting Firms From Claiming the R&D Credit

TL;DR

• The credit looks at the work and the people doing it, not your job title or your billing model. Architects, tech leads, and the first-line managers who run the work can matter, not only the developers writing code.
• Discovery, proofs of concept, and abandoned approaches can all show real technical uncertainty and experimentation. A prototype that did not ship does not disqualify the work.
• Using established frameworks or cloud services does not rule you out, but routine configuration and customer-specific adaptation of an existing solution generally do not qualify. The line depends on the facts.

Why consulting firms count themselves out

Ask a consulting principal whether their firm does research and development and you often hear, “No, we implement for clients.” That reflex is understandable. The R&D credit has a reputation as a lab-coat incentive for product companies, and consulting firms bill by the hour or by the project instead of selling a product.

The credit itself is narrower and more practical than that reputation. Under IRC Section 41, qualified research is activity undertaken to discover information that is technological in nature, intended to help develop a new or improved business component, where substantially all of the activity is part of a process of experimentation. Computer science counts as a field the experimentation can rely on, and Treasury Regulation 1.41-4 walks through each element. None of that depends on whether you sell software or sell expertise. It depends on what your people actually did on a given project, depending on the specific activities, documentation, and facts.

Here are five beliefs we hear from technology consulting firms that may be keeping them on the sidelines.

Myth 1: “Only our developers count”

It is natural to assume the credit follows the keyboards. In practice, wages for qualified services can include more than the person writing code. The statute counts time spent engaging in qualified research, and also time spent on direct supervision or direct support of that research. The regulations describe direct supervision as the immediate, first-line management of the research, and direct support as services that support the people doing or directly supervising it.

For a consulting firm, that can mean a solution architect shaping the design, a tech lead running the engineering effort day to day, or a QA engineer testing experimental builds. It generally does not stretch to higher-level management above the first line, or to general administrative functions such as payroll, accounting, or officers handling financial and personnel matters. The practical takeaway is to look at roles by what they did on specific projects, not by title, and to expect the exclusions to apply to some of your overhead. The rules for each role are in Treasury Regulation 1.41-2.

Myth 2: “Discovery and architecture are planning, not research”

Early-phase work can look like pure scoping from the outside. But when a team is genuinely unsure whether a design will meet a performance target, whether two systems can be made to interoperate, or which of several architectures will hold up under load, the uncertainty is technical. The regulation describes uncertainty as existing when the information available does not establish the capability, the method, or the appropriate design for the component.

Spikes, proofs of concept, and comparative testing of alternatives are the kinds of activity that may show a process of experimentation. Work that is really requirements gathering, market research, or management-related activity is a different story, because the statute excludes efficiency surveys, management-related activities, and market research. So the honest answer is that it depends on what happened in the room and in the repo, and that is exactly why the records matter.

Myth 3: “We use standard frameworks and cloud services, so nothing is uncertain”

Building on established tools does not by itself take you out of the credit. The question is whether the uncertainty sits in how you combine and extend those tools to reach a result the available information did not establish, such as a scale, latency, security, or integration outcome that was not a known quantity going in.

There is a real boundary here. The statute excludes research that adapts an existing business component to a particular customer’s requirement, and research that duplicates an existing component. Standard configuration of a platform, routine deployment, and customizing a known solution to a client’s preferences generally fall on the wrong side of that line. Genuinely new technical work built for a client’s problem can fall on the right side. Many firms have both kinds of work in the same quarter, which is the reason a project-by-project look tends to be more useful than a blanket yes or no.

Myth 4: “If the prototype got scrapped, there is nothing to claim”

This is one of the most common and most costly assumptions. The regulation says outright that qualifying does not require the taxpayer to succeed in developing the new or improved component. An approach that was tested and abandoned can still be part of a process of experimentation, because evaluating alternatives is the point of the process.

Success is not the test, but support is. A scrapped approach is easiest to stand behind when someone captured what was tried and why it was dropped, even in a short ticket comment or a design note. Teams that routinely write down the reason for a pivot tend to find that their normal engineering habits already produce much of what a study needs.

Myth 5: “A study will pull our delivery team off billable work”

For a firm whose revenue walks out the door when engineers are in meetings, this concern is reasonable. It is a bandwidth objection, not an eligibility one, and it deserves a direct answer. Strata starts with a $0 initial assessment to size the opportunity before you commit to anything. The engagement itself follows a structured, guided process, typically four to eight weeks depending on how quickly information comes in, and most of the work sits with Strata rather than your team. Your team’s time commitment is modest, and the end product is a documentation package built to support the claim, which you pass to your CPA, who files the return with it. Individual timelines vary.

Strata also offers more than one way to engage, from a lighter, platform-led path to a fuller-service one, so owners can match the level of involvement to the team they can spare.

How to tell where your firm stands

A simple self-check can be done in an hour. Pick three recent projects and ask: Was there a point where the team did not know whether a design would work? Did anyone test more than one approach? Can you point to a ticket, commit history, or design note that shows it? If the answer to any of those is yes, it may be worth a closer look. If you cannot say yes to any of them, that tells you something useful too.

Next step

If you are not sure whether your firm’s work qualifies, a 15-minute review is a low-effort way to find out. We will help you size the opportunity and answer your questions at no cost through our $0 initial assessment. Reach out at stratataxgroup.com/contact.

For background on how the credit is reported, the IRS publishes About Form 6765, Credit for Increasing Research Activities.

This post is for informational purposes only and does not constitute tax or legal advice. Consult a qualified tax professional regarding your specific circumstances.