What should your study document?
An R&D tax credit study is often used to organize an activity review and the related calculation. Its value depends on how clearly it connects the narrative to the actual business records. A polished report cannot replace evidence of the work performed and the expenses incurred.
Paribus Advisors assembles your R&D tax credit study package around the projects and records that support the claim. The preparation should explain what was reviewed, how relevant amounts were identified, and where a reviewer can find the source material. It should also distinguish confirmed facts from items that still need clarification.
Think of the file as a connected record: a project description leads to technical evidence, that evidence identifies people or activities, and an expense schedule explains the associated amounts. When those connections are visible, your tax team can ask more useful questions and review the work more efficiently.
What’s included in your
R&D tax credit study?
See how the pieces of an R&D tax credit study fit together.
- 01
Research activities
What was developed, what was uncertain, and how alternatives were tested.
- 02
Qualified expenses
The wages, supplies, and outside research evaluated for inclusion.
- 03
Credit calculations
Federal and state calculations with supporting expense details.
- 04
Supporting workpapers
Activity narratives, expense schedules, and links to source records.
A practical R&D documentation checklist.
Start with the records your business already creates. A project management system, engineering notebook, source-control history, or purchasing file may contain pieces of the story. The first task is to identify what exists and who can explain it.
| Record group | Examples to gather | Question it helps answer |
|---|---|---|
| Project context | Project briefs, specifications, design objectives | What was the team trying to develop or improve? |
| Technical work | Test results, design revisions, prototypes, development notes | What alternatives were considered and evaluated? |
| People and timing | Assignments, time records, payroll reports | Who worked on the project, and when? |
| Costs and agreements | Invoices, contracts, expense ledgers | What amounts relate to the reviewed work? |
| Historical context | Prior calculations and relevant financial schedules | What inputs or decisions carry into this review? |
This checklist is a starting point, not a universal substantiation standard. The appropriate evidence depends on the activities, expense category, and facts. Keep the original records; a summary spreadsheet should point to them rather than replace them.
Explain what your team developed and tested.
Describe the project so someone who was not involved can understand what happened. Describe the objective, the technical questions the team faced, the alternatives it considered, the evaluation performed, and the resulting decisions. Use dates and project identifiers that connect to supporting records.
Avoid substituting phrases such as “highly innovative” or “cutting-edge” for a factual explanation. Those descriptions do not explain an experiment or identify a cost. Plain language about a design change, a test condition, or a failed approach is often more informative.
Ask a person familiar with the work to review the narrative for accuracy. Finance may know the costs while engineering knows the development sequence. Bringing those perspectives together helps prevent an expense schedule and a project description from telling different stories.
Show where each expense came from.
Each calculation input should have an identifiable source and a clear explanation. Use a consistent project code or reference across the narrative, expense file, and supporting records. Document adjustments and remove duplicate entries before preparing the final schedule.
Where a method is used to allocate time or costs, record the basis and the information supporting it. Do not disguise an estimate as a contemporaneous record. If a source is incomplete, identify the gap and discuss how it affects the review.
Separate the original data from working versions. A simple folder structure can include source records, activity summaries, expense analysis, calculations, and open questions. Keep a dated record of material revisions so your team can identify which version was reviewed.
What to do when the records are incomplete.
Start by listing the records you still have. List the records available, the missing information, and the people who may be able to clarify the facts. Historical emails or project archives may provide context, but a retrospective explanation should be identified honestly.
Do not create documents that appear to have been written at the time if they were prepared later. The goal is an accurate account of the available evidence. A review may find that some activities or costs cannot be supported adequately; that should be reflected in the preparation.
The IRS cautions that a research credit study alone is unlikely to substantiate a claim. Its documentation guidance emphasizes the underlying evidence. Our approach to preparation therefore keeps the connection between the report and source records central to the work.
For future years, consider a light recurring routine: preserve key project milestones, retain test records, and record who can explain each project. Discuss the appropriate process with your tax team so documentation becomes part of normal operations rather than a year-end reconstruction exercise.
More help with your R&D credit.
Review employee wage support and contract research arrangements while organizing the expense schedules.