Key takeaway: Companies that already qualify for SR&ED routinely claim less than they're entitled to, not because the program is stingy but because the claim gets built the same way every year: a scramble in the weeks before the 18-month deadline, from memory, covering only the work someone happened to remember. The fix isn't a bigger accounting effort. It's catching the eligible work while it's still fresh, describing the uncertainty honestly, and allocating salaries — usually the largest line on the claim — to what people actually did. Get those three right and the number changes without changing what your team built.
Most companies that file SR&ED leave money on the table, and it's rarely because they're claiming activities that don't qualify. It's the opposite. They under-claim: a sprint that involved real technical uncertainty gets left out because nobody wrote it down at the time, a contractor's testing work gets forgotten, an engineer's hours get coded to "product" instead of "R&D" because nobody set up the project codes to distinguish them. None of that shows up as fraud risk. It shows up as a smaller refund than the work actually earned.
This is what it means to maximize your SR&ED claim: closing the gaps between what you did and what you claimed, without inflating either side. Here's where the gaps usually are, and what closes them.
How do you maximize a SR&ED claim?
You maximize a SR&ED claim by fixing three things at once: catching eligible work as it happens instead of reconstructing it later, describing the technical uncertainty honestly enough that a reviewer believes it, and allocating time and expenditures to reflect what people actually spent their hours on. Skip any one of the three and the claim understates the real work, even when nothing about it is wrong.
The order matters. A company that nails documentation but still treats SR&ED as a once-a-year exercise will keep missing eligible sprints, because nobody flagged them when they happened. A company that tracks everything year-round but writes thin, vague technical narratives will have the raw material and still under-claim it, because a reviewer can't credit uncertainty they can't see described. Fix the sequencing and the size of the claim mostly takes care of itself.
What SR&ED-eligible work do most companies leave out?
Most companies leave out work that doesn't look like "R&D" from the outside: performance tuning that turned into a genuine unknown, a security fix nobody had a standard playbook for, a scaling problem that took three failed approaches before the fourth one held. None of that reads as a lab, so nobody flags it.
The pattern is consistent enough to name. Founders picture SR&ED as major product launches or a dedicated research team, and anything short of that gets filed mentally under "just engineering." But the CRA's eligibility test doesn't ask how big the project was. It asks whether the work advanced scientific or technological knowledge in the face of real uncertainty, pursued through systematic investigation — and whether the attempt succeeded is beside the point. A sprint that ended in a dead end can qualify exactly like one that shipped.
Watch for these before ruling anything out:
- A fix that took longer than it should have. If the team tried the standard approach, it didn't hold, and someone had to figure out why before trying something else, that gap is often where the eligible work lives.
- Integration work with an unpredictable third-party system. Wiring two systems together is routine. Discovering the documented behavior doesn't match reality and working out a solution isn't.
- Anything that got shelved. A failed experiment still required systematic investigation. It just didn't end where you wanted.
How do you document technical uncertainty so it survives a CRA review?
You document technical uncertainty by writing down, close to when it happened, what you were trying to do, why the obvious approach didn't work, and what you tried instead. That's different from reconstructing a clean story after the fact. A narrative written from memory eighteen months later tends to smooth over exactly the messiness that proves the uncertainty was real.
Picture the difference in practice. One version: "We optimized the checkout flow for performance." That's a sentence a marketing page could use, and it tells a reviewer nothing about whether the work was routine tuning or a genuine technical problem. The other version: "The obvious caching approach broke under concurrent writes; we tested three alternatives before landing on one that held at production load, and here's why the first two failed." The second version is a claim a CRA review can actually evaluate, because it shows the uncertainty instead of asserting it.
Capture, at minimum:
- What the team was trying to achieve, and why the standard approach wasn't good enough
- What was tried, in what order, including the parts that didn't work
- The specific technical obstacle, not just "it was hard"
- How it got resolved, or an honest account of why it didn't
Write these down close to the work, not at filing time. A note from the week of the sprint beats a polished paragraph assembled a year later, even when the paragraph reads better — reviewers can tell which one is which.
What does closing these gaps look like at an actual company?
It looks like small, boring habits compounding over a year, not a single big fix at filing time. Take a hypothetical 15-person SaaS company (illustrative, not a real Glauq client) with one core product and a team that's never separated "R&D" from "regular engineering" in their own heads.
In March, a senior engineer spends two weeks fighting a data-consistency bug that only shows up under concurrent writes at scale. The standard locking pattern doesn't hold. Three alternative approaches get tried before the fourth finally works. Nobody labels this "R&D" at the time. It's just a hard bug. Without a weekly log or a project code that flags it, this sprint is the kind of work that quietly disappears from the claim eleven months later.
In July, the same company brings on a contractor to help with a scaling problem, and in September a different engineer spends a week on a security fix nobody had a template for. Individually, none of these feel like "the R&D project." Collectively, across a year, they're often a larger share of the eligible work than whatever the company originally had in mind as its one big claimable initiative.
The difference between a company that captures this and one that doesn't isn't effort — it's timing. A weekly five-minute note ("hit an issue with X, tried Y, still working on Z") written the week it happens costs almost nothing and survives a year later. The same information, reconstructed from Slack scrollback and fading memory at month seventeen, takes hours to assemble and comes out thinner and vaguer than what actually happened. Multiply that gap across three or four sprints in a year and it's the difference between a claim that reflects the real work and one that reflects whatever anyone happened to remember in the final weeks before the 18-month deadline.
How should you allocate employee time across a SR&ED claim?
You allocate employee time by tracking, at the project level, which hours went to work that meets the SR&ED test and which didn't. That's a different exercise than applying a flat percentage to the whole engineering team's payroll. Salaries are usually the single largest component of a claim, so getting this allocation right or wrong moves the total more than any other single decision.
Under-allocation is the more common failure. A company sets up one broad "Engineering" cost code, and by the time the claim gets built, nobody can reconstruct which weeks were spent on the eligible technical problem versus routine maintenance. The fix is granular from the start: project-level codes that separate SR&ED work from everything else, applied while the work is happening, not reverse-engineered from calendar memory in month sixteen.
A few specifics that get missed even by companies that track time carefully:
- Planning and testing count, not just writing code. Time spent designing an experiment or validating a result is as eligible as the implementation itself, when it's tied to resolving the same uncertainty.
- Partial allocation is normal. An engineer who splits a sprint between a genuine technical problem and routine feature work claims the portion that meets the test, not the whole sprint and not none of it.
- Review the split quarterly, not once a year. A quarterly check catches under-tracked weeks while someone can still remember them; an annual one doesn't.
What can you claim beyond salaries?
Beyond salaries, a SR&ED claim can include materials consumed in the R&D work and a portion of overhead — and for overhead specifically, the CRA gives you a choice of methods that materially changes what "maximizing" the claim looks like.
The prescribed proxy method lets you claim a flat 55% of your SR&ED salary base in place of itemizing actual overhead — rent, utilities, and similar costs tied to the R&D work. That rate has held since 2014 and it's simpler by a wide margin: no receipts to sort, no allocation debate. But simpler isn't always bigger. A company with high real overhead relative to salaries (a lot of specialized lab or compute infrastructure, for instance) can sometimes come out ahead itemizing the traditional way instead. There's no way to know which wins for your situation without running both, which is exactly the kind of comparison our SR&ED calculator is built for.
Materials consumed during R&D — components, supplies, anything used up in the course of the work rather than kept as a finished asset — belong on the claim too. They're one of the more commonly forgotten categories on software-heavy claims, where "materials" doesn't intuitively mean much. It still applies whenever physical inputs get consumed in the process of testing or building something.
(Contractor and subcontracted R&D costs are also part of a complete SR&ED expenditure picture, but the eligibility rules there are specific enough to deserve their own treatment rather than a bullet point here — we'll cover that in a dedicated post rather than risk oversimplifying it.)
Do provincial credits just add on top of the federal rate?
No. Provincial SR&ED credits reduce the pool of expenditures your federal credit applies to, so the combined rate is always a few points lower than adding the two headline percentages together. A claim built on the naive sum will overstate what's coming back.
This is the federal grind, and it comes from subsection 127(18) of the Income Tax Act: a provincial R&D credit counts as government assistance, and government assistance reduces the qualified expenditure base the federal 35% rate applies to, whether or not the provincial credit itself is refundable. A company in British Columbia claiming 10% provincially and 35% federally isn't getting 45% back — the real combined rate lands around 41.5%. In Quebec, a naive 30% + 35% reads as 65%; the actual first-tier rate is closer to 54.5%. Neither gap is a rounding error on a large claim, and "maximizing" a claim that ignores the grind isn't maximizing anything — it's mis-forecasting the refund and setting up a number your finance team will have to walk back later.
The practical upside: once you know the real combined rate for your province, you can forecast the refund correctly the first time instead of promising a number internally that the actual filing won't hit. See the full 2026 rate breakdown for every province's math.
When does it make sense to bring in a SR&ED expert instead of doing this alone?
Bring in a SR&ED expert once your claim is large enough, or your technical work ambiguous enough, that a wrong call on eligibility or allocation costs more than the expert's fee. For most companies claiming into six figures or beyond, it does. A very small, very clean claim with obvious eligible work and simple time allocation is genuinely fine to self-file; not every company needs outside help, and we'd rather say that plainly than pretend otherwise.
Where outside help earns its cost is the judgment calls: whether a given sprint's uncertainty is strong enough to survive a review, whether a partial time allocation is defensible, whether the traditional overhead method beats the proxy for your specific cost structure. Getting those wrong in either direction costs you — under-claim and you leave real money unclaimed, over-claim and you've built a weak narrative that a CRA review can pick apart.
This is the one place we'll say plainly how Glauq fits: the documentation problem above (catching eligible work as it happens instead of reconstructing it at filing time) is what our tooling is built to solve, pulling technical narrative directly from the commits, tickets, and discussions where the work actually happened, in Slack, Jira, and GitHub, as it's created. Automation handles the capture; it doesn't decide eligibility. Every claim still goes through a qualified, independent SR&ED expert who reviews the technical narrative, checks the allocation, and stands behind the filing if the CRA has questions. The two aren't a substitute for each other — the tooling makes sure nothing eligible gets forgotten between February and filing season, and the expert makes sure what's claimed can survive scrutiny.
Frequently asked questions
Do failed experiments qualify for SR&ED? Yes. If the work involved technological uncertainty pursued through systematic investigation, it can qualify regardless of whether it succeeded, per the CRA's eligibility criteria. Failed experiments are one of the most commonly overlooked categories on a claim, largely because founders assume a dead end doesn't count.
What's the prescribed proxy method, and does it maximize my claim? The proxy method lets you claim a flat 55% of your SR&ED salary base instead of itemizing actual overhead. It's simpler, but not automatically bigger — a company with unusually high real overhead relative to payroll can come out ahead itemizing the traditional way instead. Run both before assuming the proxy wins.
What's the single biggest mistake companies make when claiming SR&ED? Treating it as a once-a-year exercise instead of something documented as it happens. By the time the claim gets built, the technical details that would make a strong narrative are already fuzzy, and eligible work gets left off simply because nobody remembered it. Weekly activity notes and project-level time codes fix this at the source.
Do provincial R&D credits simply add to the federal 35% rate? No. Provincial credits reduce the expenditure base the federal credit applies to, under subsection 127(18) of the Income Tax Act, so the combined rate always lands a few points below the naive sum. British Columbia's real combined rate is roughly 41.5%, not 45%; Quebec's first tier is roughly 54.5%, not 65%.
Is it worth hiring help to maximize a SR&ED claim, or can I do it myself? It depends on the claim's size and how ambiguous the technical work is. A small, clean claim with obvious eligibility is fine to self-file. A larger claim, or one built on genuinely uncertain technical judgment calls, is where an independent expert's review earns its cost — both by catching claimable work you'd miss and by making sure what you do claim survives a CRA review.
Want a second set of eyes on what your team actually built this year? Check your eligibility or estimate your refund in under 2 minutes.