Key Takeaway
SR&ED claims aren't won in the spring filing meeting. They're won during the year, by keeping dated hypotheses, failed PRs, recorded decisions and weekly time allocations, and you can test one active project against a 10-question evidence-gap check this week.
Most SR&ED (Scientific Research and Experimental Development) claims don’t lose value at filing. They lose it during the year, when nobody writes down what was uncertain and the failed experiments disappear. This article is for CTOs, engineering leads and finance owners at Canadian software companies who want a claim built from records, not memory. It ends with a 10-question check you can run on one active project before your fiscal year closes.
Every spring, the same meeting happens. Finance has the T2 (corporate income tax return) deadline on the calendar. The SR&ED advisor has sent a questionnaire. The CTO and two senior engineers sit down to explain what the team was uncertain about in March of last year, which approaches they tried, and why the first two didn’t work.
They remember the approach that shipped. What they can’t reconstruct with confidence is the part the Canada Revenue Agency (CRA) cares about most: the hypothesis before the answer was known, the experiments that failed, and the hours behind each.
That meeting feels like the moment the claim gets built. It isn’t. The value was decided months earlier, every time a failed spike got squashed into a clean merge, a design decision stayed in a Slack thread, or nobody recorded which engineers spent which weeks on the hard problem.
This is general information, not tax advice. Your SR&ED advisor or accountant validates what qualifies and how it’s claimed.
What does CRA actually say about SR&ED records?
CRA says records kept “throughout all phases of your SR&ED work” support the claim and may reduce errors, and that “documentation that is dated, signed, and specific to the work performed is best.” Its “Get ready to claim” page lists time sheets and activity records right next to project records.
The clearest recent signal is the pre-claim approval process CRA opened on April 1, 2026, for eligible businesses with annual gross income under $25 million. The application asks you to “outline how you will track SR&ED work and associated expenditures, including documentation practices” and how you “will maintain contemporaneous documentation throughout the project.” It also asks for evidence of due diligence showing that existing knowledge and approaches weren’t enough.
Contemporaneous records aren’t a strict legal precondition for every claim. Courts have accepted credible evidence produced later. But reconstructed evidence carries less weight than a dated record made at the time, and it costs far more to produce.
The stakes went up this year, too. Bill C-15, which received Royal Assent on March 26, 2026, raised the expenditure limit for the enhanced 35% refundable credit from $3 million to $6 million. It also restored eligibility for capital expenditures on property acquired on or after December 16, 2024. More spend qualifies for the enhanced rate now, so more of it depends on evidence.
Where does SR&ED evidence leak out of a normal sprint?
At merges, kickoffs, Slack threads and timesheets. None of these leaks come from carelessness. They come from good engineering hygiene that was designed for shipping software, not for proving research.
| Leak | When it happens | What the claim loses |
|---|---|---|
| Failed approaches squashed or deleted | At merge, when branches are cleaned up | Proof of systematic investigation. The dead ends are the evidence. |
| Uncertainty never written down | At kickoff, when everyone “just knows” the risk | The hypothesis, stated before the answer was known |
| Decisions made in Slack or calls | Mid-project, during debugging | The reasoning that connects one experiment to the next |
| Research hidden inside feature tickets | During planning, when spikes get folded into stories | The ability to separate qualifying hours from routine work |
| Time not tracked against the problem | Every week | Defensible labour allocation, which drives most of the dollar value |
| Engineers leave or rotate | Any time | The only person who could explain the work |
Most of these leaks happen at the moment the evidence is cheapest to keep. A closed pull request (PR) with a one-line reason costs nothing at merge time. Reconstructing why it was closed costs an engineer’s afternoon nine months later, and the answer is less credible.
What does contemporaneous evidence look like in a software stack?
It’s mostly artifacts your team already produces, kept dated and linked to the project. CRA’s framework asks whether there was technological uncertainty, whether a qualified team ran a systematic investigation, and whether the work sought a technological advancement. Each of those maps to something in your tools.
| What the reviewer needs to see | Where it already lives | What to add so it holds up |
|---|---|---|
| What was uncertain, before you knew the answer | Spike ticket, RFC (request for comments), design doc | A written hypothesis and the reason known approaches weren’t enough, dated at kickoff |
| Experiments and iterations | Branches, PRs, commits | Keep failed PRs closed with a reason. Don’t delete the branch. |
| Measured results | CI (continuous integration) runs, benchmark scripts, dashboards | Commit benchmark outputs or attach them to the ticket |
| Decisions and reasoning | Slack, meetings | An architecture decision record (ADR), or a short summary pasted back into the ticket |
| Who did the work, and for how long | Git authorship, ticket assignees, timesheets | A weekly allocation of hours to the project, by person |
| What was learned | Retro notes, the final PR | A closing note on the ticket: what worked and what you know now |
The technical narrative you eventually file gets written from this table. Our T661 form guide covers the narrative side.
Which capture habits work without slowing the team down?
The ones that attach to things the team already does. Asking engineers to write more is a losing strategy. Asking them to add one line to a ticket they’re already closing isn’t.
Tag research at kickoff. Add a short template to spike and RFC tickets: what we don’t know, why the obvious approaches won’t work, how we’ll test it. Three sentences written on day one are worth more than three pages written next spring.
Close failed PRs with a reason. A closed PR titled “Approach B: write-through cache, abandoned, inconsistent reads under concurrent writes” is a dated record of systematic investigation. It took ten seconds.
Pull decisions back into the record. When a Slack thread or a call settles a technical question, someone pastes a two-line summary into the ticket or writes a short ADR.
Keep the numbers. If a benchmark decided something, commit the output or attach it. “p95 dropped from 410 ms to 160 ms on the test fixture” with a date beats “performance improved significantly.”
Allocate time weekly, not annually. Labour is usually the biggest part of a software company’s claim, and it’s the part most often estimated after the fact. A weekly allocation by person and project, even in rough percentages, is far easier to defend. Some teams derive it from ticket assignments.
Review monthly with finance in the room. A 20-minute check each month between the engineering lead and whoever owns the claim catches gaps while the people who did the work still remember it. Your advisor can join and see real material months early.
Our post on the SR&ED audit explains why documentation gaps, not ineligible work, drive most adjustments. These habits close those gaps before a reviewer finds them.
How do you run an evidence-gap check on one project?
Pick one active project with genuine technical uncertainty and answer ten questions using only what exists in your tools today. Don’t audit the whole R&D program. If you’d have to explain something from memory, the answer is no.
| # | Question | Green | Yellow | Red |
|---|---|---|---|---|
| 1 | Is the technological uncertainty written down, with a date before the work started? | Dated ticket or doc | Written later | Not written |
| 2 | Does the record explain why known approaches weren’t enough? | Specific, with references | Generic | Missing |
| 3 | Can you point to at least two approaches tried, including one that failed? | Linked PRs or branches | Only the winner survives | Nothing traceable |
| 4 | Are results measured and stored, not described? | Committed outputs or attached data | Numbers in Slack | Adjectives only |
| 5 | Are the key technical decisions recorded where the project lives? | ADRs or ticket summaries | Scattered in chat | In people’s heads |
| 6 | Can you list who worked on it and roughly how many hours each, by month? | Weekly allocation | Ticket assignees only | Year-end estimate |
| 7 | Is qualifying work separable from routine feature work in the tracker? | Separate tickets or labels | Mixed, but separable with effort | Fully blended |
| 8 | If the lead engineer left tomorrow, could someone else explain the project from the record? | Yes | Partly | No |
| 9 | Are contractor contributions identified and their agreements on file? | Yes | Partly | Unknown |
| 10 | Could your advisor review this project without interviewing anyone? | Yes | With one short call | No |
Teams running this for the first time usually go green on code artifacts, because git keeps everything. They go red on the reasoning and on time.
On a single project, the fixes are obvious and small. You’re adding a hypothesis to one ticket, restoring three closed PRs and starting a weekly allocation for four people.
What does the check look like on a real project?
Usually a mix: strong code history, weak reasoning and no time records. The company and figures below are illustrative, not a client case.
A 35-person SaaS company with a December 31 fiscal year-end runs the check in mid-October on its most technical project: real-time conflict resolution for offline edits in its mobile app. Eight engineers have touched it since February.
The results:
- Green on 3, 4 and 7. The team tried operational transforms, then CRDTs (conflict-free replicated data types), then a hybrid. All three exist as branches. Benchmarks are committed. The work lives under its own epic.
- Yellow on 5 and 8. The decision to abandon operational transforms happened in a two-hour call in May. The reasoning survives only in one engineer’s personal notes.
- Red on 1, 2 and 6. Nobody wrote the uncertainty down at kickoff. The epic description says “build offline sync.” Hours were never allocated, and finance planned to estimate them from salaries in March.
Here’s what they do with the 11 weeks left in the year:
- The tech lead writes a dated note in the epic: what was unknown in February, why the published approaches didn’t handle their data model, and what they planned to test. It’s marked as written in October. That’s honest, and far better than April.
- The engineer with the May notes turns them into an ADR and links it to the closed branches.
- Starting the next Monday, the team allocates time weekly. For February to October, finance and the tech lead reconstruct allocation from ticket history and git activity now, while all eight engineers are still around to confirm it.
- The advisor gets read access to the epic in November instead of a questionnaire in March.
The engineering stays exactly as it was. What changes is how much of it can be shown.
Why does October matter if your year ends December 31?
Because the filing window is long and the evidence window isn’t. For a corporation with a December 31 year-end, the T2 return is due six months later, on June 30, and the SR&ED reporting deadline is 12 months after that. By mid-October, roughly ten months of this year’s work is already history.
Most of it is still recoverable. The engineers are on the team, the Slack threads are searchable and the closed PRs exist. By the time claim preparation starts in the spring, some of that won’t be true.
Other fiscal year-ends move the dates, not the logic. Firms with a March 31 year-end are just past the midpoint and can fix the current year almost entirely in flight. Firms with a September 30 year-end have just closed theirs and should capture last year’s evidence while memory is fresh.
Where does your SR&ED advisor fit?
Right where they are. What shifts is where their hours go. An advisor working from dated tickets, linked PRs and weekly allocations spends time on judgment: which projects qualify, how to frame the uncertainty, how the claim holds up under review. An advisor working from interviews spends time reconstructing.
That’s the model Chrono R&D is built around. It connects to your git repositories and issue tracker, captures qualifying work as it happens, and structures it against CRA’s criteria so each claim traces back to dated source artifacts. You can work with our certified consultant partners or keep the advisor you already have. Either way, they review evidence instead of chasing it. For how reviewers tell captured evidence from generated text, see the capture-versus-generation test.
Frequently Asked Questions
Does CRA require contemporaneous documentation for an SR&ED claim?
Not as a strict legal precondition. Courts have accepted credible evidence produced later. But CRA says dated, specific records are best, and reconstructed evidence carries less weight and costs much more to produce.
What counts as contemporaneous evidence for a software project?
Dated spike tickets or RFCs stating the hypothesis, failed PRs closed with a reason, committed benchmark results, ADRs or decision summaries in the ticket, and weekly time allocations by person. Most of it already exists in git and your issue tracker.
Is it too late to fix documentation for the current fiscal year?
Usually not. If the engineers are still on the team and the threads and branches still exist, you can write dated notes now, turn scattered decisions into ADRs and reconstruct time allocation from ticket and git history. Label anything written later as written later.
Can you show a reviewer what happened on one project?
Pick one active R&D project. Could you show a reviewer, from your tools alone, what was uncertain, what the team tried and who did the work?
If you’d like a second set of eyes, we’ll run the evidence-gap check on that project with your engineering lead and your finance lead together. You’ll leave with a list of the specific gaps and what to fix before your year closes, whether or not you use Chrono R&D. Book an evidence-gap check, or start with Chrono R&D and connect one repository yourself.
Chrono R&D provides documentation software and works alongside SR&ED advisors. Nothing in this post is tax advice. Eligibility and claim amounts are determined by CRA, and your advisor or accountant validates treatment for your company.
Sources: CRA, Get ready to claim | CRA, Pre-claim approval: complete your application | CRA, Pre-claim approval process (tax tip, 2026) | Department of Finance, Legislation passes to implement Budget 2025 | KPMG, Canada’s SR&ED program enters a new era