R&D Tax Credit Study Software Problems: The 7 That Cost Real Margin, and How to Avoid Them

Why does the data model get built around engagements instead of components?

Because that is how the practice bills and how the project plan is structured, so the software quietly inherits it. An engagement is created, a workbook is attached, work happens inside it, a deliverable comes out, the engagement closes. It maps neatly onto how a consultancy runs and it is the wrong spine for this system.

Section 41 operates at the business component level. The four part test, a permitted purpose, technological in nature, elimination of uncertainty and a process of experimentation, has to be satisfied for each component, and the shrinking back rule means you test at subcomponent level when a whole product does not qualify. An examiner does not ask about your credit. They ask about a component. If the file can produce the component, its uncertainty, its experimentation and the people who worked on it, you are in a conversation. If your structure is engagement then spreadsheet then narrative, you are in a defence.

The fix is to make the client the durable record and the business component a first class entity beneath it, with a hierarchy, a four part test assessment carrying evidence references for each prong, the period it was under development and the expenses allocated to it. Wages attach to components through allocations rather than to a client wide pool. Engagements then become the annual event that adds a year of data to a permanent client structure. That one decision is what makes year two a delta review instead of a rebuild, and it is very hard to retrofit once the schema is live.

What goes wrong ingesting payroll, project accounting and engineering data?

Three source systems, none of which knows what a business component is, and all three disagree with each other. Payroll knows employees, periods and wage types. Project accounting knows jobs, and sometimes hours, under a coding scheme built for job costing rather than for research. Engineering tooling knows work but not money, and the ticket titles are things like fix line three.

The failures are consistent across practices. Employee identity does not match across systems, because payroll carries a payroll identifier while the engineering tool carries an email address that changed when the client renamed their domain. Hours sit against jobs opened and closed mid year, so a component's development period and the job's life do not line up. And the client sends an export dated after a payroll correction, so totals move between extracts and nobody notices which version an allocation was built on.

The fix is to normalise once and reuse across every client on that stack, keep the raw extract immutably beside the normalised record so any number can be traced to a file, and put the client specific mapping from jobs and work items to components in its own versioned layer. Reconcile total wages loaded against the payroll control total on every import and fail loudly on a mismatch rather than proceeding with a partial load. A study built on ninety six percent of the wage file is not a study, it is a rounding error waiting to be found by somebody else.

Why do the integrations that matter break after launch?

Connectors in this category degrade for a reason that is specific to consultancy work: the systems belong to your clients, not to you, and your clients will not standardise or warn you before they change something.

A client migrates payroll providers between years and the identifier scheme changes underneath a mapping you spent days building. A general ledger restructure renumbers the job codes your component mapping depends on. An information security review revokes the integration credential, and nobody tells the engagement team until an import fails silently in March.

The fix is to design for change rather than for stability. Treat every connector as one parser per source with strict schema validation and a blocking failure, not a tolerant read. Store the mapping as versioned client data so a provider change becomes a new mapping version with the old one intact for prior years, rather than an edit that rewrites history. Monitor credential health and import freshness so a broken connection surfaces the week it breaks. And design a file based fallback for every connector, because a meaningful share of clients will only ever send you an export by email, and a system that cannot accept one will be worked around within a month.

What happens when state credits and substantiation standards are not covered?

Two gaps quietly transfer risk from your client's balance sheet onto your firm.

The first is state credits treated as a multiplier on the federal number. 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. Deriving the state result from the federal one is fast, wrong, and creates exposure for both the client and the practice. It also fails silently, because nothing about the output looks different.

The second is a substantiation package assembled as a report rather than as an evidence file. The Internal Revenue Service tightened what must accompany a research credit refund claim on an amended return, including identification of business components, the research performed, the individuals involved and the information sought. Separately, the treatment of research expenditures under section 174 has moved legislatively in recent years, which means the underlying data has to be reusable for computations beyond the credit itself.

The fix is to keep expenses granular and tagged with the location where the activity occurred, so a state computation runs on its own rules rather than being derived, and to model each state as a rule set with effective dates because these provisions change. Then design the output as an assembled file: 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 showing both the regular and alternative simplified approaches, and an index. Store it immutably at delivery with a hash, because when an examination opens three years later the first thing that matters is proving what you gave the client at the time.

Should you build custom or configure what you already own?

If you deliver a small number of studies a year, mostly for software companies whose engineering time already sits in a ticketing system, buy. Neo.Tax and Boast.ai automate that profile well and cost a fraction of a build. Clarus R and D serves small and mid-sized claimants directly and is a sensible answer for a firm whose credit work is adjacent to a broader tax practice rather than central to it. 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 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 anywhere the evidence lives in plant records rather than pull requests. Your methodology is what you sell against the large accounting firms and it currently exists as a template folder. You need year two of a client to cost materially less than year one. Or you have had a study examined and found that reassembling the file took days of unbillable senior time. That last one is usually the call we receive.

How do hidden costs get into the quote?

A focused first release covering the client and business component model, payroll and project data ingestion, wage and supply allocation, interview capture and substantiation assembly runs $70,000 to $150,000 over 12 to 18 weeks in our delivery experience. A full platform adding state rule sets, connectors, a client evidence portal, multi-year roll forward and practice reporting runs $200,000 to $450,000 over 8 to 14 months. The overruns are predictable.

• Source system count. Every payroll provider and engineering tool your clients use is its own integration, and clients will not standardise for your convenience. Scope the connectors you will actually build and accept file uploads for the tail.
• State rule sets. Each one is legal research plus engineering, and practices routinely list the states they file in without noticing how many distinct rule models that implies.
• Methodology extraction. If your standard lives in senior people's heads, expect several weeks of structured sessions to get it written down. This is the most valuable part of the project and it costs your best people's time, which is the time you can least afford to release.
• A second jurisdiction. A United Kingdom claim under the research and development relief regime is a separate workflow rather than a variation, and now requires an additional information submission to HM Revenue and Customs before the claim, which changes the sequence of work rather than just the output.

What separates a build that works from one that fails here?

Ask a prospective developer to model the four part test on a whiteboard. A team that has done this work attaches the assessment to a business component rather than to an engagement, asks about the shrinking back rule, and wants 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 with a tax label on it.

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 a professional must edit before anything reaches a file. Fluent unsourced narrative is a liability in an examination rather than a time saving, and a developer who does not raise that themselves has not thought about your exposure.

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

Sequence the client and component model, ingestion and allocation first. State rule sets, portals and practice dashboards are worth having and they depend on a spine that has survived a real filing season.

Settle code ownership 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 what the practice is worth, and it should not sit inside a product you licence from somebody else.