SR&ED for custom software development can help pay for part of your build, but only part of the work, and only if you plan for it. If you're a Canadian business about to commission a portal, an internal tool or a SaaS product, most of what decides whether an SR&ED claim holds up happens before the first line of code: how the project is scoped, how the contract is worded, and where the work is done.
This guide is for the person paying for the build, not the tax specialist. It covers what kinds of custom software work can qualify for SR&ED, who can claim when an agency writes the code, how the 80% contractor rule works, and how a sprint-based build can produce the records your accountant will need.
A quick disclaimer: Eskore builds software. We don't give tax advice and we don't prepare SR&ED claims. Before you claim, confirm eligibility, rates and filing requirements with CRA guidance on canada.ca and a qualified SR&ED accountant.
Does Custom Software Development Qualify for SR&ED?
Yes, custom software can qualify for SR&ED. Being custom, expensive or technically complicated isn't enough. The work has to involve three things:
- Technological uncertainty. A problem your team couldn't solve with standard practice.
- Systematic investigation. A structured attempt to solve that problem.
- Technological advancement. New technical knowledge that comes out of the work.
Most software projects contain a lot of routine work and, sometimes, a smaller core of experimental work. Only the experimental core is SR&ED.
SR&ED is also a tax incentive, not an upfront grant. You pay for the build, file your claim with your tax return, and recover a portion afterwards. It can improve the economics of a project, but it won't fund the first invoice. If you need money up front, see our guide to funding for custom software development in Canada and our overview of what replaced CDAP.
What SR&ED Is (and Isn't)
SR&ED stands for Scientific Research and Experimental Development. It's Canada's main R&D tax incentive program. It offsets eligible R&D spending, including certain salaries, materials and arm's-length contractor costs. The money comes back as investment tax credits (ITCs). Some of those credits are refundable, particularly for Canadian-controlled private corporations (CCPCs), which are private companies controlled by Canadian residents.
For a sense of scale, Chrono Innovation reports that the CRA processed 22,758 claims and approved $4.5 billion in credits in 2024–25.
SR&ED is not a pre-approved pot of money, and it doesn't pay for routine product work. Timing also matters. Corporations generally have 18 months after fiscal year-end to file a claim, and as sred.ca notes, the CRA very rarely accepts late ones. If your build spans two fiscal years, you may have work in two claim periods.
The Three SR&ED Tests for Software Work
This is where buyers most often get confused. A project can be hard, slow and expensive without containing any SR&ED. These three tests separate normal delivery from genuine experimentation.
1. Technological uncertainty
Uncertainty means a competent team couldn't solve the problem using standard practice, known design patterns, vendor documentation or routine engineering. The question isn't "was this hard?" It's "did we know how to do this when we started?"
Examples that may meet the test:
- A scheduling engine that has to produce valid schedules for thousands of resources within a strict response time, where known algorithms and libraries don't meet the constraint.
- An integration with an unreliable legacy system where you need guaranteed data integrity, but the old system drops, duplicates or reorders records in undocumented ways.
- A performance ceiling that the chosen frameworks don't handle out of the box, with no documented fix.
Ryan's write-up of a Tax Court case on IT development is worth reading with your accountant. The case involved a common web stack (React, Redux, Styled Components), and it shows how closely the court examines whether a problem went beyond routine engineering.
2. Systematic investigation
The team has to work the problem methodically: form a hypothesis, try alternatives, record results and adjust based on evidence. Trial and error with nothing written down doesn't count.
Agile development fits this well if the team is disciplined. Useful evidence includes:
- a technical spike with a stated question
- benchmark logs comparing approaches
- pull requests that show an abandoned approach and why it was dropped
- sprint demo notes recording what worked
3. Technological advancement
The work has to produce new technical knowledge for your company, even if the end product is commercial. The advancement doesn't need to be new to the world. It does need to go beyond configuring or implementing something already known.
Failure can still count. If you learned that three approaches can't meet a latency target, and why, that is knowledge.
Which Custom Software Projects May Qualify for SR&ED
Most projects contain both kinds of work. Here's how that tends to look across the builds we see most often.
Internal tools and workflow automation
- May qualify: A planning or routing engine where existing algorithms fail under your real-world constraints, such as mixed vehicle capacities, time windows and live changes. The team has to experiment to get usable results.
- Usually routine: Replacing spreadsheets with standard screens for creating, editing and reporting on records. This can be very valuable to the business, as in many CRM and ERP builds, and still contain no SR&ED.
Customer portals and SaaS products
- May qualify: Concurrency, data synchronisation or performance problems that standard architecture doesn't solve. Offline-first sync with conflict resolution across unreliable connections is one example.
- Usually routine: Login, billing, basic dashboards, notification templates and normal UI polish.
For budgeting the routine parts, see our breakdown of customer portal development cost in Canada.
Web and mobile apps
The same three tests apply to web development and mobile app development. An app isn't SR&ED just because it's an app.
- May qualify: A technical problem the standard frameworks don't solve, such as the sync and performance examples above.
- Usually routine: Standard screens, forms, navigation and visual polish built with known tools.
APIs, integrations and legacy modernisation
- May qualify: Working around undocumented legacy behaviour, inconsistent data structures or scale limits, where no documentation exists and the team has to investigate experimentally.
- Usually routine: Using a documented API exactly as the vendor intended.
AI, machine learning and automation
AI and ML work can qualify when there's real technical uncertainty. Examples include getting a model to perform reliably on messy domain data, or hitting accuracy and latency targets at the same time.
Advisors are reporting closer CRA scrutiny of AI/ML claims. Chrono Innovation's commentary is one example. The scrutiny is heaviest where the work is mostly model use, prompting or implementation rather than resolving a technical uncertainty. Calling a large language model through its API, writing prompts or wiring up a no-code workflow usually won't qualify on its own.
If you're exploring AI automation projects with real technical constraints, raise SR&ED early. That way the experimental parts are scoped and documented as experiments from the start.
What Usually Doesn't Qualify
sred.ca is blunt about this, and we agree. These items normally don't qualify on their own:
- routine feature development using known patterns
- UX/UI design and visual polish
- standard CMS or SaaS configuration
- integrations that follow vendor documentation
- routine debugging and QA
- data migration using known methods
- basic reporting dashboards
- project management, meetings and admin
Most of this will be part of the same build, and good UI/UX design is still worth paying for. It just shouldn't be counted as SR&ED unless it directly supports the experimental work. A claim that labels the whole project as R&D is weaker than one that clearly separates the two.
Hiring a Development Agency: Who Claims SR&ED?
This is the part most guides skip, and it matters most to a buyer. (If you're still choosing a partner, our guide to choosing a custom software developer for your small business covers the wider hiring questions.)
As a rule, the same SR&ED work can't be claimed twice. Generally, either you claim the contract payments as the client, or the agency claims its own costs as the performer, not both. Which way it goes depends on the facts and the contract:
- whether the agency is performing SR&ED on your behalf
- who owns the resulting work
- who bears the financial and technical risk
- where the work is performed
- who has the right to exploit the results
The details are more technical than this list suggests. Your ability to include contractor payments depends on whether the contract is for SR&ED performed on your behalf and whether you're entitled to exploit the results. The contractor may also face separate tax consequences, including reductions to its own qualified expenditures. Your accountant should review the contract with this in mind.
Settle all of this in writing before the build starts. Trying to sort it out after the invoices are paid, or worse, at tax time, is how claims fall apart.
The 80% contractor rule in plain English
When an arm's-length contractor performs eligible SR&ED work on your behalf, you can generally include 80% of the eligible portion of the contract amount in your claim. Chrono's contractor guide gives a simple version: if you pay an agency $100,000 for work that qualifies as SR&ED, you include $80,000.
The point buyers miss is that the 80% applies to the eligible portion, not to every invoice. If the eligible work on a $100,000 contract is worth $40,000, the starting figure is $32,000, not $80,000. Your accountant will confirm the treatment for your situation.
IP ownership and contract wording
GrowWise Partners says the contract should state that your company owns the resulting intellectual property, or at minimum has an exclusive, unencumbered right to exploit the results. If the agency keeps the IP and resells it, your claim is weaker.
We work from a written scope and a fixed price, and both help with budgeting and clarity. A fixed price doesn't, by itself, make the work claimable by you, though. A fixed-price arrangement can even suggest the agency carries the delivery risk if it isn't drafted carefully. If SR&ED is in play, the statement of work should separately identify:
- the experimental work
- your IP ownership and exploitation rights
- where each part of the work is performed
- whether the agency is performing SR&ED on your behalf
If you want custom software development with a written scope and sprint demos, those documents give your accountant a clear starting point. Have them review the contract wording before you sign.
Offshore work: location matters
SR&ED is a Canadian program, and the work generally has to be performed in Canada. For contractor work, the contractor should be a Canadian taxable supplier performing the SR&ED work in Canada on your behalf.
We're upfront about this because it affects us. Eskore has teams in Toronto, New York and Karachi. Work done in New York or Karachi should not be assumed to count toward a Canadian SR&ED claim. Only consider qualifying work performed in Canada, unless a tax professional confirms that a specific exception applies.
If SR&ED matters to your project, tell your development partner during scoping. The contract and timesheets should show clearly where each piece of work was done. Offshore teams can be the right commercial choice. Just don't count their work toward a Canadian claim.
Worked Example: SR&ED on a $250,000 Build
This is a simplified hypothetical, not a promise of what any project will return.
A Canadian company pays an arm's-length Canadian contractor $250,000 to build a custom operations system. After a technical review, roughly 60% of the work is considered potentially eligible SR&ED, covering the optimisation engine and a difficult legacy integration. The other 40% is screens, reporting, authentication and polish.
| Step | Amount |
|---|---|
| Total contract | $250,000 |
| Potentially eligible portion (60%) | $150,000 |
| Contractor inclusion (80% of eligible) | $120,000 |
| Simplest-case federal ITC at 35% (eligible CCPC) | ≈ $42,000 |
In the simplest case, the maximum federal ITC calculation comes to about $42,000. That figure is before provincial credits, and before any limits, reductions, phase-outs or CRA review. The real number depends on your company's status, your other SR&ED spending and your accountant's assessment. Provincial credits vary, so confirm them separately.
What Changed for SR&ED in 2026
The main recent change is Bill C-15, which implements SR&ED measures from the November 4, 2025 federal budget. The Library of Parliament's legislative summary is the most authoritative source we can point to. Lexology's overview and other legal commentary report that the bill received Royal Assent on March 26, 2026.
Based on those sources, the enacted federal changes include:
- Enhanced expenditure limit raised from $3 million to $6 million, for tax years starting on or after December 16, 2024.
- Maximum refundable federal credit for eligible CCPCs raised from $1.05 million to $2.1 million.
- Phase-out: the limit starts shrinking when taxable capital employed in Canada exceeds $15 million and is fully phased out at $75 million. Companies can elect to use a revenue-based phase-out instead.
- Capital expenditures: eligibility for certain capital expenditures has been restored.
- Eligible Canadian public corporations may access a $6 million expenditure limit, subject to a phase-out based on average annual revenue.
For most small and mid-sized software buyers, the practical effect is more headroom: a project that might once have hit the cap may now fit within it. How these rules apply depends on your tax year, corporate status and CRA administrative guidance, which can lag legislation. Confirm the current limits on canada.ca and with your accountant before relying on any figure here.
Can You Check SR&ED Eligibility Before You Build?
Possibly, but treat any early check as guidance, not a guarantee.
The CRA has offered a pre-claim service for SR&ED. helloDarwin's program summary describes it as covering up to three projects, with each result valid for up to three years. We haven't confirmed the current program name, terms or legal effect directly with the CRA. Read the CRA's own SR&ED pages on canada.ca, or ask your accountant, before relying on it.
Even where an early review is available, it's useful guidance. It doesn't replace filing a complete, well-documented claim, and it doesn't guarantee acceptance unless the CRA expressly says so.
It's still worth raising during discovery, especially for larger or technically risky builds. If you're deciding between building, buying or delaying, technology and funding planning before a build helps you find where the real technical uncertainty sits before you commit to a scope.
Records to Keep During a Custom Software Build
Every SR&ED guide tells you to "document contemporaneously." Here's what that looks like on a real build.
Before development starts
Write down, in plain language:
- the business goal
- the technical uncertainty: what you don't yet know how to do
- known approaches already considered, and why they may fall short
- the main technical risks
- IP ownership and exploitation rights
- who expects to claim SR&ED, and on what basis
- where each part of the work will be performed
- which milestones are likely to involve experimentation
During each sprint
For the experimental work, keep:
- tickets that state a hypothesis, not just a task ("Can approach B keep response under 300 ms at 10,000 records?")
- the alternatives tested and the constraints that applied
- benchmark results, including the bad ones
- failed attempts and why they were dropped
- code review notes and architecture decisions
- demo notes
- time allocation, split between experimental and routine work
Records made at the time are far stronger than a story reconstructed 14 months later from memory and Git history. If your partner already runs short sprints with demos, most of this comes down to tagging and discipline rather than extra work.
At launch and tax time
Hand your accountant:
- the final scope and contract
- invoices
- sprint records and technical summaries
- evidence of where work was performed in Canada
- contractor details
- IP and exploitation terms
- a clear split between routine delivery and experimental work
How Eskore Runs SR&ED-Friendly Software Projects
We don't prepare SR&ED claims. We run projects so the technical work is easy to understand: for you, for your accountant, and for a CRA reviewer if it comes to that.
Every engagement starts with a written scope, a fixed price and a realistic launch date. We ship working software every sprint and demo it. We build around your actual workflow rather than forcing it into a template.
Typical deliverables are internal tools, customer portals, SaaS products, admin dashboards, APIs, integrations and legacy modernisation. Our usual stack is Next.js, React, Node.js, TypeScript, Laravel or Python, with PostgreSQL, Redis and Docker underneath.
If SR&ED is in play, here's what we'll do:
- Flag the parts of the build that look experimental.
- Structure tickets and spikes so hypotheses and results are recorded.
- Be explicit in the statement of work about the experimental scope, IP and where each part of the work is done, so your accountant can review it before signing.
You can see how we work in our custom software case studies.
For US Companies: SR&ED Is Canada-Only
US readers: SR&ED is a Canadian tax incentive. US companies should ask their tax advisor about the US federal R&D tax credit and any state-level incentives. If you're considering Canadian operations partly for SR&ED, get tax and legal advice on structure first, and don't assume a new Canadian entity will qualify. We can help with US and Canadian company formation support, but whether you qualify for a tax credit is a question for your tax advisor.
Bottom Line: Plan SR&ED Before the First Sprint
The most common mistake with SR&ED on custom software development is building first and asking about the claim later. By then, the contract may give the IP to the agency, the work may have been done outside Canada, and nobody recorded what was tried and why it failed.
Do it in this order:
- Identify real technological uncertainty during discovery.
- Get the contract right on IP, exploitation rights, risk and who claims.
- Confirm which work happens in Canada.
- Document experiments as they happen.
- Bring your accountant in early.
If you're planning a custom software build and want to know which parts might be worth an SR&ED review by your accountant, book a free 30-minute scoping call. We'll map the project, show where the technical risk sits, and give you a written scope you can take to your accountant.
