Key takeaway: SR&ED for gaming startups runs through the same two-part CRA test as any other software claim, but the split between what qualifies and what doesn't tracks the split between engineering and content unusually cleanly. A new physics solver, a netcode approach for a genre with no published reference architecture, or a procedural-generation system that has to hit a performance budget nobody's hit before — that's real technological uncertainty. A level built with your existing tools, a character redesign, a balance pass — that's excluded "style changes" work no matter how many iterations it took. Canada's gaming clusters in Montreal, Vancouver, and Toronto sit inside a software category that already takes 42.6% of all SR&ED credits allowed — the opportunity is real, and so is the trap of claiming the wrong half of the studio's work.
Game studios have a strange relationship with SR&ED. Some assume a creative industry can't possibly qualify for an R&D tax program built for labs and engineers. Others assume that because shipping a game is famously hard, everything that goes into it must count. Neither read survives contact with the actual test, and the honest answer sits in the middle, in a place most studios have never had to draw precisely.
Here's where that line falls: what kind of game engineering clears the CRA's bar, what looks technical but is really content work, how the contractor and capital rules apply to a studio, and where teams that ship annually get the documentation wrong.
Does SR&ED cover game development
Yes — but only the part of it that's engineering research, not the part that's making a game. The CRA doesn't have a games-specific rule; it applies the same two-part eligibility test it applies everywhere: was there a technological uncertainty standard practice couldn't resolve, and did you resolve it, or try to, through systematic investigation rather than iteration by feel.
Computer programming and mathematical analysis are both named in the eight recognized categories of support work, alongside engineering, design, operations research, data collection, testing, and psychological research. A rendering pipeline or a netcode stack gets evaluated the same way a database engine would. What doesn't transfer from generic software advice is the shape of the excluded category — because gaming runs headfirst into it in a way most B2B software teams never do.
The exclusion that matters most for games
"Style changes" is one of the CRA's named exclusions from eligible work, and it lands on gaming harder than on almost any other software vertical. Redesigning a character, retuning an economy for fun, reworking a UI for clarity, building a new level with tools that already exist — none of that resolves a technological unknown, however much creative iteration it took to get right. It's design work, and design work that doesn't hit a technical wall isn't SR&ED just because a studio calls it "R&D" internally.
The eligibility guidance also excludes market research and sales promotion, and routine quality control or testing — both of which show up in games as playtesting for fun and balance (a design activity) versus playtesting to verify a technical fix actually resolved a defect (which can be legitimate testing evidence inside an eligible project, not a project on its own). The line isn't "did a human iterate on this many times." It's whether the iteration was chasing a subjective creative target or measuring against a technical hypothesis that could fail.
Where the real engineering uncertainty shows up
Real engineering uncertainty in games clusters on the engine and tools side, not the content side. The tell is whether a senior engineer at a comparable studio could have predicted the outcome in advance — and in games, the "no" answers show up in specific, recurring places.
Netcode for a genre with no published reference architecture at your player-count and latency target is a common one: keeping dozens of players' state consistent under real-world packet loss, at a tick rate nobody's documented hitting for your specific game type, is genuine systems uncertainty. Procedural generation that has to guarantee playability — not just variety — under a hard performance budget is another. Producing content algorithmically is easy. Producing content that's provably traversable, balanced, and fast enough to generate in-frame is a real constraint-satisfaction problem with no off-the-shelf answer.
Physics work pushing past what an off-the-shelf engine's solver handles counts too: soft-body deformation, large-scale destruction, fluid or cloth at a player count the stock solver chokes on. So does a rendering technique attempting a visual or performance target the current literature and shipped titles haven't reached on your target hardware, or a machine-learning system for NPC behavior or animation where the failure modes aren't known going in. Anti-cheat detection belongs on the same list and rarely gets mentioned: building a heuristic or model that catches novel exploit patterns in your specific game, without a false-positive rate that alienates legitimate players, is an open, unsolved problem for most genres — there's no published detector you can just implement.
This mapping of the general CRA test onto game-engineering scenarios is our read on how the rule applies, not a CRA-published games bulletin — there isn't one. The CRA sets a technology-neutral standard and expects an honest application of it to whatever a studio's engineers actually attempted.
Two studios, two different claims
Picture two Canadian studios that would both describe themselves as doing "years of R&D" before launch.
Studio A spends eighteen months building a narrative platformer in a licensed engine, using the engine's built-in physics, animation, and rendering exactly as documented. The team iterates constantly — level layouts, difficulty curves, boss fight timing, dialogue trees — and every iteration is genuinely hard creative work. But nothing about the underlying technology's behavior was ever in question; the engine does what its documentation says it does, and the uncertainty the team faced was "is this fun," not "will this work." That's a real game and a thin SR&ED claim, if there's one at all.
Studio B is building an open-world game where hundreds of physics-simulated objects need to interact simultaneously without the frame rate collapsing on mid-range hardware — a problem the licensed engine's stock solver can't handle at that object count, so the team designs and tests its own spatial-partitioning and simulation-LOD system across several architectures before one holds up under load. That's a documented technical hypothesis, a series of experiments, and results that didn't match expectations until the design changed. Studio B's claim has something real behind it, and it would look identical whether the genre were a platformer, a shooter, or a puzzle game — the eligibility has nothing to do with the finished game being fun.
Both studios did real work. Only one of them did work that clears the SR&ED bar, and a studio doing both — which is normal, since every game needs shipped content around its engineering — needs to separate the two honestly rather than claim the whole production budget.
Contractors, co-development, and the 80% rule
Only 80% of what a studio pays an arm's-length contractor for SR&ED work counts toward the qualified expenditure pool — the same rule as any other software claim, applied here to contract artists doing genuine technical work, outsourced porting shops, and specialized netcode or audio contractors, all more common in games than in most software teams. That rule has applied since 2012 and doesn't bend for a studio's invoice format.
Whether a given engagement even counts as a contract payment turns on the substance of the deal, not the label on the purchase order: did the contract require specific experimental engineering work, or general production labour against a spec you'd already locked? Who carried the risk if the technical approach didn't pan out? A studio outsourcing a netcode rewrite to a specialist shop should get that scoping right in the contract itself — it's the fact pattern a reviewer looks at, not the invoice line item.
Porting deserves its own mention because studios treat it inconsistently. A straight console port done against a documented SDK, following the platform holder's own optimization guides, is applying known practice — not SR&ED, whoever does the work. A port that has to solve a genuinely undocumented performance or memory problem on a specific console's architecture, where the platform's own guidance doesn't get you there, is a different animal entirely. Same contractor, same invoice format, different eligibility depending on which kind of porting problem the team actually had.
Engines, tools, and capital equipment
Most studio SR&ED claims run on salaries — the engineers and technical artists doing the experimental work — and the CRA's proxy method adds an overhead allowance on top rather than requiring line-item tracking of every tool subscription and render-farm hour. The prescribed proxy amount has been 55% of the SR&ED salary base since 2014.
Capital equipment is worth flagging specifically: eligible capital property acquired after December 15, 2024 is claimable again, at 40% refundable on the 35% rate. For a studio that bought motion-capture hardware, specialized VR rigs, or a dedicated render/build farm to support genuine R&D work — not general production — that restored eligibility is new money that wasn't there before 2024.
What studios get wrong about documentation
The most common failure mode isn't claiming ineligible content work outright — most studios know a character redesign isn't R&D. It's losing the evidence for engineering work that was genuinely eligible, because game studios document for production, not for a tax claim.
A commit message that says "fixed netcode desync" doesn't show what the team hypothesized was causing it, which approaches they tried and discarded, or why the fix that worked wasn't obvious going in. A design document captures the target, not the technical uncertainty around hitting it. By the time a studio sits down eighteen months later to build a claim, the engineer who fought through the hardest stretch of a crunch-driven production may already be at the next studio, and the Slack threads where the real debugging happened have scrolled into the archive. The CRA's own guidance is explicit that a project doesn't need to succeed to qualify — an approach the team tried and abandoned is evidence, not a gap in the claim, but only if someone captured why it was tried and why it failed.
Who should think twice before claiming
Skip this, or claim narrowly, if a studio's engineering is almost entirely built on a licensed engine used as documented, with the real effort going into content, art, narrative, and balance. Iterating on fun is not iterating on a technological unknown, no matter how many playtest cycles it took or how many crunch weeks it cost.
The mirror mistake is just as common: studios that assume a creative industry automatically disqualifies them from an R&D program, and never look at what their engine or tools team actually built. If a studio's engineers hit a real technical wall — netcode, procedural generation, simulation, or rendering — and ran structured experiments to get past it, that's exactly the kind of work this program funds, independent of whether the finished game is a AAA shooter or a two-person indie release.
What SR&ED for gaming startups is actually worth
The rates don't change because the R&D happens to sit inside an entertainment product. A Canadian-controlled private corporation earns the enhanced 35% refundable rate on up to $6 million of qualifying expenditures a year, for tax years beginning after December 15, 2024, with the basic 15% rate applying beyond that — as much as $2.1 million a year at the enhanced rate. Current expenditures like salaries at the 35% rate are 100% refundable up to the limit for most CCPCs, cash even against zero tax owing, though excluded corporations receive 40% instead.
Studios based in Quebec have an added layer worth knowing: Quebec's CRIC credit stacks with the federal credit, though not additively — the real combined first-tier rate works out closer to 54.5%, not a naive 65%, because provincial credits reduce the federal base under the s.127(18) grind rule. The same non-additive math applies to any studio in BC, Ontario, or Alberta claiming both credits.
The clock is identical to every other industry too: a corporation's SR&ED reporting deadline is 18 months after its fiscal year end, with no extension process available. A studio in full crunch ahead of a launch date is precisely the kind of team that lets that date slip while everyone's heads-down on the ship.
That's the part of the job that doesn't care whether the codebase renders polygons or processes payments: continuous documentation, captured from the tools a studio's engineers already use, reviewed by a qualified independent SR&ED expert before anything is filed. Automation on our side handles the collecting; a named human still stands behind what goes in front of the CRA. It doesn't decide whether a netcode rewrite or a procedural system qualifies — that's still the two-part test — but it means the evidence exists when the claim gets built instead of being rebuilt from a year-old commit history after the team that did the work has scattered to three other studios.
Frequently asked questions
Does making a video game qualify for SR&ED on its own? No. Making a game isn't the test; resolving a genuine technological uncertainty through systematic investigation is, per the CRA's eligibility guidance. A studio can ship an excellent, technically ordinary game with no eligible SR&ED work, or a modest one built on a genuinely novel engine system that clears the bar.
Are level design, art, and balance work eligible for SR&ED? Generally no. The CRA names "style changes" as an excluded activity, and creative iteration aimed at a subjective target — is this fun, does this look right — doesn't resolve a technological unknown, however many iterations it took.
Is building on a licensed engine like Unity or Unreal automatically disqualifying? Not automatically, but it raises the bar. Using an engine's documented features as intended is adopting existing technology, not advancing it. Work that pushes past what the stock engine can do — a custom solver, a novel netcode layer, a rendering technique beyond documented limits — can still qualify.
Does outsourcing art, porting, or netcode work change what a studio can claim? Yes, if the contractor is arm's length. Only 80% of that contract payment enters the qualified expenditure pool, and whether a given engagement counts as a contract payment at all depends on the substance of the arrangement, not the invoice description.
Can a Quebec-based studio claim both the federal and provincial credit? Yes, and most studios with a permanent establishment in the province should. The two don't add directly — Quebec's CRIC credit reduces the federal expenditure base under the grind rule, so the real combined first-tier rate is closer to 54.5%, not 65%.
Does capital equipment like motion-capture or VR hardware qualify? It can, if acquired after December 15, 2024 for genuine R&D use rather than general production, per the CRA's restored capital-expenditure eligibility. Capital expenditures at the 35% rate are 40% refundable.
Gaming doesn't get a special SR&ED rulebook, easier or harder than any other software vertical. It gets the same two-part test, applied honestly to the half of a studio's work that's actually engineering research, not the half that's making the game good.
See what your studio's engineering work could be worth — estimate your refund or check your eligibility.