Key takeaway: SR&ED for CTOs is an engineering-process problem wearing a tax-form costume. Finance can file the T661, but only engineering knows which sprints had real technical uncertainty, which failed experiments are worth documenting, and when a risky project should get a CRA eligibility read before the team spends a dollar building it. A Canadian-controlled private corporation can recover up to 35% of qualifying spend, refundable, on up to $6 million a year — up to $2.1 million in credits — and software development already takes the single largest share of every dollar the CRA allows. The gap between claiming that and leaving it on the table is almost always a documentation habit, not an eligibility problem.
Most SR&ED guidance is written for whoever signs the return. This one is written for whoever decides what the team builds next, because that's the person who actually controls whether a SR&ED claim is strong, weak, or nonexistent.
Here's a scenario that plays out at a lot of Canadian software companies. Finance pulls together payroll and contractor costs at year end, hands a spreadsheet to whoever's filing the claim, and hopes the numbers are defensible. Nobody in that chain was in the room when the team spent six weeks fighting a data pipeline redesign that might not have worked. That's the gap SR&ED for CTOs is meant to close: the same federal Scientific Research and Experimental Development tax incentive every Canadian company claims, but with the engineering judgment finance can't supply on its own.
What SR&ED for CTOs actually means
Finance owns the forms and the dollar totals. Engineering owns the facts those forms describe — which projects had real technical uncertainty, whether the team's documentation will hold up if the CRA asks questions, and when a project is risky enough to flag for eligibility review before it ships. A CTO doesn't need to understand tax law to make any of those calls.
That division of labour is also where companies leave money on the table. A finance team working from expense reports can total up salaries and contractor costs just fine. What it can't do is tell you whether six weeks spent redesigning a data pipeline under real performance constraints was routine engineering or SR&ED-eligible experimentation. Someone has to have been in the sprint planning meetings for that call to mean anything — you, or whoever reports to you.
Which of your team's work actually qualifies
Two conditions, both required, per the CRA's eligibility policy: a "why" (advancing scientific knowledge or achieving technological advancement in the face of genuine uncertainty) and a "how" (a systematic investigation carried out by experiment or analysis). Neither one mentions industry, headcount, or lab equipment. That's the single biggest misconception CTOs carry into their first claim: the assumption that this program was built for someone else's kind of company.
Translate the test into engineering terms and it gets simpler. Could your team have gotten the answer from documentation, or from a senior engineer who'd seen the problem before? If not, if you genuinely didn't know whether the approach would work, or how well, until you tried it, that's your "why." The "how" is just a hypothesis-test-measure-iterate pattern, even an informal one, as opposed to trying a few things and moving on once something shipped.
Failure counts, and this is where most CTOs underestimate their own claim. A quarter spent on an architecture that didn't pan out, then got scrapped, is often the cleanest SR&ED evidence a company has. The uncertainty was unambiguous, and the record of what was tried is usually sitting in pull requests and postmortems already. (We go deeper on the eight CRA support-work categories in our eligible activities breakdown, and on eligible-vs-not engineering scenarios in our guide for software companies.) Software teams clear this bar constantly: 42.6% of all SR&ED investment tax credits allowed went to software development in fiscal year 2025–26 — the largest share of any sector, by a wide margin.
The other half of the test is knowing what's out. Per the same eligibility policy, market research, routine quality control or testing, social sciences research, style changes, and commercial production runs don't qualify — even when they eat real engineering time. Knowing that list from memory cuts both ways: it stops you from building a narrative that won't survive review, and it stops you from writing off a whole quarter as ineligible just because part of it was routine.
Where the evidence for SR&ED already lives in your stack
It's already in your engineering tools; it just isn't organized for tax purposes yet. Commit history shows what was tried and when. PR descriptions and code review comments carry the technical reasoning. A Jira or Linear ticket usually has the hypothesis going in and the outcome coming out, and a sprint retro or architecture decision record is often the closest thing you have to a lab notebook.
None of that was written for the CRA — which is exactly why it holds up. A T661 narrative reconstructed eighteen months later, from memory, after the engineer who did the hardest part has since left, reads differently to a reviewer than one built from records made while the work was happening. It shows up in how a claim performs under a CRA review.
So skip the spreadsheet. The move that actually compounds is flagging SR&ED-relevant work at the point it happens: a label on the epic, a line in the retro, PR descriptions that state the uncertainty and not just the change. Do that for a fiscal year and you'll have a better claim than any year-end reconstruction could produce.
How to size the claim before it's due
Sizing your claim starts with the rate: Canadian-controlled private corporations earn a 35% refundable enhanced credit on qualifying current expenditures, up to $6 million a year as of the Budget 2025 changes enacted when Bill C-15 received royal assent on March 26, 2026. That's up to $2.1 million in credits at the full limit, refundable even at zero tax owing. Eligible Canadian public corporations now qualify for the same enhanced rate too. Above that, or for other corporations, the basic rate is 15%, with qualifying corporations able to recover 40% of it as a refund. The taxable-capital phase-out now runs $15 million to $75 million, so a growing company keeps the enhanced rate longer than the pre-2026 rules allowed.
Overhead doesn't need to be itemized: the prescribed proxy amount lets you claim 55% of your SR&ED salary base instead, which is usually simpler for an engineering-heavy cost structure with a lean finance function.
If your company has a permanent establishment outside the province where you claim a provincial R&D credit, the number on your term sheet slide isn't the real combined rate. Provincial credits reduce the federal expenditure base under ITA s.127(18), a mechanic we call the grind, so "35% federal + 8% Ontario" is not 43%; illustratively it works out closer to 40.2%. We've written up the exact math and the province-by-province comparison separately, and the full mechanism in our grind rule explainer; both are worth ten minutes before you present a claim estimate to your board.
Timing SR&ED into your engineering calendar
SR&ED has one hard date, and it isn't a suggestion: your reporting deadline is 18 months after your fiscal year end, 12 months after your T2 corporate return's due date, which is itself 6 months after year end. The CRA "cannot by law allow any additional time" past that date, citing Income Tax Act subsection 220(2.2), per the Filing Requirements Policy. Miss it and that year's credits are gone permanently, not delayed. We cover the full deadline math and a fiscal-year-end table in our filing deadline guide.
For a CTO, the more useful date isn't the deadline. It's the moment before a risky, expensive project starts. As of April 1, 2026, the CRA runs an optional pre-claim approval process: apply through My Business Account for up to 3 projects, and the CRA issues an eligibility determination within 8 weeks of a complete application, open to corporations with gross business income under $25 million in good standing. The CRA's own framing is that it evaluates planned work before you've incurred significant costs, which is exactly the window a CTO controls. If your team is about to sink two quarters into an architecture you genuinely aren't sure will work, that's the project to run through pre-claim approval: a CRA read on eligibility before the engineering hours are spent, not eighteen months after. We've written more on the mechanics in our pre-claim approval guide.
Filing early also just moves faster: refundable claims accepted as filed are processed within 60 calendar days under the CRA's service standards, a target the CRA hit 95% of the time in fiscal year 2025–26, versus 180 days (met 92.5% of the time) for claims selected for review. File with your T2 at month 6, and the cash lands months sooner than filing at month 17 ever could.
What happens if the CRA reviews the claim
A CRA review is a request for more detail, not an accusation. The program's own statistics back that up: in fiscal year 2025–26, the CRA accepted 90% of claims as filed with no modification, adjusted 6% after review, and denied 4%. Most claims that go to review still get paid; the review changes the amount, not the outcome, for the large majority.
What decides which bucket a reviewed claim lands in is documentation quality, and that's an engineering artifact, not a tax one. A reviewer reading your T661 narrative alongside your actual commit history, ticket history, and architecture decisions can quickly tell whether the story matches the record. A narrative written from memory, disconnected from any contemporaneous evidence, is where reviews turn into disputes. We cover what triggers a review and how to make it a non-event in our CRA review guide.
Where CTOs get this wrong
Treating SR&ED as finance's problem until the deadline forces engineering into the room is the big one. By then the engineer who owned the hardest technical stretch may have left the company, and someone's rebuilding a narrative from whatever's still in the repo. Decide which projects are candidates at the start of the fiscal year and flag them as the work happens — don't wait to reconstruct candidacy after the fact.
Caution cuts money too, just less visibly. Plenty of teams assume a project doesn't qualify because "it was just engineering," when it actually cleared the two-part test the whole time — and the opposite mistake happens just as often, where routine maintenance or standard integration work gets swept into a claim it was never eligible for. Both come from the same root cause: nobody with technical judgment made the call early enough for it to matter. A third failure mode is easy to miss, too: scoping the claim around one high-profile project instead of the whole team's output. The infrastructure team's pipeline redesign, the platform team's isolation work, some smaller experiment that never got its own name because it lived inside a bigger release: none of it shows up if eligibility only gets attention once a year, for whichever project happens to be visible.
One honest caveat, since this isn't a pitch for claiming everything: SR&ED isn't worth the overhead for every team. Well-documented integrations, standard CRUD features, ordinary configuration work — forcing that into a SR&ED narrative wastes your time and invites the exact review friction described above. The program rewards real uncertainty, not creative framing of ordinary work.
Software can genuinely help collect the evidence, but it's worth being precise about what it does and doesn't replace. A tool watching your dev tools continuously and flagging SR&ED-relevant activity as it happens beats reconstructing everything at filing time, but a defensible claim still needs a qualified, independent SR&ED expert reviewing the eligibility calls and narrative before it's filed, someone who'll stand behind it if the CRA has questions. Ask any SR&ED tool who signs off on the technical narrative, not just how much of it got automated.
How Glauq fits into a CTO's workflow
Glauq collects SR&ED evidence continuously from the tools your team already uses: commits, pull requests, tickets, and technical discussions, so the narrative is built from records made when the work happened, not reconstructed at month 17. A qualified, independent SR&ED expert reviews every claim before it's filed and stands behind it if the CRA asks questions, and the fee is flat rather than a percentage of your refund, so a larger claim under the new $6 million limit doesn't come with a larger bill. For a CTO, the practical outcome is that flagging SR&ED-relevant work becomes a five-second habit inside the tools you're already using, instead of a quarter-end fire drill owned by nobody in particular.
Frequently asked questions
Does a CTO need to sign the SR&ED claim? No. The corporate return, including Form T661 and Schedule T2SCH31, is filed by the corporation, typically coordinated through finance or an external preparer. What the CTO owns is the input finance can't generate alone: which projects had real technical uncertainty and where the supporting evidence lives. Per the CRA's submission guidance, the corporation is responsible for the claim being complete, accurate, and evidence-backed regardless of who prepared it.
How much engineering time should a CTO expect to spend on SR&ED? There's no CRA figure for this — it depends entirely on how well documentation habits are already built into your engineering process. Continuous, lightweight tagging of SR&ED-relevant work as it happens costs closer to zero than a year-end reconstruction, which can consume days of engineering and leadership time chasing details nobody wrote down.
Should every engineering project be flagged for SR&ED review? No — only projects with genuine technical uncertainty under the CRA's two-part test. Routine maintenance, standard integrations, and UI work using established frameworks are explicitly excluded. Flagging everything dilutes the claim and invites review friction; flagging too little leaves real credits unclaimed.
What's the fastest way to know if a new project will qualify before we build it? Apply for pre-claim approval through My Business Account before the work starts. The CRA issues a determination within 8 weeks of a complete application, for up to 3 projects per application — a genuine eligibility read before you've committed engineering hours to it.
Do failed engineering projects still count toward the claim? Yes, and they're often the strongest evidence a company has. A project that didn't work out because a real technical uncertainty didn't resolve favourably still satisfies the CRA's "why" and "how" test — the outcome doesn't have to be success, the process has to be systematic.
Does claiming a provincial R&D credit change how much the federal claim is worth? Yes — provincial credits reduce the federal expenditure base under ITA s.127(18), so the combined rate is never a simple addition of the two headline percentages. See our grind rule explainer for the real math by province.
The engineering decisions behind a SR&ED claim (what counts, what's worth documenting, when to check eligibility before building) belong to the CTO, whether or not that's written down anywhere. Own them early in the fiscal year and the claim becomes a byproduct of how your team already works, not a project of its own.
See what your engineering spend could be worth — estimate your refund or check your eligibility.