R&D tax credit claims live or die on documentation. Under IRC Section 41, a company must show that its research activities satisfy the four-part test — permitted purpose, elimination of uncertainty, process of experimentation, and technological in nature — and it must do so for every project, every year, with contemporaneous records that tie engineers’ time and wages to qualifying work. In practice, most finance teams inherit a mess: scattered Jira tickets, engineering standups recorded in someone’s memory, project wikis that were never updated, and a prior-year study prepared by an outside firm that no one can fully reconstruct.
The pain compounds at year-end. Controllers chase technical leads for narratives weeks after the work happened. Analysts rebuild wage allocations from payroll exports and guess at time percentages. CFOs sign returns knowing that if the IRS or a state examiner requests substantiation, the file may not survive scrutiny — and the downside is not just disallowed credits but penalties and interest on prior years. Meanwhile, the documentation burden pushes companies to underclaim, leaving legitimate credit dollars on the table simply because proving them is too expensive.
Claude Cowork changes the economics of this work. Because it operates directly on the files and folders where your evidence already lives — project repositories, meeting notes, payroll exports, prior studies — it can read source material at scale, extract the facts that map to the four-part test, and draft project-by-project narratives in your house format. The analyst’s job shifts from assembling documentation to reviewing and approving it. What used to take an outside firm six weeks and a five-figure fee becomes an internal workflow measured in days.
Where to start: a documentation map before any drafting
The most common failure mode is asking an AI tool to “write the R&D study” before anyone has defined what evidence exists and where. Resist that. Your first prompt should force Claude to inventory your source files, identify gaps against the four-part test, and ask questions — not produce prose. The output you want is a coverage matrix: which projects have adequate contemporaneous evidence, which need engineer interviews, and which should be excluded from the claim entirely. That matrix is also the artifact your CFO will want to see before signing anything.
First, read these files completely before responding:
[prior_year_study.md] — last year’s R&D study, including project narratives and qualified wage tables
[project_inventory.md] — list of all active and completed engineering projects for the tax year, with owners and date ranges
[payroll_export_notes.md] — description of payroll data fields available, including wage, bonus, and time-tracking granularity
[four_part_test_summary.md] — our internal summary of the permitted purpose, elimination of uncertainty, process of experimentation, and technological nature requirements
Here is a reference for what I want to achieve:
[Upload the prior-year coverage matrix or examiner-ready documentation index as markdown]
Here’s what makes this reference work:
Each project is mapped to the four-part test with a named evidence source (ticket system, design doc, test log). Gaps are flagged explicitly rather than papered over. Wage tie-outs reference specific payroll fields. Tone is factual and audit-oriented, with no marketing language about “innovation.”
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: coverage matrix table plus a one-page gap memo, roughly 800 words
Recipient’s reaction: the CFO should see clearly which projects are audit-ready and which need remediation before filing
Does NOT sound like: a sales pitch for the credit or a generic summary of what R&D is
Success means: every project in the inventory is classified as defensible, remediable, or excluded, with a named next action and owner for each gap
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
From coverage map to examiner-ready narratives
Once the coverage map is approved, the second prompt does the heavy lifting: drafting project narratives that read the way examiners expect. The discipline here is grounding. Every sentence in a narrative should trace to a source file — a design document showing uncertainty, a test log showing experimentation, a ticket showing iteration after a failed approach. Claude Cowork can enforce that traceability by citing the file behind each claim, which is precisely what makes the output defensible and what makes your review fast. Reviewers approve or reject citations rather than rewriting prose from scratch.
Keep the prior-year study in the working set as a style reference, but instruct Claude explicitly on what to preserve (structure, level of technical detail, wage tie-out format) and what to change (this year’s projects, updated time percentages, resolved uncertainties). And build in a human checkpoint: engineer sign-off on each narrative before it enters the file. The credit’s substantiation rules reward contemporaneous, credible documentation — an AI-drafted narrative that an engineer has reviewed and signed is stronger than a vendor-written one no one remembers producing.
First, read these files completely before responding:
[approved_coverage_matrix.md] — the coverage map we finalized, listing projects classified as defensible with their evidence sources
[prior_year_study.md] — last year’s narratives, to be used strictly as a structural and tone reference
[project_source_docs/] — folder of design docs, test logs, and ticket exports for the defensible projects
[house_style_guide.md] — our documentation standards, including wage tie-out format and prohibited language
Here is a reference for what I want to achieve:
[Upload one prior-year narrative that passed external review as markdown]
Here’s what makes this reference work:
It opens with the business context, then walks the four-part test in order with a specific technical uncertainty named. Each factual claim is attributable to a contemporaneous document. Wage figures tie to named payroll fields. Length is consistent across projects, and the language is technical but readable by a non-engineer examiner.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: one narrative per project, 400 to 600 words each, plus a wage tie-out table
Recipient’s reaction: an examiner should find each claim supported without requesting additional records; our engineers should recognize their work accurately described
Does NOT sound like: marketing copy, generic “we innovated” language, or a narrative with unsourced claims
Success means: every factual sentence carries a bracketed source citation to a file in the source folder, and zero claims rely on information not present in the files
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
A practical tip: run the coverage-map prompt in the first week of January, not at filing deadline. The gap memo it produces tells you which engineer interviews to schedule while the work is still fresh, and it gives your CFO an early, defensible estimate of the claim size. From there, the narrative prompt becomes a repeatable annual workflow — and each year’s approved file becomes the style reference that makes the next year faster.
Published on 8 November 2026 on growwithgpt.com