SR&ED Tax Credit for App Development: What Qualifies, What Doesn’t, and How to Structure Work with a Dev Partner in 2026

Yes, the SR&ED tax credit for app development is real. Parts of a mobile app build can qualify for SR&ED, Canada's Scientific Research and Experimental Development tax credit. Usually it's only parts, and often a smaller share than founders hope. This guide covers what app development work qualifies for SR&ED, what doesn't, and how to structure work with a development partner so a claim stays possible.

Quick answer: can app development qualify for SR&ED?

App work can qualify when three things are true:

• Your team faced a real technical problem it couldn't solve with standard knowledge.
• You worked through it with planned experiments.
• You came out the other side knowing something new.

That is the CRA's three-part test: technological uncertainty, systematic investigation and technological advancement. Each project in a claim must meet all three.

Most of what goes into a typical app does not meet that bar. Login flows, profile screens, standard API integrations, Stripe or in-app subscriptions, and patterns implemented straight from the docs are routine development. They're valuable, but they aren't SR&ED.

At a glance

May qualify: work that resolves a genuine technical uncertainty through documented experiments. Examples include conflict-heavy offline sync, custom native bridges that work around an OS limitation, and on-device ML under tight memory or latency constraints.

Usually doesn't qualify: login and profiles, CRUD screens, Firebase or Supabase setup, payments and subscriptions, basic push notifications, analytics, visual design, App Store submission and routine bug fixing.

Ask your advisor before signing: who claims when an agency builds the app, how work done outside Canada is treated, what the contract says about IP and risk, and which limits apply to your taxation year.

A necessary disclaimer: Eskore builds apps. We are not SR&ED tax advisors, and nothing here is tax advice. Use this guide to ask better questions. Then confirm eligibility, contract treatment and filing details with an SR&ED accountant or consultant, ideally before you sign a development agreement.

SR&ED is not a discount on every app build

Owners budgeting a project sometimes assume they'll get a fixed percentage of the whole invoice back. The program doesn't work that way.

SR&ED rewards eligible experimental work. Having an app, a startup idea or a long list of custom features doesn't earn anything by itself. The CRA assesses the technical work and the records behind it. The commercial value of the product doesn't enter into it.

That produces some counterintuitive results:

• A clever marketplace built entirely on proven tech may have no eligible work.
• A plain internal field-service app that had to solve a nasty offline data-conflict problem might have some.

Budget the build on its own merits and treat SR&ED as a possible later offset, not a funding source you can count on. If you're weighing SR&ED alongside grants and other programs, start with our guides to funding for custom software development in Canada and what replaced CDAP. Our technology and funding roadmap work can help you sequence them.

The three-part SR&ED test for mobile apps

1. Technological uncertainty

You had a technical problem that couldn't be resolved using standard practice and the knowledge reasonably available to a competent team. "We hadn't built this before" doesn't meet the test. "We didn't know whether this approach would work, or how to make it work" does.

App examples that can involve real uncertainty:

• Offline sync where many users edit the same records and conflicts must resolve correctly at scale
• Unusual device or OS constraints, such as keeping a process alive within iOS background limits
• A custom native bridge in React Native or Flutter where the documented approach fails
• On-device processing that hits memory, battery or latency limits on real hardware

CRA training material offers a useful counterpoint. It uses a mobile push-notification example to show that the absence of a capability does not equate to a technological uncertainty. If your app couldn't send notifications before and now it can, you've added a feature. You haven't run an experiment.

2. Systematic investigation

You formed hypotheses, tested them in a planned way, recorded what happened and adjusted. Trial and error without records doesn't count.

This fits agile work well, as long as your tools capture it. Sprint tickets, branches, test logs and short technical notes can tell the story if they record the uncertainty, the experiment and the result. A Jira ticket titled "Fix sync" doesn't do that.

3. Technological advancement

The work produced new technical knowledge for your company. It doesn't need to be a patent or a public breakthrough.

Learning that an approach doesn't work can also count, if you investigated it properly. A documented failed prototype is evidence. An undocumented one is a lost week.

What app development work qualifies for SR&ED (and what doesn't)

App work	Likely SR&ED position	What makes it stronger / weaker	Records to keep
Offline-first sync with conflict resolution	Possible	Stronger: novel conflict cases, scale limits, failed approaches. Weaker: using a sync library as documented	Design notes, test matrices, failed branches, conflict logs
Custom native module or bridge (React Native, Flutter)	Possible	Stronger: documented OS limitation, multiple approaches tested. Weaker: wrapping a known SDK	Benchmarks, device/OS matrix, PRs, crash logs
Background processing on iOS/Android	Possible	Stronger: working around platform constraints with no known solution. Weaker: standard background fetch	Test plans, battery and timing measurements
On-device ML or AI features	Possible	Stronger: latency, accuracy or privacy constraints that need experimentation. Weaker: calling a hosted API	Evaluation results, model comparisons
Real-time data at high volume	Possible	Stronger: measured limits, architectures tested and rejected. Weaker: standard WebSocket setup	Load test results, architecture decision records
Payments and subscriptions (Stripe, RevenueCat, in-app)	Usually not	Routine integration	Normal project records
Push notifications	Usually not	Routine unless a genuine delivery or OS constraint is investigated	Normal project records
Firebase or Supabase backend setup	Usually not	Standard configuration	Normal project records
Analytics, App Store submission, visual design	Not	Not technological experimentation	No SR&ED-specific records usually needed; keep normal project and accounting records

Examples that may qualify

• Conflict-heavy offline-first sync. Field teams edit shared records without connectivity, last-write-wins would corrupt data, and no off-the-shelf approach handled your conflict types.
• Custom native bridges. Checkpoint Research points to custom native bridges for cross-platform apps as potential SR&ED work, when the bridge solves an actual platform limitation.
• Unusual background-processing constraints. The OS kills continuous sensor capture or location logging, and your team had to test several strategies to keep it running.
• On-device ML or AI. You need to run inference on mid-range phones within latency and memory limits.
• High-scale real-time data handling. For live tracking or streaming, you measured where your architecture broke and tested alternatives.
• Security or encryption beyond routine. One example is end-to-end encrypted sync with key recovery, under constraints that standard libraries didn't address.
• Performance on low-end devices or unreliable networks. You ran benchmarked experiments to make the app usable on older Android hardware or patchy rural connections.

Examples that usually do not qualify

• Login, sign-up and profile screens
• CRUD dashboards and admin panels
• Standard Firebase or Supabase setup, auth and storage
• Routine payment and subscription integration
• Basic push notifications
• Standard Expo, React Native or Flutter implementation
• Visual design and UI polish. Good UI/UX design matters, but it isn't SR&ED.
• App Store and Google Play submission
• Analytics setup
• Routine bug fixing. Debugging can be eligible, but only when it's part of a documented experiment to resolve a technological uncertainty.
• Copying established patterns from documentation or tutorials

React Native, Flutter and Expo: does the stack matter?

No. The framework doesn't make a project eligible or ineligible. The technical uncertainty and the documented experimentation do.

A routine cross-platform build in Expo, React Native or Flutter is very likely not eligible, however polished the result. Now suppose the same project needs a custom native bridge because the OS blocks something you need, and your team tests several approaches and records the results. That workstream may be eligible. (For more on choosing a stack and partner, see our guide to cross-platform app development in Canada.)

Using Expo, Firebase or Supabase doesn't count for or against you. They're tools. When we scope a build with our mobile app development team, we flag early which parts are routine and which carry real technical risk. That's also the point where any SR&ED conversation should start.

Can AI, LLM or machine-learning app features qualify?

Adding a chatbot through the ChatGPT API, or plugging in an off-the-shelf model, is usually routine integration. SR&ED advisors are reporting closer review of AI and ML claims, so expect to document the technical uncertainty carefully.

Eligibility becomes possible when the team has to experiment under real technical constraints:

• Getting acceptable latency on-device or over poor networks
• Keeping sensitive data on the phone for privacy reasons
• Building evaluation methods for domain-specific accuracy
• Testing controls that reduce hallucinations in a regulated context

If you're exploring AI automation and app features, decide early whether the AI part is a product feature built on known tools or an open technical problem. If it's an open problem, document it as you work on it.

Who claims SR&ED when an agency builds your app?

Most SR&ED guides skip this part, and it's where buyers get caught out.

The claimant isn't determined by the invoice alone. When an outside partner builds your app, the answer depends on several factors:

• The contract, and who has rights to the results
• Who pays for the work, and who bears the financial risk if experiments fail
• Where the work is performed
• Who owns the IP
• Whether the parties are at arm's length
• The CRA's contract-payment rules and the legislation in force for your taxation year

There's no universal answer, and we won't pretend to give you one. If you expect to claim, bring an SR&ED advisor in before you sign the build agreement. Fixing contract language afterwards is much harder.

The Canada-only rule: separate Canadian and offshore work

SR&ED is designed for work carried on in Canada. In most app-agency arrangements, work performed by non-Canadian teams should be kept separate and should not be assumed eligible. There are detailed rules and limited exceptions, and your SR&ED advisor should review them for your situation.

This applies directly to us. Eskore has teams in Toronto, New York and Karachi. Work done by our Karachi-based developers needs to be separated from any potentially eligible Canadian work, and the same goes for New York. If a project might include SR&ED work, we can staff the experimental workstream in Canada and track hours by person and location. Your advisor then gets clean numbers instead of a blended invoice.

Contract payments, IP and financial risk

When an arm's-length contractor does experimental work for you, your advisor will look at questions like these:

• Who bears the cost and the risk if the experiment fails?
• Who owns the resulting IP?
• Are you entitled to the results and allowed to use them?
• Is the contractor also trying to claim the same work?

Contract payments have their own treatment under the SR&ED rules. The amount that counts may not be the full invoice. Provincial rules also differ. Your advisor should review the contract, the rights to results, the risk allocation and the current CRA contract-payment rules before the work starts.

How to structure the project before sprint one

1. Split the scope. Identify possible SR&ED work packages separately from routine build work in the statement of work.
2. State where work will be performed, by workstream.
3. Clarify IP ownership and your rights to use the results.
4. Agree on documentation expectations: what gets written, by whom and how often.
5. Tag experimental tickets from day one.
6. Track time by person, location and workstream.
7. Have your SR&ED accountant review the contract before anyone signs.

SR&ED tax credit rates and limits for app development in 2026

The federal program has long had two tiers:

• Enhanced credit (35%, refundable) for eligible Canadian-controlled private corporations (CCPCs), up to an annual expenditure limit
• General credit (15%, non-refundable) for other corporations, and for spending above the limit

Budget 2025 announced the biggest changes to the program in years. Practitioner summaries, such as this one from Boast, list four main changes:

• A higher expenditure limit for the enhanced credit
• Higher phase-out thresholds
• Renewed eligibility for capital expenditures
• Broader access to enhanced treatment for some public companies

SR&ED Education reports that the budget legislation has since received Royal Assent.

We're deliberately not quoting exact dollar limits, thresholds or effective dates. They depend on the enacted legislation and CRA guidance for your specific taxation year, and those calls belong to a tax professional. Bring these questions to your advisor:

• Which expenditure limit and phase-out thresholds apply to our taxation year?
• Is any capital spending on this project eligible, such as servers or test hardware?
• How will overhead be calculated: the prescribed proxy amount or the traditional method?
• What does our province add? Provincial credits stack on the federal credit and vary by province.

Simple app-build example

Say your app build costs $180,000 (for typical ranges, see how much an app costs for a small business in Toronto):

• $130,000 goes to routine product work: screens, auth, payments, push, backend setup and store launch.
• $50,000 goes to a hard offline-sync problem, performed in Canada and documented throughout.

Any claim starts from the $50,000 workstream, not the $180,000 invoice. The amount that counts may shrink further, depending on contract-payment treatment, overhead method and other adjustments. The CRA can also disagree with your view of eligibility. Your advisor runs the actual numbers. We don't, and you shouldn't budget around a refund figure until they have.

What records should app teams keep for SR&ED?

Create records during the build. Don't plan on reconstructing them months later from memory. Reconstructed claims are weaker and take longer to prepare.

Sprint records that help

• Jira or Linear tickets tagged uncertainty / experiment / result
• Sprint plans and retros
• Architecture decision records
• Git commits and branches, including abandoned ones
• Pull requests with technical discussion
• Test plans and test logs
• Failed prototypes
• Performance benchmarks
• Device and OS test matrices
• Error and crash logs
• Technical meeting notes
• Time entries by developer, location and workstream
• Screenshots or screen recordings of test behaviour

How to write the technical story for the T661

Part 2 of the T661 form is where the CRA reads your project description. Chrono Innovation's T661 guide puts it bluntly: write about the technical problem, not the product.

The three key lines map to the test:

• Line 242: the technological uncertainty you faced
• Line 244: the work you did to try to overcome it
• Line 246: the advancement, or what you learned

Compare two descriptions:

• "We built a marketplace app for contractors."
• "We couldn't reconcile concurrent offline edits to job records without data loss using available CRDT approaches. We tested three conflict models across 40 simulated devices…"

The first is a product story. The second is a technical story, and only the second helps your claim.

Agile sprints can qualify — if the uncertainty is traceable

The CRA does assess iterative work, so agile isn't the problem. The problem is that sprint records rarely say what was uncertain or what was learned.

Here is a typical ticket:

SYNC-112: Fix offline sync bug

Here is the same ticket, made SR&ED-ready:

SYNC-112 [Experiment] Uncertainty: Can field-level merging resolve concurrent edits to job records without losing technician notes, on devices offline for 8+ hours? Hypothesis: Per-field vector clocks will preserve both edits where timestamp-based merging drops one. Test: 40 simulated devices, 500 conflicting edits; compare data loss rate against the current approach. Result: (filled in at close, including failure)

Writing tickets this way adds a couple of minutes each. Over a quarter, those minutes give your advisor most of the raw material for the T661.

Deadlines, forms and the CRA pre-claim option

Corporations claim SR&ED using the T661 and Schedule 31 (T2SCH31). The filing deadline is a hard 18 months after your tax year-end. If you miss it, you lose the claim for that year.

SR&ED advisors, including Avinova, report that the CRA introduced an optional pre-claim approval process in 2026. It's intended to give some smaller businesses an eligibility determination before they file. We haven't confirmed the eligibility criteria or timing against CRA guidance, so treat it as a question for your advisor:

• Is it available to us?
• Which projects would we submit?
• Would the timing help before we commit budget to the experimental workstream?

For US companies: SR&ED is not the US R&D credit

SR&ED is a Canadian program. US companies should look separately at the federal R&D credit and the current rules for expensing or amortizing software and R&D costs. The two programs aren't interchangeable.

If a US company hires a Canadian team, or a Canadian company has US operations, you need professional tax advice in both countries. How the contract is structured affects both sides. If you also need to set up an entity on either side of the border, our LLC formation and filings team handles the registration paperwork. Tax treatment stays with your advisors.

How Eskore keeps app projects SR&ED claim-ready

We build cross-platform iOS and Android apps end to end: prototypes, backend and API work, payments and subscriptions, push and analytics, and store launch. When a project goes beyond a standard app, our custom software development team handles the harder backend and integration work. You can see the kind of projects we deliver in our case studies.

On the SR&ED side, our role is narrow and practical — we're not your accountant:

• We separate routine delivery from potentially experimental workstreams in the scope.
• Where a client intends to claim, we staff experimental work in Canada and log hours by person and location.
• We record uncertainty, experiments and results in tickets, PRs and architecture notes as we work.
• We coordinate with your SR&ED advisor, who makes the eligibility calls.

We can't guarantee that any work will qualify for the SR&ED tax credit for app development. What we can do is make sure the engineering records already exist if your advisor finds eligible work.

If you're planning an app and want a clear scope with clean technical documentation from sprint one, book a free 30-minute scoping call.