What your CPA’s R&D-credit study will ask you for

Published 2026-08-15 · updated 2026-08-15

The study is theirs, the records are yours

Somewhere around Q3, most CPAs doing an R&D credit study for the first time send a founder the same email: a list of what they need, due in two weeks, to compute the credit before the return goes out. The founder who has spent the year running a company, not anticipating a tax study, opens it and sees line items that do not map cleanly onto anything the company tracks day to day.

The fix is not to learn to compute the credit yourself. Under IRC section 41, that computation — which activities meet the four-part test, how much of a given engineer's wages counts as qualified research expense, whether a given contractor cost is includible at 65% — is a determination for the firm doing the study, not a founder-side judgment call. What is a founder-side job is keeping the underlying records in a shape the study can actually use, all year, so the two-week request becomes a query against your own books instead of a reconstruction project.

This is the checklist behind that email: what a study asks for, why it asks for it, and which of it you can have ready before anyone asks.

Time by project, not time by department

The single largest line item in most startup R&D credit claims is wages, and the credit only reaches wages tied to qualifying research activity — not all engineering time, and not engineering headcount as a proxy. A study needs some evidence of how a person's time split across projects during the year, and "the whole team is R&D" is not that evidence.

What holds up is time tracked by project or ticket, even loosely — a Jira epic, a Linear project, a spreadsheet mapping engineers to initiatives by quarter. It does not need to be a stopwatch. A reasonable, contemporaneous allocation methodology (this engineer spent roughly 70% of Q2 on the new indexing engine, 30% on customer support rotations) is what the study is built from, and it is much easier to produce from a system that already exists than to reconstruct from memory in October.

The gap that actually costs credit is not sloppy time tracking — it is no time tracking at all, discovered the week the study starts, for a team that has since turned over.

Where the technical uncertainty lived

The four-part test asks whether the work resolved a genuine technical uncertainty — not whether it was hard, or new to the company, but whether the outcome or the method was uncertain at the outset in a way that required a process of experimentation to resolve. A study needs to see that uncertainty documented somewhere it was captured at the time, not narrated after the fact to fit the test.

In practice that evidence already exists in most engineering orgs: design docs, RFCs, architecture decision records, PR descriptions that explain why an approach was tried and dropped, sprint retros that note an approach failed and had to be redone. None of it needs to be written for tax purposes. It needs to survive — which mostly means not living only in a Slack thread that gets pruned, or in a wiki that gets migrated and half the pages don't make it across.

Business components matter here too. Form 6765 has a section for reporting qualified research expenses by business component — the product, process, or software feature the research related to — and starting with tax years beginning after 2025, that section stops being optional for most filers claiming the credit; a small-filer exception covers companies with $1.5 million or less in QREs and $50 million or less in average gross receipts filing an original return, and a separate exception covers qualified small businesses making the payroll-offset election. Grouping engineering documentation by feature or product line, rather than one undifferentiated engineering bucket, is what lets a study answer that question without re-deriving it from scratch.

Design docs and RFCs, kept somewhere durable
PR and commit descriptions that explain the reasoning behind an approach, not only the change itself
Sprint or retro notes on approaches that were tried and abandoned
A rough map of engineering work to product or feature (business component)

Contractors, employees, and the line between them

Contract research and employee wages are not interchangeable inputs to the credit — they are counted differently, and misclassifying one as the other is one of the more common defects a study finds late. A W-2 engineer's qualifying wages generally flow in at full value; a 1099 contractor's qualifying research expense is generally includible at a reduced percentage of what was paid, and only applies if the work meets the same research test.

The practical ask is simple even if the rule underneath it is not: a clean split, in the ledger, between W-2 payroll and contractor payments, with enough detail on the contractor side to say what the engagement was for. A general "contractors" expense line that blends a freelance research engineer with a marketing consultant and a fractional recruiter is exactly the kind of thing that turns a study into a line-by-line archaeology project instead of a report pull.

The same discipline extends to cloud and compute spend, which increasingly makes up a real share of a software company's qualified supply expense. A single AWS or GCP bill that blends production hosting, a staging environment used for experimentation, and unrelated internal tooling is much harder to substantiate than one where compute used for research is tagged or cost-allocated separately as it is incurred — by project, by environment, or by cost-center tag at the point of spend, not reconstructed from a year-end invoice PDF.

The payroll-offset election runs on a clock the study does not control

For a pre-profit startup, the research credit is often more valuable as a payroll tax offset than as an income tax credit that just carries forward against profits the company has not made yet. A qualified small business can elect under IRC section 41(h) to apply up to $500,000 of the credit against payroll taxes each year, offsetting the employer share of Social Security tax first and Medicare tax after that, in place of the income tax credit.

That election has one property founders consistently underestimate: it has to be made on the originally filed income tax return, on or before its due date including extensions, and it cannot be made on an amended return. A study that finishes after the extended deadline has passed loses more than time — for that tax year, the payroll offset path is closed, and the company is left with a credit that can only carry forward against income tax it may not owe for years.

That is the real cost of starting the records conversation late. It is not that the CPA cannot compute the credit eventually. It is that the election with the most near-term cash value has a hard filing deadline that does not move for a founder who is still assembling time records in September.

What "ready" actually looks like going into the study

None of the above requires building an R&D-tax-specific system. It requires running the systems a growing engineering org already has — project trackers, PR history, a chart of accounts — with enough discipline that qualifying activity is separable from everything else without a special project.

A chart of accounts that already splits R&D-coded wages and supplies from ordinary operating expense on a monthly basis, reconciled as part of routine bookkeeping rather than assembled once a year, is what turns the CPA's intake list from a fire drill into an export. That reconciliation is bookkeeping work — keeping the ledger detail clean and current — and it sits upstream of the credit study itself, which remains your CPA's computation, your CPA's Form 6765, and your CPA's election to make.

Sources

Reading about it is optional. The books aren’t.

A named accountant, software underneath, licensed partners where the law wants them.

Book a fit call