SR&ED for Software Companies: A CTO's Complete Guide

Software development accounts for 40.8% of all SR&ED credits approved by CRA. It’s the largest single category in the program. If your engineering team is doing technically uncertain work, you’re almost certainly eligible for credits worth more than you think.

Most software companies leave a substantial portion of their credit unclaimed. Not because their work doesn’t qualify, but because the documentation is painful, the eligibility rules feel opaque, and matching engineering work to CRA’s framework requires effort that no one wants to stop and do mid-sprint.

This guide is for CTOs and engineering leaders who want to understand the program from first principles: what qualifies, what the credits are worth, what CRA requires you to document, how the T661 works, and the mistakes that most commonly reduce claims.

What Is SR&ED?

SR&ED stands for Scientific Research and Experimental Development. It’s Canada’s largest federal tax incentive for R&D, administered by the Canada Revenue Agency. The program provides investment tax credits (ITCs) for qualifying expenditures incurred while advancing scientific or technological knowledge.

The program has been running since 1986. In 2024-25, CRA processed 22,758 claims and approved $4.5 billion in credits. It’s not a grant or a subsidy. It’s a tax credit applied against federal corporate income tax, with a refundable component for certain companies that means cash back even in loss years.

For software companies, SR&ED covers work where your engineering team was genuinely trying to solve a problem that couldn’t be solved by applying existing techniques. The outcome was uncertain, the approach required investigation, and your team learned something new about what was technically possible.

Three types of activity qualify:

• Basic research — experimental or theoretical work to advance knowledge without a specific commercial application
• Applied research — work to advance knowledge for a specific practical purpose
• Experimental development — work to achieve technological advancement for a new or improved material, device, product, or process

The vast majority of software company claims fall into experimental development.

Does Your Software R&D Qualify?

CRA applies a three-part test to every project in an SR&ED claim. All three parts must be satisfied.

What counts as technological uncertainty?

CRA’s definition: “Whether a given result or objective can be achieved, or how to achieve it, is not known or determined on the basis of generally available scientific or technological knowledge or experience.”

This is the most critical criterion and the most misunderstood. Technological uncertainty is not the same as technical difficulty. Building something complex using established techniques is hard, not uncertain. Uncertainty exists when a competent engineer, applying all known methods, can’t determine in advance how to achieve the objective or whether it can be achieved at all.

In practice for software teams:

• Qualifies: Your team investigated whether a machine learning model could produce reliable classification at a required confidence threshold with the training data available. The answer was unknown at the start.
• Doesn’t qualify: Your team implemented a recommendation engine using an established collaborative filtering algorithm. The algorithm was known; you were applying it.
• Qualifies: Your team attempted sub-50ms latency on a real-time data pipeline under concurrent write loads exceeding published benchmarks for your message queue technology. No known solution existed.
• Doesn’t qualify: Your team added Redis caching to improve database query response time. The technique was established; the outcome was predictable.

A 2024 Tax Court ruling in DAZZM Inc. v. His Majesty the King (2024 CCI 129) expanded the definition in a meaningful way. Justice Gagnon confirmed that “system uncertainty” — uncertainty arising from the interactions between known components — can satisfy this criterion. If your team integrated two or more existing systems and encountered interaction effects requiring original investigation to resolve, you may have qualifying work even though no individual component was novel.

What does systematic investigation mean?

The work must use a systematic approach: formulating hypotheses, testing them, observing results, drawing conclusions, iterating. CRA uses the “Northwest Hydraulic” framework from a 1998 Tax Court case to evaluate whether a project meets this standard.

The five-part test CRA applies:

1. Was there scientific or technological uncertainty?
2. Were hypotheses formulated to reduce that uncertainty?
3. Was the approach consistent with systematic investigation via experiment or analysis?
4. Was the goal scientific or technological advancement?
5. Were records of hypotheses tested and results maintained as work progressed?

For software teams, this looks like: a technical design document (hypothesis), implementation and testing (experiment), measured outcomes against expected performance (results), documentation of what was learned (conclusion). Agile development processes map onto this structure reasonably well.

What qualifies as technological advancement?

The work must generate new knowledge or capability that advances the state of the technology. The advancement doesn’t have to be industry-wide. It can be local to your organization: something your team now understands about the problem space that wasn’t known at the start.

• Qualifies: Your team determined that a specific neural network architecture can’t achieve reliable inference latency under the constraints of your deployment environment, then developed a modified architecture that can.
• Doesn’t qualify: Your team shipped a feature faster than expected because the engineering was straightforward.
• Qualifies: Your team established the performance boundary conditions under which a distributed consensus algorithm degrades, then developed a fallback mechanism to handle those conditions.
• Doesn’t qualify: Your team refactored legacy code to improve maintainability. Better structure isn’t technological advancement.

What does CRA explicitly exclude from software SR&ED?

Certain categories are excluded regardless of technical complexity:

• Routine bug fixes using established debugging methods
• Data entry, conversion, or migration between systems
• Quality control and routine testing
• Maintenance of existing software
• Applying standard frameworks, libraries, or APIs without addressing their known technical limitations
• Adding UI features or functionality using existing technical methods

How Much Is Your SR&ED Credit Worth?

The credit structure depends on your company type, the nature of the expenditures, and your province.

What are the federal SR&ED credit rates?

Canadian-Controlled Private Corporations (CCPCs):

• 35% refundable ITC on the first $3 million of eligible expenditures per year
• 15% non-refundable ITC on eligible expenditures above $3 million

All other companies (non-CCPC, public corporations, foreign-owned):

• 15% non-refundable ITC on all eligible expenditures
• No refundable component

“Refundable” is the key distinction. A CCPC with a 35% refundable credit on $3M in eligible expenditures receives $1.05M even if the company has no tax payable that year.

For most early-stage software companies, CCPC status and the refundable credit mechanism are why SR&ED is worth pursuing even in loss years.

The CCPC threshold reduction: the $3M enhanced rate begins to phase out when your prior-year taxable income exceeds $500K and is fully eliminated at $800K. It also phases out when prior-year taxable capital exceeds $10M and is eliminated at $50M.

What expenditures are eligible for SR&ED?

SR&ED credits apply to:

• Salaries and wages of employees directly engaged in SR&ED
• Materials consumed or transformed in performing SR&ED
• Subcontractor costs for SR&ED performed on your behalf (at 80% of the amount paid)
• Capital expenditures for equipment used in SR&ED (restricted in recent years)
• Overhead via the proxy method (55% of direct labour, no itemized tracking required)

Salaries are the largest category for most software companies. A developer spending 60% of their time on qualifying projects contributes 60% of their salary to the eligible expenditure base.

Sample calculation: $500K in eligible salaries

A CCPC with $500,000 in eligible salaries, using the proxy method:

Component	Calculation	Amount
Eligible salaries	Given	$500,000
Overhead proxy (55%)	$500,000 × 55%	$275,000
Total eligible expenditures		$775,000
Federal ITC at 35% (CCPC)	$775,000 × 35%	$271,250
Provincial credit (Ontario, 8%)	$775,000 × 8%	$62,000
Estimated total credit		$333,250

How do provincial SR&ED rates compare?

Provincial rates vary significantly. Ontario’s combined rate for a typical CCPC is roughly 43% (35% federal plus 8% provincial). British Columbia’s SR&ED tax credit is 10% refundable for CCPCs, giving a combined rate of 45%. Quebec’s R&D credit is 14-30% depending on company size, pushing combined rates to 49-65%. Alberta has no provincial SR&ED credit, so CCPCs receive only the 35% federal rate.

For a company spending $1M on eligible R&D in Ontario, that’s approximately $430,000 in credits per year.

Province	Federal (CCPC)	Provincial (approx.)	Combined (approx.)
Ontario	35%	8-11.5%	43-46.5%
British Columbia	35%	10%	45%
Quebec	35%	14-30%	49-65%
Alberta	35%	0%	35%

What Documentation Does CRA Require?

Documentation is where most SR&ED claims succeed or fail. CRA requires contemporaneous records: documentation created during the R&D work, not assembled afterward to support a claim.

What does CRA mean by contemporaneous documentation?

CRA’s documentation policy, IC86-4R3, specifies that supporting evidence must demonstrate:

• The nature of the technological uncertainty
• The systematic approach taken to investigate it
• The work performed, hypotheses tested, and results observed
• The advancement or new knowledge achieved
• The time employees spent on qualifying activities

“Contemporaneous” means the records existed at the time the work was performed. Git commits, pull requests, sprint tickets, technical design documents, architecture decision records, test results, and meeting notes all qualify. A write-up assembled at claim time carries less weight.

What documentation survives an audit?

What holds up:

• Git commit history with substantive messages referencing the technical problem being solved
• Pull request descriptions that describe the investigation approach and outcome
• Issue tracker tickets (Jira, Linear, GitHub Issues) with technical context about the uncertainty and approach
• Architecture decision records (ADRs) documenting why a technical approach was chosen and what alternatives were rejected
• Test results and benchmarks showing what was measured, under what conditions, and what was found
• Sprint retrospectives or design reviews where technical challenges were discussed
• Technical design documents written before implementation began

What doesn’t hold up:

• SR&ED write-ups drafted by engineers specifically for the claim
• Verbal descriptions assembled through retrospective interviews
• Financial records without supporting technical narratives
• Time allocations without evidence in project management tools

What goes into the three T661 narrative fields?

Every qualifying project requires three technical narratives in Part 2 of the T661 form:

• Line 242 (350 words max): The technological uncertainty. What was unknown or unknowable at the start, and why it couldn’t be resolved by applying existing knowledge.
• Line 244 (700 words max): The work performed. Hypotheses, experiments, tests, results, and conclusions in chronological order.
• Line 246 (350 words max): The advancement achieved. What new technical knowledge was produced by the investigation.

How Do You File: T661 and Process

The T661 must be filed alongside your T2 corporate tax return and the T2SCH31 Investment Tax Credit schedule. Filing the T661 without the T2SCH31 — or vice versa — forfeits part of the benefit.

The SR&ED filing deadline is 18 months after fiscal year-end for most corporations. CRA can’t extend this deadline by law. A claim filed one day late is disallowed entirely. There’s no appeal mechanism for a missed SR&ED deadline.

For a December 31 fiscal year-end: the T2 return is due June 30, and the SR&ED deadline is June 30 of the following year.

CRA recommends submitting at least 90 days before the deadline. This leaves time to address deficiencies identified through a pre-approval review.

What Mistakes Most Often Reduce an SR&ED Claim?

The gap between a strong claim and a reduced one is almost always in the narratives and documentation quality. CRA approves roughly 80% of claims without detailed review. Of the 20% that receive close scrutiny, most are reduced or denied.

Retroactive documentation

The single most common reason claims are reduced in audit. If your engineering team writes SR&ED narratives from memory at filing time, the documentation is inherently weaker than records that existed during the work. CRA reviewers compare the dates on project artifacts against the dates of claimed work. Inconsistencies are a red flag.

The fix: document as work happens. This doesn’t mean adding SR&ED paperwork to your engineers’ workflow. It means ensuring your existing development artifacts contain enough technical context to support a claim. Most of what CRA needs already exists in your dev tools.

Missing technological uncertainty language

Part 2, Line 242 must describe technological uncertainty. Reviewers look for specific language: what was unknown at the start, why it was unknown, and why it couldn’t be resolved by applying existing knowledge. Many companies describe what they built rather than the uncertainty they faced.

“We developed a natural language processing pipeline for customer intent classification” is a product description. “We investigated whether transformer-based models pre-trained on general text corpora could achieve production-grade intent classification accuracy on a specialized financial services vocabulary without domain-specific fine-tuning, where fine-tuning data was limited by confidentiality constraints” describes an uncertainty.

Under-counting eligible expenditures

Companies frequently under-report eligible salary allocations. They claim only the engineers who were “working on SR&ED” as a project, when qualifying work was actually distributed across the team throughout the year. A developer spending 30% of their time on qualifying work contributes 30% of their salary to the base — but only if that allocation is tracked and documented.

Claiming 100% of salary without support

Allocating 100% of an engineer’s salary to SR&ED without supporting time records draws CRA scrutiny. Time allocations above 80% for any individual require time-tracking data, calendar records, or project assignment documentation to support.

Missing the technological advancement requirement

Line 246 must describe what new technical knowledge was produced. Many companies describe the commercial outcome. CRA doesn’t care about commercial outcomes. The required content is technical: what your team now understands about the problem space, what constraints were mapped, what approaches were confirmed to be infeasible, what novel method was developed.

Should You Use a Consultant or SR&ED Software?

Three ways to prepare an SR&ED claim: use a traditional consultant, use SR&ED software, or prepare it in-house. The right answer depends on your claim complexity, team capacity, and how often you file.

SR&ED consultants typically charge 15-30% of the total claim value. On a $300,000 claim, that’s $45,000-$90,000.

A consultant makes sense when:

• This is your first SR&ED claim
• Your claim includes contentious or complex projects likely to draw CRA scrutiny
• You have a one-time large claim following a multi-year period without filing
• Your engineering and finance teams have no bandwidth to manage the process

SR&ED software is the better approach when:

• You file SR&ED claims every year
• Your qualifying work is primarily software development
• Your team already generates good technical documentation in your dev workflow
• You want to reduce consultant dependency while maintaining claim quality
• You’re concerned about audit readiness

The core advantage of software is continuous capture. Rather than reconstructing the year’s qualifying work at filing time, the documentation is built incrementally from actual development artifacts.

How Does Chrono R&D Fit In?

If you’re filing SR&ED every year, the documentation gap is the problem worth solving.

The qualifying work your engineers did this year is already in your dev tools. It’s in the commit history, the PR descriptions, the sprint tickets, and the architecture decisions. The question is whether it’s captured in a format CRA can evaluate, or whether your team will spend weeks reconstructing it at filing time.

Chrono R&D connects to your git repos, issue trackers, and project management tools. It identifies qualifying work as it happens, structures the technical narratives in CRA’s required format, and outputs a claim-ready package. Your engineers don’t write SR&ED reports. Your filing doesn’t depend on memory. Your documentation is audit-ready from day one.

SR&ED Quick Reference for Software Companies

Item	Detail
Program name	Scientific Research and Experimental Development (SR&ED)
Administered by	Canada Revenue Agency (CRA)
Credit type	Investment Tax Credit (ITC)
CCPC federal rate	35% refundable on first $3M of eligible expenditures
Non-CCPC federal rate	15% non-refundable
Filing form	T661 (filed with T2 and T2SCH31)
Filing deadline	18 months after fiscal year-end
Software’s share of SR&ED claims	40.8% of all allowed credits

FAQ

Does our software company qualify for SR&ED if we’re not doing AI or ML work?

Yes. The qualification test is about technological uncertainty, not the type of technology. Any software project where the outcome was genuinely unknown at the start, required systematic investigation, and produced new technical knowledge can qualify. That includes work on distributed systems, database performance, real-time data pipelines, security architecture, and many other domains.

How far back can we file SR&ED claims?

The deadline is 18 months after fiscal year-end. You can’t file retroactively for years outside that window. If you’ve never claimed SR&ED, you can file for your current fiscal year and potentially the prior year depending on your fiscal year-end date.

What’s the biggest documentation mistake software companies make?

Writing the SR&ED narratives from memory at filing time rather than capturing technical context as work happens. The records that hold up in an audit are the ones that existed during the project: git commits, PR descriptions, issue tickets, and design documents. A narrative assembled six months after the fact carries significantly less weight with CRA reviewers.

---

Ready to see what your engineering team’s work is worth in SR&ED credits? Talk to us — we’ll do a quick assessment of your qualifying projects at no cost.