R&D Tax Credit Study Software: What It Costs to Run Hundreds of Defensible Studies a Year Without Rebuilding Every Substantiation File by Hand

Why credit studies quietly eat a consultancy's margin

A manager is closing a study for a manufacturing client with 340 employees. She needs qualified wages, which means deciding which employees performed, supervised or directly supported qualified research, and what share of their time went to which business component. Payroll gives her box one wages and a cost centre. The client's project accounting system gives her job numbers that do not map to business components. Engineering uses a ticketing tool where the useful evidence lives, but tickets are titled things like fix line three and nobody outside the plant knows which of those involved genuine technical uncertainty. So she runs interviews, takes notes into a Word file, builds a time allocation matrix in Excel, and writes narratives from scratch. Next year, a different manager will do the same work for the same client because none of this year's structure survived in a form anyone can reuse.

The tooling that exists serves a different buyer. Neo.Tax and Boast.ai are built to automate credits for technology companies where engineering time already sits in a ticketing system, and they do that well. Clarus R and D serves small and mid-sized claimants directly. None of them encodes a consultancy's own methodology: your four part test documentation standard, your business component hierarchy, your interview protocol, your audit defence file structure, and your view on what a defensible allocation looks like. Your methodology is the thing clients pay for, and it currently exists as a template folder and the habits of your senior staff.

Problem 1: the credit lives at the business component level, not the project level

Section 41 requires the four part test to be satisfied for each business component: a permitted purpose, a technological in nature requirement, the elimination of uncertainty, and a process of experimentation. The credit is not computed on a department or on an engineering budget. It is computed on qualified research expenses tied to components, and the shrinking back rule means that when a whole product does not qualify you test at the subcomponent level.

Generic tax software has no model for this, and neither does a spreadsheet with a project column. The build makes the business component a first-class record with a hierarchy, a four part test assessment with the evidence supporting each prong, the time period it was under development, and the expenses allocated to it. Wages then attach to components through allocations rather than to a client-wide pool. That single structural decision is what makes an examination survivable, because the examiner does not ask about the credit, the examiner asks about a component, and if your file can produce the component, its uncertainty, its experimentation and the people who worked on it, you are in a conversation rather than a defence.

Problem 2: three source systems that will never agree

Payroll knows wages and employees. Project accounting knows job costs and sometimes hours. Engineering tooling knows work but not money. Nothing knows business components. The reconciliation between them is manual in almost every practice, and it is where the hours go.

Build the ingestion once and reuse it across every client on that stack. A payroll extract normalises to employee, period and wage type. A project accounting extract normalises to job, employee and hours. Engineering exports normalise to work items with dates and assignees. Then the mapping layer, which is client specific and versioned, links jobs and work items to business components. The crucial design decision is that the mapping is a client asset that persists between years, so year two starts from last year's structure with a delta review rather than a blank workbook. Practices that make this change typically find the second year study takes a fraction of the first, and that compounding is where the return on the build actually lives, not in the first engagement.

Problem 3: interviews evaporate between study years

The substantive evidence for uncertainty and experimentation comes from people: the engineer who explains that they did not know whether the new alloy would hold tolerance at temperature, and tried four approaches. That conversation happens once, gets summarised into a narrative, and the underlying detail disappears into a manager's notes. Next year the same engineer is asked similar questions again, gives a slightly different answer, and the two years' files now describe the same work differently.

Capture interviews as structured records against components: who was interviewed, when, which component, what uncertainty was described, what alternatives were evaluated, what evidence exists elsewhere. Attach the transcript or recording where the client permits it. Machine assistance has a real and narrow role here: transcription, then a drafting pass that proposes narrative language grounded strictly in the interview record for a professional to edit. It must never invent technical detail, and the system should make the provenance of every narrative sentence traceable back to the interview or document it came from. A narrative nobody can source is a liability, not a deliverable.

Problem 4: state credits are not a multiplier on the federal number

Practices lose money quietly here. Several states operate their own research credits with different qualifying expense definitions, different base period calculations, different apportionment of in-state activity, and their own forms and deadlines. Treating the state credit as a percentage of the federal result is fast, wrong, and creates exposure for the client and for you.

The build handles this by keeping expenses at their most granular form, tagged with the location where the activity occurred, so a state computation can be run on its own rules rather than derived from the federal answer. Base period data has to persist across years for the states that need it, which is another reason the client record must be durable rather than a per-engagement workbook. Model each state as a rule set with its own effective dates, because states change these provisions and your file for an earlier year has to reflect the rules in force then.

Problem 5: the substantiation package is the actual product

Clients think they are buying a credit number. What they are actually buying is the ability to keep it. The Internal Revenue Service tightened what must accompany a research credit refund claim on an amended return, requiring identification of business components, the research performed, the individuals involved and the information sought, which pushed the market toward exactly the structure described above. Separately, the treatment of research expenditures under section 174 has moved legislatively in recent years, which means a study's supporting data needs to be reusable for computations beyond the credit itself.

Design the output as an assembled evidence file, not a report. Component register, four part test assessment per component with evidence references, wage allocation with methodology and interview support, supply and contract research schedules, the computation with both the regular and alternative simplified approaches shown, and an index. Store it immutably at delivery with a hash, because when an examination begins three years later the first thing that matters is proving what you gave the client at the time. Practices that can produce that in minutes negotiate differently from practices that start reassembling.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for study management software. A focused first release covering the client and business component model, payroll and project data ingestion, wage and supply allocation, interview capture and substantiation package assembly runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding state credit rule sets, connectors to common payroll and engineering systems, a client evidence portal, multi-year roll forward and practice level reporting on study economics runs $200,000 to $450,000 phased over 8 to 14 months.

What drives price up in this category: the number of source systems you want connected, since every payroll provider and engineering tool is its own integration and clients will not standardise for you. The number of state rule sets modelled. Whether you serve more than one jurisdiction internationally, because a United Kingdom claim under the research and development relief regime has a different structure and now requires an additional information submission to HM Revenue and Customs before the claim, which is a separate workflow rather than a variation. And how much of your methodology is written down: if your standard is in senior people's heads, expect several weeks of structured sessions to extract it, and treat that as the most valuable part of the project rather than overhead.

Build versus buy, and when buying is right

Buy, and do not call us, if you deliver a small number of studies a year, mostly for software companies whose engineering time is already recorded in a ticketing system. Neo.Tax and Boast.ai automate that profile well and cost a fraction of a build. If you are a claimant rather than a consultancy, buying is almost always right unless your research operation is genuinely unusual.

Build when two or more of these are true. You run enough studies a year that a percentage point of delivery efficiency is meaningful revenue. Your clients are in industries the automated tools do not serve well, meaning manufacturing, food science, construction, agriculture and anything where the evidence lives in plant records rather than pull requests. Your methodology is a differentiator you sell against the large accounting firms, and it currently lives in templates. You want year two of a client to cost materially less than year one, which requires persistent client structure that per-engagement workbooks cannot provide. Or you have had a study examined and discovered that reassembling the file took days of unbillable senior time. That last one tends to be the moment practices call.

How to choose a developer for credit study software

Ask them to model the four part test on a whiteboard. A team that has done this work will attach the assessment to a business component rather than to an engagement, will ask about the shrinking back rule, and will want to know how you evidence each prong. A team that draws a project with a qualifies checkbox has not read section 41 and will build you a timesheet tool.

Ask how narrative drafting is grounded. If a language model is involved, every generated sentence must be traceable to an interview record or a document, and the professional must edit before anything reaches a file. A system that produces fluent unsourced narrative is actively dangerous in this field, and any developer who does not raise that themselves has not thought about your exposure.

Ask how year two works. The correct answer describes carrying forward the component structure, the mapping and the base period data, then running a delta review. If the answer is that you start a new study, the tool will not change your economics.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes the code is yours from the first commit. Your methodology encoded in software is a firm asset that affects your valuation, and it should not sit inside a vendor's product you licence.