How to explain your R&D for an SR&ED claim

Start with a stretch of development where the team had to test an approach because the available knowledge did not provide an answer. Open the design note and the results, then walk through the decision that followed. That sequence gives us a useful starting point for the technical report.

You do not need to arrive with a finished technical report. A conversation with the people who did the work, supported by their project records, gives us the material to write it. Cedar’s senior claim preparer leads that discussion, identifies the SR&ED projects, and writes the technical descriptions for your team to check.

Invite someone who did the work

Start with the person who can explain the technical decisions and results. That might be a founder, engineer, scientist, or technical lead. A project manager can help with the timeline; the people running the work can explain why an approach was chosen and what happened when they tested it.

For a project with several contributors, one person can lead the walkthrough and bring in colleagues for specific questions. Find the main design notes or test files beforehand so the discussion can follow the work itself.

Explain what the team could not resolve

Separate the product goal from the technical problem. “Handle more users” explains the business need. It does not yet explain the knowledge your team needed to develop.

For example, a team might investigate whether a new way of distributing work can meet a latency target while preserving consistency under unpredictable traffic. The useful detail is which known approaches they evaluated, where those approaches fell short, and what remained uncertain. Routine capacity increases using an established design are separate from that investigation.

The CRA’s eligibility guidelines connect eligibility to an attempt to advance scientific or technological knowledge through systematic experiment or analysis. The assessment considers knowledge available within the business and from reasonably accessible public sources. Start with what the team knew at the time, then explain the gap.

Follow one attempt into the next

Choose a sequence you know well and walk through it in order:

• What did you expect the first approach to do?
• How did you test or analyse it?
• What did the result show, including anything unexpected?
• What did you change next, and why?

A result that ruled out an approach can be useful. An investigation can qualify even when it does not meet the original technical objective. Record the findings and the limits identified by the tests.

Use the language you would use with a technical colleague. Cedar translates the discussion into a project description; you check that it accurately explains the work.

Open the records during the conversation

A useful starting set is the design document, a test plan or analysis, the results, and the issue or note that explains the next decision. For manufacturing or laboratory work, the equivalent might be trial-run sheets, batch records, lab notes, and measurements.

Keep the original dates and links. If the explanation lives across several tools, a short index is enough to help us find it. Our recordkeeping article shows how to connect those pieces.

Agree what still needs an answer

We finish the discussion with a short list of follow-ups: a missing result, a date to confirm, or another contributor to speak with. Your team supplies the technical facts. Cedar handles the project scoping, report writing, cost reconciliation, tax schedules, and filing coordination with your accountant.

When the draft arrives, read it as the person who did the work. Check the reasoning, dates, and conclusions, and correct anything that changes their meaning. This review is easier when the description follows a sequence you recognize.

Tell us what you’re developing. Cedar will lead the project assessment and turn your team’s account of the work into the claim.