Key takeaway: SR&ED for dev shops runs into a mechanic most agencies never hear about until they try to claim it: payments you receive for SR&ED work performed under contract reduce your own pool of deductible SR&ED expenditures, project by project. Build a genuinely novel piece of engineering for a client and get paid for it, and that payment generally comes off your own claim for the same work — not the other way around. Your client, meanwhile, is the one who usually claims 80% of what they paid you. The credit tends to follow the money, not the keyboard.
A dev shop's instinct is that whoever wrote the code should get the credit. That instinct is wrong often enough that it's worth a post of its own.
Here's how SR&ED actually splits between an agency and its client when the work happens under contract: what a contract payment does to your own expenditure pool, the four factors the CRA uses to decide whether a payment even counts as one, what your agency can still claim outright, and the double-claim mistake that trips up shops juggling several client contracts at once. If you haven't claimed SR&ED at all yet, our complete SR&ED guide covers the program from the ground up; this post assumes you know the basics and goes straight at the contract-specific mechanics.
Does a dev shop get to claim SR&ED for work done under contract
Usually not, at least not on the terms you'd expect. When a client pays you to perform SR&ED on their behalf, that payment reduces your own pool of deductible SR&ED expenditures for the same work — the CRA's contract payment rule runs in the opposite direction from what most founders assume.
Our read on the logic: it's an anti-duplication rule, not a penalty on agencies. The government isn't going to fund the same piece of R&D twice — once through a credit to the client who commissioned it, and again through a credit to the agency who happened to execute it. Somebody gets the ITC on that expenditure. The default answer is the party who paid for the work, not the party who typed it. That's our interpretation of why the mechanic exists, not something the CRA states as a rationale on the policy page itself — the page states the rule, not the reasoning behind it.
That default only applies to work performed under a genuine contract payment, which is a narrower category than "any invoice we sent a client." We'll get to how that's decided. But the starting assumption for a dev shop building something uncertain for a paying client is: the R&D might be real, the eligibility test might be satisfied, and your agency might still not be the one who gets to claim it.
How the reduction actually works, project by project
Here's the arithmetic. A contract payment you receive reduces your own eligible SR&ED expenditure pool for that specific project, dollar for dollar, up to the amount you'd otherwise have been able to claim. It's calculated project by project — a payment on one engagement doesn't touch the pool on another, even at the same agency.
Picture an agency that spends $250,000 in salaries building a genuinely novel data-pipeline architecture for a client, and bills the client $220,000 for the engagement under a fixed-price contract that qualifies as a contract payment. That $220,000 comes off the agency's own pool of deductible SR&ED expenditures for that project. What's left over — here, roughly $30,000 — is what the agency could still pursue on its own claim for that specific project, assuming the underlying work clears the two-part eligibility test in the first place.
One detail agencies miss: if the contract payment received exceeds the expenditures incurred on that project in a given year, the excess doesn't vanish. It carries forward to a later tax year, per the same CRA policy. That matters for a shop that gets paid a large deposit early and does most of the technical work in a later fiscal period — the reduction follows the money across years, not just within one.
What your dev shop can still claim outright
Work you fund yourself — building your own internal tooling, frameworks, or platform rather than a specific client deliverable — isn't touched by the contract-payment reduction at all, because there's no contract payment attached to it.
Most agencies have some version of this even if they've never labeled it: the internal component library every client project reuses, the custom build pipeline nobody bills a client for directly, the proprietary testing harness built because the team was tired of solving the same problem project after project. None of that carries a client invoice that could qualify as a contract payment against it. It's evaluated exactly the way any company's SR&ED work is: does it clear the two-part test — genuine technological uncertainty, resolved through systematic investigation — regardless of who's paying for the salaries behind it. If you're not sure what clears that bar in the first place, we've covered the test itself separately.
There's a practical implication here that agencies underuse. A shop that treats every hour as billable client time has nothing left in this bucket. A shop that deliberately carves out a slice of engineering time for its own tools and IP — even a modest slice — keeps a claim that doesn't depend on how any single client contract gets classified.
The four factors that decide if a payment even counts as a contract payment
Not every client invoice is a "contract payment" in the CRA's sense, and the label on your invoice doesn't decide it — the substance of the arrangement does. Four factors carry the weight: whether the contractor was required to perform specific SR&ED work, whether a ceiling price shifted cost risk onto the contractor, who ends up owning the resulting IP, and whether the deal reads as a contract for services or a sale of goods. None of them is conclusive by itself.
Structure matters more than most agencies realize when they're negotiating a statement of work. A fixed-price, deliverable-based contract where the client owns the resulting code looks a lot like a contract payment: specific scope, cost risk on the agency, IP flowing to the client. A loose time-and-materials retainer with no defined deliverable, where the agency retains rights to what it builds and simply bills hours as they're worked, sits much closer to ordinary services revenue than to a contract payment for SR&ED performed on someone's behalf. Two engagements that look identical on an invoice can land on opposite sides of this line depending on how the underlying agreement is actually written.
This is where the framing question changes for an agency: instead of asking "did we do R&D," ask "whose R&D was this under the contract we signed." The technical answer to the first question can be yes while the tax answer to the second still isn't your agency.
Sales teams at agencies rarely think about any of this when they're negotiating scope. A founder pushing for a fixed price to control budget risk, and a client pushing for full IP ownership because it's their product, are both making completely reasonable asks — and together they're also assembling a contract that reads as a textbook contract payment. None of that is a reason to negotiate differently. It's a reason to know, going in, which pool the resulting expenditures will land in.
The other side of the deal: what your client can claim
Flip to the client's side of the same contract, and the number that matters is 80%. Contract SR&ED and third-party payments are only 80% eligible for the investment tax credit when paid to an arm's-length contractor — a rule that's been in place since 2012 and wasn't touched by the 2026 Bill C-15 changes. Pay your dev shop $220,000 for a qualifying contract payment, and roughly $176,000 of that enters the client's qualified expenditure pool, not the full invoice.
So on a genuinely eligible piece of contracted R&D, the arithmetic usually looks like this: the client claims about 80% of what they paid, the agency's own pool for that project shrinks by the full payment received, and 20% of the value sits in neither party's claim at all. Neither side is being shortchanged by an error — that gap is just what falls out of applying the 80% rule and the pool reduction to the same dollar, and it's a normal result, not a sign something was filed wrong.
Where founders get this wrong: trying to double-claim
Agencies rarely get burned by misreading this rule. They get burned by ignoring it — billing a client for a contract deliverable, then also filing an SR&ED claim on the same expenditures without netting out the payment received. The rule says that credit belongs to the party paying for the work. Once the CRA lines up your claim against your client's, that's a straightforward overstatement, not a grey area anyone can argue their way out of.
There's also an anti-avoidance backstop worth knowing about if a client ever proposes routing a payment through a third party to dodge this treatment: subsection 127(25) of the Income Tax Act deems a payment routed through an intermediary to still be treated as a contract payment if avoiding that treatment was a main purpose of the structure. It's not a workaround. It's a rule written specifically to close that workaround.
For an agency running several client engagements at once, this is a documentation problem as much as a tax one. If your project tracking doesn't separate "work billed under a qualifying contract" from "work funded internally," you can't reliably tell which pool a given expenditure belongs in — and neither can whoever's preparing your claim.
When your agency might still be the right one to claim
Not every engagement fits the pattern above, and pretending otherwise doesn't help you. A few situations where the contract-payment reduction may not apply, or may apply more lightly than you'd assume:
- Loose time-and-materials work with no fixed deliverable and no risk transfer. If your agency retains the IP, bills hourly with no ceiling price, and the client isn't dictating specific SR&ED objectives, the arrangement may not meet the substance test for a contract payment at all. That's a call worth getting right before you file, not after.
- R&D your agency does on spec, unbilled, hoping to win future work. If there's no payment attached to a specific project, there's no contract payment to net against it — ordinary eligibility rules apply.
- Internal product work running alongside client services. Plenty of dev shops are quietly becoming software companies on the side, building a tool they eventually productize. That work is evaluated on its own merits, completely separate from whatever contract-payment accounting applies to the client-billed side of the business.
None of these are loopholes. They're just situations where the four-factor test genuinely points the other way, and an agency that assumes every client dollar is a lost SR&ED dollar is leaving real claims on the table out of caution rather than accuracy.
Keeping the two pools straight
The operational fix is unglamorous: track which hours belong to which project, and which projects carry a contract payment against them, as the work happens rather than at tax time. An agency juggling six client engagements and a side project can't reconstruct that split eighteen months later from memory, and a claim built on a guess about which expenditures were already netted against a client payment is a claim that invites a CRA review it doesn't need to invite.
That's the specific gap Glauq is built to close for a services business. The evidence — who worked on what, for which client, under which contract terms — gets captured continuously from the tools your team already uses, project by project, instead of reconstructed from invoices after the fact, and none of it requires overhauling how your agency bills clients: it's tagging engineering time by project and contract type as it's logged, work that mostly already happens implicitly in a project-management or time-tracking tool. A qualified, independent SR&ED expert then reviews the claim before it's filed, including the contract-payment classification itself, and stands behind it if the CRA has questions. The fee is flat, not a percentage of your refund, which matters for an agency whose SR&ED-eligible expenditure pool moves around every time a contract's terms change.
Frequently asked questions
Can a software agency claim SR&ED for a client project? Sometimes, but only on whatever portion of the expenditures isn't offset by a contract payment received for that project. If the engagement qualifies as a contract payment under the CRA's four-factor test, the payment you received reduces your own pool for that project dollar for dollar, with any excess carried forward to a later year. Work you fund yourself, with no client payment attached, is unaffected.
Does my dev shop lose the SR&ED credit if a client pays for the work? Not entirely — the client's payment reduces your pool for that specific project, it doesn't zero out your whole claim. Any expenditure on the project beyond what the contract payment covers can still be pursued, and internal work you don't bill to any client isn't touched by this rule at all.
What's the difference between a fixed-price contract and time-and-materials, for this rule? The CRA weighs whether a ceiling price shifted cost risk onto the contractor, who owns the resulting IP, and whether specific SR&ED work was required, among other factors. A fixed-price, deliverable-based, client-IP-owned engagement tends to read as a contract payment. A loose hourly retainer with no defined deliverable and agency-retained IP tends not to. None of the factors is conclusive alone — the substance of the actual agreement decides it.
Can both my agency and my client claim SR&ED on the same work? No. The contract-payment rule exists specifically to prevent that: the payment received reduces the performing agency's own expenditure pool so the same dollar of R&D spend isn't credited twice. Filing your own claim without netting out a contract payment your client already accounted for is an overstatement, not a grey area.
Does building our own internal tools count if we're primarily a contract dev shop? Yes, evaluated the same way any company's SR&ED work is. Whether you're a five-person agency or a fifty-person consultancy, unbilled internal work — your own build pipeline, component library, or a product you're developing on the side — runs through the ordinary two-part eligibility test with no contract payment to net against it.
How much of what our client pays us do they actually get to claim? Generally about 80% of the amount that qualifies as a contract payment, per the CRA's contractor rule, assuming the payment is to an arm's-length supplier for SR&ED performed on the client's behalf. That's worth knowing on your side of the table too — it shapes what a client can reasonably expect back from the engagement.
The technical work and the tax claim aren't the same thing, and for a dev shop billing multiple clients, conflating them is the single easiest way to overstate — or underclaim — what the program actually owes you. Separate the pools while the work is happening, and the claim writes itself instead of getting reconstructed from old invoices.
See what your claim could be worth — estimate your refund or check your eligibility.