What counts as support work in an SR&ED project?

Support work can qualify for SR&ED when it directly helps an eligible investigation and the effort matches what that investigation needs. Working on the same product is not enough.

Consider a hypothetical software team. On Tuesday, a developer builds a tool to measure what happens during an experiment. On Wednesday, the same developer fixes a familiar checkout bug before release. Both tasks belong on the product roadmap. They may need different treatment in the SR&ED claim.

To explain the difference, start with what the team was trying to learn. The task name, department, and project code can only tell you so much.

Find the experiment inside the product project

Suppose the team is investigating how to keep transaction records consistent when parts of a distributed system lose contact. Existing technical knowledge cannot resolve the problem, so the team develops hypotheses and compares approaches through controlled experiments.

For this example, assume that investigation meets the SR&ED requirements. Difficulty alone would not establish eligibility.

The developer's measurement tool lets the team observe where the experimental approaches fail. Building it may qualify as support work, even if the tool uses familiar programming techniques. Fixing the unrelated checkout bug using a known solution serves the release rather than the investigation.

The CRA's project-grouping guidance draws this boundary between a business project and an SR&ED project. One product can contain eligible experimental work alongside routine development. The claim needs to show where each activity belongs.

What makes an activity support work?

The Income Tax Act's definition of SR&ED names eight possible categories: engineering, design, operations research, mathematical analysis, computer programming, data collection, testing, and psychological research.

That list tells you which kinds of work to consider. The next questions are whether the activity directly supported eligible basic research, applied research, or experimental development undertaken in Canada, and whether its scale was appropriate.

In the software example, ask what the measurement tool enabled the team to observe. A clear connection to the experiment helps explain direct support. Saying that the tool made the developers more productive is too general.

Then ask how much of the tool the experiment needed. If the developer also added features for a future commercial dashboard, those features need a separate assessment.

The law calls this second requirement "commensurate with the needs." In plain language, the amount and duration of the support work must match what the investigation required. The CRA's eligibility guidelines explain why support work cannot qualify on its own.

The purpose of testing and data collection matters

A time entry that says "testing" leaves a lot unanswered. Was someone comparing experimental approaches, or checking that the finished product met known specifications?

In our hypothetical project, controlled test loads could help reveal why transaction records diverge. Those tests may support the investigation. Routine regression testing before the next release has a different purpose, even if the same developer runs it.

Data collection needs the same attention. Measurements gathered specifically for the experiment may qualify. Normal operational logs do not become eligible collection work simply because someone later finds them useful for research. The CRA makes this distinction explicit in its current eligibility guidance.

Engineering and design follow the same reasoning. A fixture designed to hold a prototype during an experiment may support the investigation. Standard production drawings prepared after the uncertainty is resolved need separate treatment. Necessary commercial work can still fall outside SR&ED.

Give the reviewer something better than a task label

For the measurement tool, an illustrative record might read:

Built a logging tool for the transaction-consistency experiments. The tool recorded the sequence of updates during controlled connection failures so the team could compare the experimental approaches. The linked issue, code changes, and test results show the work performed.

That explanation makes the connection visible. It still needs dates, a reasonable time allocation, and actual source records behind it. Writing a persuasive description after the fact does not establish that the work occurred.

Compare it with "software development for the new platform." That description gives a reviewer very little basis for separating the experiment from the release work.

There is no need to rename every task with tax terminology. Keep the team's ordinary language and explain how the task helped investigate the technical question.

Separate the person's activities before allocating their time

An employee can move between experimental work and ordinary operations during the same week. Review the activities before assigning a percentage of their salary to the claim.

The CRA's salary or wages policy bases directly engaged work on what the person does. A manager's technical input into ongoing experiments may qualify; budgeting or scheduling does not qualify as directly engaged work just because it relates to that project.

Keep the allocation method and the records that let another reviewer check it. Timesheets can help, but other supporting records may also matter. The financial treatment needs its own review after the eligible activities have been identified.

Start with one activity that is hard to classify

Choose a task whose treatment is unclear and put its records together. A useful review note should answer:

• What investigation did this task support?
• What did the task enable the team to do or learn?
• Which support-work category does it fit?
• Why did the investigation need this amount of work?
• Where are the dated records and the basis for the time or cost allocation?

For the developer's measurement tool, that might mean connecting the experiment plan to an issue, the code changes, and the resulting test output. Keep unrelated dashboard features visible so the reviewer can assess them separately.

Resolve that connection while the people who did the work can still explain it. A task that is unclear now will be harder to reconstruct at filing time.

Frequently asked questions

Does the support task itself have to be experimental?

It may use familiar techniques. What matters is whether it fits a listed category, directly supports underlying eligible SR&ED, and matches that work's needs.

Can we claim every task needed to finish an experimental product?

No. Commercial production, routine testing, and other excluded activities remain outside the definition. A product project can include both eligible and ineligible work.

Does project management count as support work?

Project management is not one of the eight categories. A manager's technical contribution may qualify under the relevant rules, but the project-management label alone does not establish eligibility.

What if the same tool supports experiments and normal operations?

Identify the work that served the eligible investigation and explain the allocation. Shared use does not establish that all development or operating effort qualifies.

Sources reviewed September 10, 2026.