Reviewed by Logan Hanson, BSc, CPA. Last verified against CRA guidance on August 4, 2026.
There’s no CRA list of “approved” software. No category that’s automatically in and none that’s automatically out. What qualifies is any software development where you had to resolve genuine technical uncertainty, whatever the domain. That said, after enough claims you start to see the same kinds of work show up again and again. So here are the categories where software development most often qualifies, with real examples, plus the honest caveats.
Any type of software development qualifies for SR&ED if it meets the three tests: technological uncertainty, systematic investigation, and technological advancement. The domain doesn’t decide it. The uncertainty does. Below are the categories where that uncertainty tends to show up, but treat them as prompts to find your own eligible work, not as a checklist to match.
Using a model library isn’t automatically SR&ED, but the work around getting a model to actually perform often is. Think developing a novel architecture, engineering features nobody had a recipe for, hitting an accuracy or latency target that wasn’t known to be achievable, or making a model run inside tight memory or cost limits. Calling an off-the-shelf API is not eligible. Making it work where it wasn’t designed to, when that takes real experimentation, can be.
When your system has to do something at a scale, speed or reliability the standard approach couldn’t deliver, and you had to invent or heavily adapt an approach, that’s classic SR&ED. Handling a data volume that broke your architecture, cutting latency past what tuning could reach, or building for a concurrency level with no documented pattern are the kind of problems that tend to qualify, when there was real uncertainty in getting there.
Making systems work together that were never designed to is a common source of eligible work, once it goes past following an integration guide. If there was no documented path, the interfaces fought each other, and you had to experiment to get reliable behaviour, the experimental part can qualify.
Developing an algorithm or data structure to solve a problem existing methods choked on is often eligible. The test is whether a competent professional could have produced it from standard practice. If they could have, it’s routine. If it took real experimentation to find something that worked, it’s a candidate.
Building internal platforms, pipelines or tooling can qualify when you push past what existing tools can do and have to solve a genuine technical unknown to do it. Standard CI/CD setup doesn’t qualify. Engineering a build or deployment system to overcome a technical limitation nobody had a published fix for can.
Software work usually doesn’t qualify when the outcome was never in technical doubt. Building standard features, UI and UX work, configuring software the way the vendor documents, routine debugging, and testing to a plan all fall outside SR&ED on their own, no matter how much effort they took. The line is uncertainty, not difficulty.
Here’s how the money works when you isolate the eligible part. A CCPC with $300,000 in eligible developer salaries and a $25,000 arm’s-length Canadian contractor (claimable at 80%, so $20,000) has a qualifying base of about $320,000, and roughly $112,000 in federal credit before the prescribed-proxy overhead amount and provincial credits. In this case the team shipped a big release, but only the part where they built a new sync algorithm to keep offline and online data consistent was genuinely uncertain. That slice was the claim.
Because it’s a CCPC, that 35% federal credit is refundable, so it comes back as cash even in a year with no tax owing. The 35% refundable rate applies to the first $6 million of qualifying spend, up to $2.1 million a year, and phases out as taxable capital grows. With provincial credits on top, the combined return is higher than the federal credit alone, though not by simple addition, and how much higher depends on your province. Our State of SR&ED overview has more on how the program sizes up.
Software work qualifies when you can tie it to a real technical unknown, so hunt for those unknowns across everything you built. Run this over your year:
Most teams find more than they expected once they stop thinking in whole projects and start thinking in uncertain slices.
SRED.ca charges a flat fee, billed monthly, never a percentage or contingency fee, which usually works out to roughly half the lifetime cost of a percentage-based firm. As far as we know, we’re the only SR&ED provider that publishes its pricing on its website, so you can see it before you talk to us. We’re CPA-owned, audit defense is included, and if the CRA approves less than 75% of the filed claim we waive our fees, which you can read about on our 75% guarantee. If there’s no eligible work in your year, you don’t pay. We also track your eligible work year-round, which is how the smaller qualifying slices across your projects actually make it into the claim.
The software development that qualifies for SR&ED isn’t a category you belong to. It’s the specific work, in any category, where you had to resolve a real technical unknown. Look across everything you built this year, find those slices, and tie your costs to them. If you’d like a second opinion on what qualifies in your codebase, grab a free consultation and we’ll walk it with you. The CRA’s SR&ED program page sets out the official criteria.
Related reading: why tech firms struggle with SR&ED claims, how SR&ED tax services support startup R&D credits, and what could go wrong if founders file on their own.
Using PyTorch or a similar library can qualify, but only the experimental part that resolves technological uncertainty is eligible. Using the library the documented way is not. If you had to develop a new approach, engineer features nobody had a recipe for, or hit a target that wasn’t known to be achievable, that experimental work can qualify.
Routine app development, building standard features and UI, usually doesn’t. But a mobile project can contain eligible work if it hit a genuine technical unknown, such as a novel on-device processing method or a performance problem with no documented solution. The app being mobile doesn’t decide it; the uncertainty does.
Standard setup and configuration are not. Infrastructure work becomes eligible when it resolves real technological uncertainty, like engineering a system to overcome a scaling or reliability limit that had no published fix and required experimentation to solve.
Yes. SR&ED does not require success or shipping. If the work addressed technological uncertainty and you investigated it systematically, it qualifies even if you abandoned the feature. You still generated technical knowledge, which is what the program rewards.
Yes. You claim the eligible work wherever it happened, aggregated across your projects for the year. Many companies leave money behind by only looking at their flagship project and missing smaller pockets of uncertain work elsewhere.
No. Eligibility is about the nature of the work, not your headcount. A two-person startup resolving genuine technical uncertainty qualifies on the same terms as a large engineering org. Team size only affects the dollar amount, through the salaries and contractor costs you can claim.
This article is general information, not tax advice. Tax figures depend on your corporation type, province, and taxation year.
Do you have a SRED question? Planning for the future or perhaps you want to know how much your claim might be? Don’t worry, our CPA is always ready to answer any question. Get a SRED expert in your corner.
Have a question? We’d love to help. If you don’t have a SR&ED expert in your corner, doesn’t it make sense to have one?
