R&D Tax Credit Documentation: What to Keep and How to Organize It

An R&D credit is only as strong as the records behind it. The IRS can generally examine a return for three years after it is filed, and credits you carry forward can be questioned again in the year you use them, so records from 2023 may matter in 2030.

If you cannot show what your team worked on, why the outcome was technically uncertain, and how you tied wages and costs to those projects, an examiner can disallow the credit. After-the-fact reconstruction is the usual weak point: it reads as guesswork and tends to overstate qualifying time.

Under IRC Section 41, qualifying research must satisfy four criteria for each business component: permitted purpose (functional improvement), technological in nature (relying on hard sciences or engineering), technical uncertainty (outcome, method, or capability was uncertain at the outset), and process of experimentation (systematic evaluation of alternatives). Your documentation needs to address each prong. This does not mean writing a lab notebook for every Jira ticket. It means your project descriptions, sprint retrospectives, and technical design docs should capture the uncertainty your team faced and the approaches they tried or discarded.

For software companies, the most useful records include technical design documents or architecture decision records that explain why a particular approach was uncertain. Git commit histories and pull request descriptions that show iterative experimentation are valuable. Time tracking data or payroll records that allocate developer hours to qualifying projects are essential. Cloud infrastructure invoices tied to development and testing environments, not production, should be preserved. Contractor agreements and invoices for engineers performing qualifying work also matter. You do not need to create new paperwork. The goal is to tag and organize records you are already generating.

The most reliable approach is a quarterly review. At the end of each quarter, your engineering lead spends 30 to 60 minutes with your tax advisor reviewing active projects. You identify which projects involved technical uncertainty, estimate the percentage of time spent on qualifying activities versus routine development, and flag any new contractors or cloud expenses. This cadence keeps documentation current without creating a burden. It also means your annual credit calculation is a straightforward rollup, not a frantic year-end reconstruction.

The IRS revised Form 6765 and added Section G, which asks for information by business component: what each component is, the information you sought to discover, and the wages, supplies and contract costs tied to it. Section G is optional for tax years beginning before 2026. Under the December 2025 Form 6765 instructions, it is required for tax years beginning after 2025, with two exceptions: a qualified small business that elects the payroll tax credit, and a taxpayer whose controlled-group QREs are $1.5 million or less, whose average annual gross receipts for the prior three years are $50 million or less, and who claims the credit on an original return (checked October 2026).

Refund claims on amended returns have their own rule. Under the IRS refund claim FAQs as updated in June 2024, a valid claim must identify all business components the claim relates to, the research activities performed for each, and the total qualified wage, supply and contract research expenses, which you can report on Form 6765. The IRS dropped the requirement to name the individuals and what each sought to discover, but it can still ask for that information in an exam. The IRS extended the transition period in which it lets taxpayers fix a deficient claim within 45 days of a notice through January 10, 2027.

If your records are organized by project from the start, both requirements become a reporting exercise instead of a research project.

The fastest way to organize R&D records is by the four places QREs come from, because that is how Form 6765 and an examiner will look at them.

• Wages. Payroll registers by employee, job titles and descriptions, an org chart showing who supervised whom, and the time allocation for each person (project codes, sprint reports or documented manager estimates). Under the regulations, if 80% or more of a person's services are qualified services, all of that person's wages can count.
• Supplies. Invoices for materials consumed in research, such as prototype components or test materials. Equipment you depreciate is not a supply.
• Computer use. Cloud bills split by environment, with tags or account structure showing development and testing separately from production.
• Contract research. Signed agreements showing the work is performed in the United States, that you bear the risk if it fails, and that you keep substantial rights to the results, plus invoices and a description of what each contractor did.

Add a short project list for each year naming the business components, what was uncertain, and what alternatives were tried. That list is the backbone of Section G.

A good record for a single business component fits on one page and points to evidence that already exists. A hypothetical example for a SaaS company:

1. Business component: a new real-time sync engine for the mobile app.
2. Uncertainty at the start: whether conflict resolution could keep sync latency under 200 milliseconds with offline edits from several devices.
3. Alternatives evaluated: last-write-wins with timestamps, operational transforms, and a CRDT-based design, each prototyped and load tested.
4. Outcome: the CRDT design met the target after two rounds of changes; the other approaches were dropped.
5. People: three engineers at an estimated 70% of their time for two quarters, and one engineering manager at 20% for direct supervision.
6. Costs: the wages above, plus $8,000 of cloud costs for the load-testing environment.
7. Evidence: the design document, the architecture decision record, the pull requests for each prototype and the load-test results.

Written during the project, that page takes an engineer twenty minutes. Rebuilt two years later, it takes days and convinces no one.

Keep R&D credit records until the statute of limitations closes for the last year in which the credit is used, not just the year it was earned. The general assessment period is three years after the return is filed, but research credits that you cannot use right away carry forward for up to 20 years.

A labelled example: a startup earns a credit in 2026, applies part of it against payroll taxes, and carries the rest forward until it becomes profitable in 2031. The IRS can examine the 2026 calculation when it reviews the 2031 return, so the 2026 records need to survive until at least 2035.

Base-period records matter too. Under the ASC, QREs from the three prior years determine the current credit, so the documentation for those years has to remain available while the later credit can still be examined.

Auditors focus on a few common issues. Credits that spike dramatically year over year without a corresponding change in headcount or project scope raise questions. Claims where 100% of engineering time is allocated to R&D suggest a lack of honest assessment. Documentation created after the fact, especially if it all has the same date stamp, undermines credibility. Finally, claiming activities that are clearly routine, like bug fixes, UI reskinning, or data entry, signals that the four-part test was not rigorously applied. This is general information as of October 2026, not tax advice for your specific facts.