SR&ED for SaaS Companies in 2026: What Actually Qualifies

SaaS founders chronically under-claim SR&ED because they apply consumer intuitions — “I just shipped features” — to a program that rewards a very specific technical pattern. The CRA isn't asking whether you built something new. It's asking whether you advanced technological knowledge in a non-obvious way. Properly framed, most SaaS engineering qualifies. Properly documented, almost none of it gets denied.

We see the same story every spring: a founder books a call in March, pulls up GitHub, and starts narrating a year of work that was clearly eligible — but they've already shipped the code, closed the tickets, and lost the trail of whyeach decision was hard. The claim still goes in, but it's thinner than it should be. This guide is the framing we wish every SaaS team had on day one of their fiscal year.

The CRA's actual test

Every SR&ED claim collapses down to three criteria. If your work clears all three, it qualifies. If it misses any one, it doesn't.

1. Scientific or technological uncertainty.At the start of the work, a competent professional couldn't have known whether a given approach would work, or what the right approach even was. The problem isn't solved by reading the docs.
2. Systematic investigation.You formed a hypothesis, ran an experiment, observed a result, and iterated. Not necessarily in lab coats — a prototype branch with a measured outcome counts. Trial-and-error with no analysis does not.
3. Advancement of knowledge.The work produced new technical understanding. The advancement can be entirely internal to your team — it does not need to be a public-domain first.

The most important sentence in this whole article: novelty in the market is irrelevant; novelty in technical knowledge is what counts. You can be the tenth company to build a recommendation engine and still have a perfectly defensible SR&ED claim, because the question is whether your engineersfaced real uncertainty — not whether the category is new.

What SaaS engineering work counts

The categories below cover roughly 90% of the qualifying work we see across our SaaS clients. Use them as a mental checklist when you scan your last quarter.

Performance and scaling work

Query optimization that goes beyond standard indexing — rewriting access patterns to hit p99 targets that vendor documentation doesn't cover. Distributed-systems work to handle load patterns that no off-the-shelf solution solves cleanly: sharding under write-skewed workloads, cross-region consistency trade-offs, queue backpressure under bursty traffic. Novel caching strategies where the invalidation logic itself was the hard part.

A useful test: if your senior engineer can't describe the solution as “we followed the obvious playbook,” there was probably technological uncertainty in the work.

Custom ML and AI engineering

Calling the OpenAI API is not SR&ED. Choosingthe right model, prompt structure, retrieval pattern, evaluation harness, or fine-tune for a problem where the architecture wasn't obvious canbe. Building or fine-tuning models, designing domain-specific embeddings, engineering RAG pipelines that have to meet quality bars stock implementations miss — that's squarely in scope.

The 2026 lens matters here: the CRA has gotten more sophisticated about AI work, and the line is now drawn around the engineering decisionsyou had to make and validate empirically, not around the headline fact that “we used AI.”

Algorithmic problems

Ranking, matching, pricing, allocation, scheduling, routing — any time you build an algorithm where stock implementations fall short because of your data, your latency budget, or your business constraints, the design work likely qualifies. The signal is that you had to define and test multiple approaches before you found one that held up.

Data pipelines under unusual constraints

Real-time analytics with sub-second freshness, schema evolution at scale (column-store migrations, backfills across billions of rows), novel integration patterns where you had to invent a contract because none existed — this is the unglamorous-but-eligible bucket. Lots of SaaS data work qualifies and almost none of it gets claimed, because nobody thinks of pipeline plumbing as “R&D.”

Reliability and observability engineering

When out-of-the-box monitoring doesn't capture the behavior of your system and you build instrumented experiments to figure out what's going wrong — chaos testing, custom tracing, homegrown SLO frameworks, performance regression detection on weird signals — the experimental nature of that work tends to map cleanly to the SR&ED test.

What gets denied

The denial patterns are just as predictable as the eligible ones. These four show up in almost every rejection letter we read for new clients who filed without help.

“We built a new dashboard”

UI work without underlying technical uncertainty is not SR&ED, no matter how complex the design or how many sprints it consumed. A beautiful React component tree is a product achievement, not a technological advancement. If the hard part was the design and the coordination, not the technical problem, it doesn't qualify.

“We integrated Stripe / Twilio / [SaaS]”

Wiring up well-documented APIs is not R&D, even when the integration is large and the data mapping is fiddly. The CRA assumes a competent developer can read documentation. If your engineering challenge can be solved by reading docs and writing glue, it's development work, not experimental development.

Routine bug fixes and refactors

Even significant refactors don't qualify on their own. Renaming modules, splitting services, upgrading dependencies, tidying technical debt — all valuable, none of it experimental. The bar is whether you faced uncertainty about whether something could be done, not just how to do it cleanly.

“We're using a new framework”

Adopting Next.js 15, switching from REST to GraphQL, moving to a new ORM — that's adoption, not experimentation. Building a fundamentally new framework, or pushing an existing one past its documented behavior, can qualify. Using the framework as intended does not.

Activity-by-activity: what qualifies

Six concrete examples, drawn straight from claims we've filed, with the framing that made the difference between accepted and denied.

Documentation that survives a review

The single biggest predictor of whether a claim survives CRA review isn't the work itself — it's whether your team logged the thinking while it was happening. The pattern is simple:

1. Log your hypotheses.Before you start the work, write down what you think will happen and why. One paragraph is enough. If you can't articulate a hypothesis, there probably wasn't real uncertainty.
2. Log your experiments. When you try an approach, record what you tried, what the inputs were, and what you measured. A short note in the ticket or in a shared engineering doc is fine.
3. Log your results.Especially the failures. Prototype branches that died are some of the strongest SR&ED evidence we ever submit, because they prove the work was experimental rather than executional.

Concrete formats that work in practice: a weekly engineering retro with a “what didn't work” section, ticket-level notes that name the uncertainty up front (“we don't know whether approach A or approach B will hold up under load X”), and preserved prototype branches with short README explanations of what was tested and why it was abandoned.

The numbers (for a BC CCPC)

A quick refresher on what you actually get back. For a Canadian- controlled private corporation (CCPC) headquartered in British Columbia in 2026:

• Federal SR&ED ITC: 35% refundable on the first $3M of qualified expenditures, 15% (non-refundable) above that threshold.
• BC SR&ED ITC: 10% provincial credit, refundable for a CCPC.
• Combined headline: up to 64%of qualifying SR&ED expenditures recovered, depending on the labour mix and proxy treatment.

Worth flagging: the 35% refundable CCPC rate was a political question for a stretch in 2025, and the 2025 federal budget keptthe favorable CCPC treatment intact for 2026. That's the regime SaaS companies are filing under right now, and it's the one that turns a strong engineering year into a material cash refund.

If you want to see what your specific spend translates to, we keep a live calculator on the Axscope homepage— plug in headcount and salary mix and you'll get a rough number in seconds.

When to start tracking

Day one of your fiscal year. There's no clever way to put this: most SaaS companies leave real money on the table because they try to reconstruct evidence in March for a December fiscal year-end. By the time you're looking, you've forgotten which approaches you tried in February, which prototypes you killed in May, and what actually was uncertain at the time versus what feels obvious now.

Live tracking flips the economics. When the documentation pattern is running all year, the annual filing is a two-week exercise instead of a six-week scramble — and the claim is bigger, because nothing falls through the cracks. The teams that get the largest refunds relative to their headcount are almost always the ones that started tracking before they had a refund to chase.

Next steps

If you're running a SaaS company in Canada and you suspect you've been under-claiming, three things you can do this week:

1. Audit your last quarter.Walk through the completed work with one engineer and one finance person, and tag each project against the three CRA criteria. You'll surprise yourself with how much was eligible.
2. Set up a weekly engineering log.A shared doc, a ticket template, a recurring retro — any format will do. What matters is that hypotheses and failed experiments are written down while they're fresh.
3. Talk to a consultant before your next fiscal year-end. The conversation is cheap, and the upside is large. See our SR&ED service page for how we work, or send a short note via the contact pagedescribing your stack and your fiscal year — we'll send back a one-page eligibility memo within a business day.

SR&ED isn't a reward for inventing something the world hasn't seen. It's a reward for doing the kind of careful, experimental engineering that most serious SaaS teams already do every quarter. Framed and documented well, it's one of the most reliable sources of non-dilutive capital available to Canadian founders — and if you're also raising equity, it stacks cleanly with the BC EBC and VCC programs on the investor side.