Key takeaway: SR&ED eligible activities are defined by a two-part CRA test — a "why" (advancement of scientific knowledge or technological advancement, in the face of real uncertainty) and a "how" (systematic investigation by experiment or analysis) — not by industry, headcount, or whether the project succeeded. The CRA recognizes 8 categories of eligible support work, and it explicitly excludes market research, routine quality control, social sciences, prospecting, commercial production, and style changes. A failed project can still qualify. Most companies that skip SR&ED aren't ineligible; they've just never checked their work against the actual test.
Ask ten founders what qualifies for SR&ED and you'll get ten different guesses, most of them wrong in the same direction: too narrow. "We're not a lab." "We didn't invent anything." "The project failed, so it doesn't count." None of that is how the CRA actually defines SR&ED eligible activities.
The real test is narrower than "we did engineering work" but far broader than "we published a paper." Here's what the CRA's own eligibility criteria say, the 8 categories of work that count as support activities, what's explicitly carved out, and why a failed experiment can be worth more to your claim than a smooth one.
The two-part test the CRA actually applies
Per the CRA's SR&ED eligibility policy, work qualifies as SR&ED when it meets two requirements at once:
- The "why": advancement of scientific knowledge or technological advancement, with uncertainty in the existing knowledge base. You have to be trying to resolve something that isn't already known or documented — a genuine technological uncertainty, not a question you could answer by reading the manual.
- The "how": systematic investigation by experiment or analysis. You have to get there through a methodical process — hypothesize, test, measure, iterate — not by guessing until something works and never writing down why.
Both conditions have to be true. Uncertainty without a systematic process is just trial and error; a rigorous process applied to a solved problem is just competent engineering. SR&ED lives in the overlap: real uncertainty, investigated methodically.
Notice what isn't in the test. There's no requirement that the work happen in a lab, that it produce a patent, that it be conducted by someone with a specific degree, or that the company operate in a particular industry. The test is about the nature of the problem and the nature of the process, full stop.
Failure can still qualify — and that surprises almost everyone
The single most common reason founders self-reject good SR&ED work is outcome bias: "the approach didn't work, so there's nothing to claim." The CRA's own eligibility policy says the opposite — failure can still qualify. The two-part test asks whether uncertainty existed and whether you investigated it systematically. It does not ask whether you succeeded.
This matters more than it sounds like it should. A team that spent three months building a caching layer that didn't hit its latency target still resolved technological uncertainty through systematic investigation — they now know that approach doesn't work, and why, which is itself an advancement in the team's technical knowledge. If anything, a documented failure is often easier to defend than a documented success, because the record of "we tried X, measured Y, and it fell short for reason Z" is unambiguous evidence of a genuine experiment. A clean, obviously-correct-in-hindsight solution can actually look, on paper, like there was never much uncertainty at all.
The 8 categories of SR&ED support work
Beyond the core "why" and "how," the CRA recognizes 8 categories of support work that can be part of an eligible SR&ED project:
- Engineering — design and problem-solving work directly supporting the experimental effort.
- Design — creating and refining the technical approach being investigated.
- Operations research — modeling and analyzing complex systems or processes to resolve a technical unknown.
- Mathematical analysis — the quantitative work underpinning an experiment or model.
- Computer programming — writing code as part of resolving technological uncertainty (not writing code in general).
- Data collection — gathering the information needed to run or evaluate an experiment.
- Testing — validating whether an approach resolves the uncertainty it was meant to address.
- Psychological research — where human-factors uncertainty is part of the technical problem.
Two things to notice. First, "computer programming" is on this list by name, which is a big part of why software work shows up in SR&ED claims as often as it does — software development alone accounted for 42.6% of all SR&ED credits allowed in fiscal year 2025–26, per the CRA's own statistics. Second, every category on this list is a support activity — it has to be in service of resolving the core technological uncertainty, not simply labor that happens to be adjacent to a project. A developer writing routine CRUD endpoints is doing computer programming, but not in support of any uncertainty being investigated, so that time isn't the SR&ED-eligible part of the sprint.
What's explicitly excluded
The same CRA eligibility policy is just as specific about what doesn't qualify:
- Market research — understanding customer demand or market fit isn't a technological question.
- Quality control or routine testing — checking that a known process still produces a known result isn't uncertainty; it's verification.
- Social sciences research — unless it's specifically the psychological research category described above and tied to a technological uncertainty.
- Prospecting — a carve-out aimed at resource-sector exploration activity that isn't itself R&D.
- Commercial production — actually manufacturing or operating at scale, as opposed to the R&D that preceded it.
- Style changes — cosmetic or aesthetic updates with no underlying technical uncertainty.
Notice the pattern: every excluded category describes work that's valuable to a business but doesn't involve resolving a technological unknown through experimentation. A well-run company does plenty of this work — market research, QA regression suites, UI polish — and none of it is a knock against the company. It's just not what this specific program funds.
What this looks like in practice
The two-part test is abstract until you run a real decision through it. Consider a team trying to reduce a search feature's latency. If they knew in advance which of three indexing strategies would hit the target and simply implemented the known-best option, there's no uncertainty and no SR&ED. If instead they didn't know whether any approach could hit the target, built and benchmarked multiple strategies under realistic load, and used the results to decide, that's uncertainty resolved through systematic investigation — the core of the test, regardless of industry.
The same structure applies far outside software. A biotech team testing whether a formulation is stable at a new storage temperature, a manufacturer trying to reduce material waste in a process where the physics isn't fully predictable, an agtech company running field trials on a new irrigation method — all of it can meet the same two-part test, because the test is about the shape of the problem, not the sector. This is also why "we're not a tech company" is a weak reason to skip SR&ED. The 8 support-work categories name computer programming, but they equally name engineering, design, mathematical analysis, and testing, none of which are software-specific.
If your team builds software specifically, the pattern usually shows up as: could we have looked this up, or did we have to find out? More engineering work clears that bar than most founders assume.
Why "who qualifies" is really "which hours qualify"
One correction worth making explicitly: SR&ED eligibility isn't a company-level label. It's evaluated project by project, and often task by task within a project. A single sprint can contain SR&ED-eligible work (the uncertain part) and non-eligible work (the routine part) side by side. The programming category above only covers the code written in support of resolving uncertainty — the surrounding CRUD, styling, and configuration work in the same codebase, written by the same person in the same week, isn't automatically swept in.
That distinction is exactly why documentation matters more than intuition here. Knowing your team does R&D-flavored work isn't the same as being able to show, activity by activity, which hours met the two-part test and which didn't. The CRA's own filing requirements put the burden on the claimant to have the prescribed information ready by the reporting deadline, not to reconstruct it after the fact.
Eligible activities also set your overhead claim
There's a second, less obvious reason to get the eligibility call right: it doesn't just determine which salaries you can claim directly, it also sets the base for overhead. Most claimants use the prescribed proxy amount instead of tracking every overhead invoice individually, and per the CRA that proxy has been set at 55% of your SR&ED salary base since January 1, 2014. That means every dollar of salary you correctly attribute to eligible activities pulls an extra 55 cents of overhead into the claim automatically. Undercounting eligible hours doesn't just shrink the direct labor claim — it shrinks the proxy amount riding on top of it, twice over.
That's a practical reason to take the task-by-task exercise seriously rather than rounding down out of caution. A developer who spent 60% of a sprint on a genuinely uncertain caching problem and 40% on routine cleanup isn't choosing between "claim the sprint" and "skip the sprint" — the honest answer is claiming the 60%, proxy included, and leaving the rest out. Rounding an uncertain 60% down to zero because the work felt mixed is where real, eligible money quietly disappears.
What eligible activities are worth
Getting the eligibility call right has real financial stakes, because the credit rates attach to whichever expenditures clear the test. Per the CRA's investment tax credit policy, Canadian-Controlled Private Corporations earn a 35% refundable credit on up to $6 million of qualifying expenditures per year for tax years beginning after December 15, 2024 — double the old $3 million limit — with the rate for everyone else at 15%. That 35% rate is 100% refundable on current expenditures up to the limit, meaning cash back even against zero tax owing. On $6 million of eligible spend, that's up to $2.1 million a year, but only for the portion of the work that actually meets the two-part test. The full breakdown of rates, limits, and the 2026 program changes is worth reading in detail if you haven't already sized your own claim with the SR&ED calculator.
That's also the honest counterpoint to a program this generous: the reward is proportional to real uncertainty, not to how much engineering happened in total. A company that spends $2 million a year on entirely well-understood implementation work, with no genuine technical unknowns, has a small or nonexistent SR&ED claim no matter how good the engineering is. The test filters for uncertainty, not effort.
Who should think twice before claiming
Not every technical team should assume a large claim. If your engineering work mostly consists of integrating well-documented third-party services, applying known design patterns, or shipping features where the implementation path was clear from the start, you may have very little that clears the "why" half of the test — competent execution of known solutions isn't the same as resolving uncertainty. Companies in this position aren't wasting their time by checking, but they should go in expecting a claim scoped to a genuinely uncertain subset of the work, not the whole engineering budget. Overclaiming routine work is also the fastest way to draw CRA review attention you don't need.
Documenting eligible activities as they happen
The two-part test rewards teams that can show their work, not just describe it after the fact. A note in a pull request explaining why an approach was uncertain, a ticket recording which alternatives were benchmarked and why one was rejected, an architecture decision record capturing the unresolved question at the start of a sprint — these are the raw materials of a defensible SR&ED claim, and most engineering teams already produce something like them without thinking of it as SR&ED documentation.
Glauq's approach is to capture that evidence continuously from the tools your team already uses — commits, tickets, and technical discussions — so the record of which hours met the two-part test exists from the week the work happened, not reconstructed at filing time. A qualified, independent SR&ED expert still reviews every claim before it goes to the CRA and stands behind it if questions come back. The eligibility test itself doesn't change based on who prepares your claim; what changes is whether the evidence for it still exists eighteen months later.
Frequently asked questions
What is the actual CRA test for SR&ED eligible activities? A two-part test: work must pursue an advancement of scientific knowledge or technological advancement in the face of real uncertainty (the "why"), and it must be carried out through systematic investigation by experiment or analysis (the "how"), per the CRA's SR&ED eligibility policy. Both conditions must be met; neither alone is sufficient.
Does a failed project still qualify for SR&ED? Yes. The CRA's eligibility policy states that failure can still qualify — the test asks whether uncertainty existed and was systematically investigated, not whether the attempt succeeded. A well-documented failed experiment can be as strong a claim as a successful one.
What kinds of work count as SR&ED support activities? The CRA recognizes 8 categories: engineering, design, operations research, mathematical analysis, computer programming, data collection, testing, and psychological research, per the same eligibility policy. Each only counts when it's in direct support of resolving a technological uncertainty, not general labor on a project.
What activities are excluded from SR&ED? Market research, quality control or routine testing, social sciences research (outside the psychological-research category), prospecting, commercial production, and style changes are all explicitly excluded, per the CRA's eligibility policy. These can be legitimate, valuable business activities — they just don't meet the technological-uncertainty test.
Is SR&ED only for software or tech companies? No. The two-part test and the 8 support-work categories apply across industries — engineering, mathematical analysis, and testing are not software-specific. Software happens to be a large share of claims (42.6% of credits allowed in fiscal year 2025–26, per the CRA's statistics), but biotech, manufacturing, and agtech projects can meet the same test.
How do I know if my specific project qualifies? Run it through the two-part test directly: could your team have determined the outcome in advance using standard, available knowledge, or did you have to investigate? If investigation was genuinely required and you followed a methodical process to do it, check your eligibility and use the SR&ED calculator to see what it could be worth before you commit time to a full claim.
The eligibility test is the same whether you file it yourself or not — what usually decides a claim is whether the evidence for it still exists. Check your eligibility or estimate your refund to see where your work stands.