Business owner
Own the decision to explore or file a claim, provide the business and project context, approve access, and keep the company accountable for the accuracy of its records.
A technical evidence guide for Canadian software teams
Document the technical work while it is happening.
Potential SR&ED work is easier to assess when the project leaves a dated, specific trail from the starting knowledge and technical uncertainty through the experiments, results, people, time, and underlying software artifacts. Build that trail into delivery, then let a qualified tax advisor and the CRA make the eligibility decisions.
The technical thread
What should a software team document for SR&ED?
CRA guidance focuses on what work was done, why it was undertaken, how the investigation proceeded, what it produced, and what evidence supports the people, dates, and expenditures. The record needs context, not a folder of disconnected tickets.
Objective and starting knowledge
State the capability the team sought and what was known at the start. Link the standards, vendor material, prior designs, prototypes, or expert review used to understand the available approaches.
Scientific or technological uncertainty
Describe the limitation in the available knowledge that made the result uncertain. Keep this separate from ordinary schedule, budget, market, or product uncertainty.
Ideas and alternatives tested
Record the proposed explanation, design, method, or approach and the alternatives considered. Explain why each test could resolve, narrow, or expose the uncertainty.
Work actually performed
Connect experiments and analyses to dated work items, commits, prototypes, configurations, test protocols, data, and observations. A feature list alone does not explain the investigation.
Results and new learning
Capture failed attempts, partial results, unexpected behaviour, decisions, and conclusions. A useful record explains what the team learned and how that changed the next step.
People, time, and project boundary
Identify who did the work, when it occurred, and how it was separated from routine engineering and commercial delivery. Keep the technical record traceable to the financial record.
Keep the boundary honest
Evidence and eligibility are different questions.
Documentation can show what happened. It cannot turn routine software work into SR&ED.
Evidence question: Can the team show the uncertainty, investigation, results, timing, people, and resources through usable records?
Eligibility question: Does the work and its purpose meet the current legal and CRA requirements for SR&ED, and which expenditures are allowable?
Keep normal product planning, feature implementation, bug fixing, migration, training, support, and commercial work visible too. A qualified advisor needs the full boundary to distinguish possible SR&ED from other delivery.
An evidence pack that follows the work
Make each artifact answer a specific question.
Use ordinary engineering and business systems where possible. Add short context and links so a reviewer can follow the project without treating every commit, ticket, or hour as qualifying work.
| Record | Question it should answer | Likely owner | Cadence |
|---|---|---|---|
| Technical decision record | Starting knowledge, uncertainty, alternatives, and the reason for a test | Engineering lead | When the decision is made |
| Work item and source history | What was attempted, who changed it, when it changed, and the related technical objective | Delivery team | As work happens |
| Test plan, data, and result | The idea tested, method, conditions, result, anomalies, and conclusion | Engineer or tester | For each meaningful trial |
| Architecture, prototype, or design | System boundary, constraints, dependencies, and evolution of the approach | Engineering lead | When the design changes |
| Review and meeting notes | Questions, observed behaviour, decisions, rejected options, and follow-up work | Project owner | At reviews and decision points |
| Time and contractor records | People, dates, hours, roles, agreements, and the basis used to connect effort to work | Project and finance owners | At least monthly |
| Release and component inventory | Versions, dependencies, deployment context, and software supply-chain changes | Engineering owner | At each material release |
A delivery rhythm
Do not wait for the tax year to close.
CRA guidance emphasizes contemporaneous evidence, often meaning records generated as the work was carried out. A small recurring discipline is more reliable than asking a team to reconstruct technical decisions at year-end.
Set the boundary before work starts
Name the business owner, engineering lead, financial owner, and qualified tax advisor. Agree on the tax-year boundary, project naming, evidence location, access, and retention before records scatter.
Capture the thread inside delivery
Use the tools the team already works in. A short technical record should link the uncertainty, proposed approach, work item, source change, test, result, people, and date without asking engineers to write a tax claim.
Reconcile every month
Review possible SR&ED work with technical and financial owners. Separate routine delivery, correct missing links while the facts are current, and reconcile people, time, contractors, and costs without deciding eligibility by percentage.
Prepare the claim with qualified advice
Give the organized evidence to the qualified tax advisor. The claimant and advisor can assess the work and expenditures against current CRA rules and prepare the project description and Form T661.
Assign responsibility
Name the record owners before the first sprint.
Technical and financial records come from different people and systems. The claimant remains responsible for its claim, with engineering, finance, delivery partners, and qualified advisors contributing different evidence and judgment.
Engineering lead
Keep the technical thread coherent: starting knowledge, uncertainty, ideas tested, work performed, results, and the artifacts that support each part.
Delivery team
Record work and observations as they occur. Link tickets, source changes, prototypes, test data, decisions, and failed attempts instead of reconstructing them months later.
Finance or project owner
Maintain usable time, payroll, contractor, and expenditure records and reconcile them to the technical project boundaries chosen with the advisor.
Qualified tax advisor
Interpret current law and CRA guidance, assess potential eligibility and allowable expenditures, advise the claimant, and prepare or review the claim.
RSC delivery team
When engaged, RSC can maintain contemporaneous technical records and collaborate with the client and advisor. RSC does not determine eligibility, credit amounts, or tax outcomes.
Research behind this guide
Primary sources reviewed October 26, 2026. CRA updated its Form T661 application and reporting pages in October 2026 and noted that Guide T4088 is being revised. Confirm the current form, guide, and advice for the claimant’s tax year before preparing a claim.
- CRA: Current requirements for work to be eligible for SR&ED, updated October 2026
- CRA Guide T4088: Documentation and other evidence to support an SR&ED claim
- CRA: Describe work and report expenditures with Form T661, updated October 14, 2026
- CRA: SR&ED Client Portal, pre-claim workbook, and Self-Assessment and Learning Tool
- Canadian Centre for Cyber Security: 2026 minimum elements for a software bill of materials
This guide is general planning information, not tax or legal advice. RSC can support contemporaneous technical documentation and collaborate with qualified tax advisors. RSC does not determine eligibility, allowable expenditures, credit amounts, or CRA outcomes.
Keep the evidence close to delivery
Make technical records part of the work.
RSC keeps senior developers close to architecture, experiments, review, and documentation, giving the client and its qualified advisor a clearer account of what the team actually did.