SR&ED for Software Companies
Software developers in Canada often leave SR&ED money on the table because they think their work is too routine. If your team is solving genuine technical problems — not just building features on top of documented frameworks — you likely have qualifying work.
Why software companies qualify
CRA recognizes that software development frequently involves genuine technological uncertainty. When your engineers are building something where no documented approach exists, where performance or accuracy targets can't be met using standard libraries, or where architectural constraints require original solutions — that's SR&ED work.
Software work that typically qualifies
- Developing novel algorithms where existing approaches failed to meet performance, accuracy, or latency requirements
- Building distributed systems where correctness, consistency, or throughput targets required original architectural solutions
- Creating machine learning models or inference pipelines where standard frameworks were insufficient
- Developing compilers, interpreters, or domain-specific languages where performance characteristics couldn't be predicted in advance
- Solving integration or interoperability problems between systems where no documented solution existed
- Achieving scalability or reliability targets at levels that required original investigation beyond documented best practices
- Security or cryptographic implementations where novel threat models or hardware constraints required original protocol design
Software work that does not qualify
- Routine application development using standard frameworks and documented APIs
- UI/UX design and front-end development work
- Configuration, deployment, and DevOps work using established tools
- Data migration, ETL pipelines, and database administration
- Bug fixing that doesn't involve resolving technological uncertainty
- Writing tests or test automation for already-developed software
- Feature additions that apply existing, well-understood technology
Software SR&ED evidence examples
These are the records CRA reviewers look for when evaluating a software SR&ED claim. The good news: most teams already generate them — they just need to be organized.
- Git commit history showing iterative technical work over weeks or months
- Issue tracker records (Jira, Linear, GitHub Issues) describing the problem, hypothesis, and resolution
- Code review threads demonstrating systematic evaluation of alternatives
- Benchmark and profiling reports showing performance targets and achieved improvements
- Architecture decision records (ADRs) explaining why standard approaches were rejected
- Sprint retrospectives capturing what was learned, what failed, and what changed
- Slack or email discussions about technical challenges, experiments, and decisions
Common documentation mistakes in software SR&ED claims
- Reconstructing narratives from memory instead of using contemporaneous records
- Describing what was built rather than the technical uncertainty that was resolved
- Including time spent on routine development, bug fixes, or UI work without proper allocation
- Failing to show the systematic investigation: what was tried, what failed, and why
- Missing financial records linking specific employees to specific SR&ED projects
How sredy.io helps software teams
sredy.io's guided interview maps your technical work directly to CRA's three criteria. The platform generates T661-ready narratives, schedules, and an evidence index — designed for your accountant to review and file.
Documenting software SR&ED work
Software companies often have excellent contemporaneous documentation without realizing it:
- Git commit history — timestamped evidence of iterative investigation
- Issue trackers (Jira, Linear, GitHub Issues) — show the problem, hypothesis, and iteration
- Code review records — demonstrate the systematic evaluation of approaches
- Benchmark and profiling results — quantify the uncertainty and the advancement
- Architecture decision records (ADRs) — document why standard approaches were insufficient
- Sprint retrospectives — capture what was learned and what changed
Common questions
Does using standard frameworks like React or PostgreSQL disqualify our claim?
Not necessarily. The key is whether your work within or around those frameworks involved genuine technical uncertainty. Building a routine feature with documented APIs doesn't qualify — but solving a novel problem that the framework couldn't address does.
Can we claim SR&ED for work on an open-source project?
Yes, if the work meets the eligibility criteria. The IP doesn't need to be proprietary — open-source contributions involving genuine technical uncertainty are eligible.
How do we separate SR&ED time from regular development time?
CRA expects employees to allocate their time between SR&ED and non-SR&ED work. Time-tracking exports from tools like Jira, Harvest, or Toggl are commonly used.
Related SR&ED guides
Ready to start?
Prepare your SR&ED claim with AI assistance
sredy.io generates structured, CRA-ready claim packages for a fixed fee. No consultant percentage.