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.
SR&ED for CTOs isn't a different program. It's the same federal Scientific Research and Experimental Development tax incentive every Canadian company claims, and what's different is which decisions matter. A CTO doesn't need to understand tax law. A CTO needs to know which engineering work counts, where the proof of that work already lives, and when to loop in finance before a deadline turns a good claim into a rushed one.
What SR&ED for CTOs actually means
SR&ED for CTOs means owning three decisions finance can't make without you: which projects had real technical uncertainty, whether your team's documentation habits will hold up if the CRA asks questions, and when to flag a project for eligibility review before it ships. Finance owns the forms and the dollar totals. Engineering owns the facts those forms describe.
That division of labour is also where most companies lose money. A finance team working from expense reports alone can total up salaries and contractor costs, but it can't tell you whether the six weeks your team spent redesigning a data pipeline under real performance constraints was routine engineering or SR&ED-eligible experimentation. That call requires someone who was in the sprint planning meetings: you, or someone reporting to you.
Which of your team's work actually qualifies
Work qualifies for SR&ED when it satisfies two conditions together, 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 condition mentions industry, headcount, or lab equipment, which is the single biggest misconception CTOs carry into their first claim.
In practice, the "why" test asks whether your team could have gotten the answer from documentation, a senior engineer's experience, or standard practice. If the uncertainty was real, meaning you didn't know if the approach would work, or how well, until you tried it, that's the signal. The "how" test asks whether the work followed a hypothesis-test-measure-iterate pattern, even an informal one, rather than "we tried a few things until something shipped."
Failure counts. If your team spent a quarter on an architecture that didn't pan out and then pivoted, that work can still qualify, and it's often the cleanest SR&ED evidence a company has: the uncertainty was unambiguous, and the record of what was tried usually already exists in pull requests and postmortems. We go deeper on the eight CRA support-work categories and what's explicitly excluded in our eligible activities breakdown, and on common eligible and non-eligible engineering scenarios in our guide for software companies.
The data backs up that software teams clear this bar constantly, not occasionally: software development took 42.6% of all SR&ED investment tax credits allowed in fiscal year 2025–26, the largest share of any sector by a wide margin. If you're deciding whether your team's work is "SR&ED enough," the CRA's own numbers say software is the base case the program is built around, not an edge case squeezed in.
It's just as important to know what's explicitly excluded, 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 consume real engineering time. A CTO who can name these exclusions from memory saves the team from building a narrative around work that was never going to survive review, and from the opposite mistake of assuming an entire quarter is disqualified because part of it was routine.
Where the evidence for SR&ED already lives in your stack
The evidence for a strong SR&ED claim already exists in your engineering tools. It just isn't organized for tax purposes yet. Git commit history shows what was tried and when. Pull request descriptions and code review comments capture the technical reasoning. Jira or Linear tickets show the hypothesis going in and the outcome coming out. Sprint retrospectives and architecture decision records show the systematic part of "systematic investigation."
None of that was written for the CRA, which is exactly why it's credible. A T661 narrative reconstructed eighteen months later, from memory, after the engineer who did the work has left, reads differently than a narrative built from records made while the work was happening. Reviewers can tell the difference, and it shows up in how a claim performs under a CRA review.
The practical move for a CTO is not "start a SR&ED spreadsheet." It's tagging or flagging SR&ED-relevant work at the point it happens — a label on the epic, a note in the retro, a habit of writing PR descriptions that state the uncertainty and not just the change. That single habit, sustained across a fiscal year, is worth more to your eventual claim than any amount of year-end reconstruction.
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, valid for up to 3 years, open to corporations with gross business income under $25 million in good standing. Claims built entirely from pre-approved projects qualify for an accelerated 90-day expenditure-only review. 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
The most common mistake is treating SR&ED as finance's problem until the deadline forces engineering into the room. By the time that happens, the engineer who owned the hardest technical stretch may have left the company, and the narrative has to be rebuilt from whatever's left in the repo. The fix is establishing, at the start of a fiscal year, which projects are candidates and flagging them as the work happens — not reconstructing candidacy retroactively.
The second mistake is under-claiming out of caution: assuming a project doesn't qualify because it "was just engineering," when it actually cleared the two-part test the whole time. The third runs the opposite direction: over-claiming by counting routine maintenance, UI restyling, or standard integration work that the CRA's eligibility policy explicitly excludes. Both errors come from the same root cause: nobody with technical judgment made the eligibility call early enough for it to matter.
A fourth, quieter mistake is scoping the claim project by project instead of team-wide. A CTO who only thinks about SR&ED when a single high-profile project comes up misses the accumulated eligible work happening in parallel — the infrastructure team's data pipeline redesign, the platform team's multi-tenant isolation work, a smaller experiment that never got a name because it lived inside a larger release. None of that shows up if eligibility is treated as a once-a-year exercise triggered by whichever project is most visible.
One honest caveat: SR&ED isn't worth the operational overhead for every team. If your engineering work is genuinely routine, think well-documented integrations, standard CRUD features, configuration work, forcing it into a SR&ED narrative wastes your time and invites exactly the kind of review friction described above. The program rewards real uncertainty; it doesn't reward creative framing of ordinary work.
Automating the collection of that evidence is where software genuinely helps, and it's worth being precise about what it does and doesn't replace. A tool can watch dev tools continuously and flag SR&ED-relevant activity as it happens instead of at filing time — but automation only produces a defensible claim when a qualified, independent SR&ED expert reviews the eligibility calls and narrative before it's filed and stands behind it if the CRA has questions. A CTO evaluating any SR&ED tool should ask who signs off on the technical narrative, not just how much of it is 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, valid up to 3 years, for up to 3 projects — 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.