SR&ED for Agile Startups

Canada’s SR&ED Program

Part I: Basics

Key Pointsrefundable tax credit: partial reimbursement for money spent on technology R&D

not a grant: if you meet the criteria, you get the money

part of your corporate tax return

SO INCORPORATE ASAP (bconline.gov.bc.ca)

must file within 18 months of corporate year end

usually get paid 3 - 6 months after submission

Application

two parts to the application

- financial calculation of the tax credit

- report (proves eligibility)

supporting documentation (more about this later)

The ReportAlways in 3 parts:

1.Technological Advance• technology improvement

1.Technological Obstacles/Uncertainties• proof that the work isn’t “routine”

1.Work Done (“War Story”)• what you did to solve the problems• doesn‘t have to be successful

Tech. Advances• Performance improvements of any size

• Design and coding of a prototype

• Integration of software components

• Architectural improvements

• Framework extensions

• New or improved algorithms

• Any kind of reverse engineering

• Some types of factoring

Tech. Obstacles/Uncertainties

• Tech. Obstacles more important than Tech. Advances (TO implies TA)

• Ensures that work isn’t “routine” (subjective and personal)

• Hardest and most important part of the claim

• Developers forget problems

• Identify them at the beginning

Work Done

• Think high school science experiments

• More on this later

Part II: Not-So-Basics• Writing reports• Audits

Developer’s View

Product

feature1 feature2 feature3

Technology Stack

Developer’s View

Product

feature1 feature2 feature3

Technology Stack

where the important stuff happens

CRA’s View

Productfeature1 feature2 feature3

Technology Stack

where the important stuff happens

Tech. Obstacle1Tech. Obstacle2

CRA’s View

Productfeature1 feature2 feature3

Better Technology Stack

Reality

Productfeature1

feature2

feature3

Technology Stack

Tech. Obstacle2

Tech. Obstacle1

Reality doesn’t matter: report must conform to CRA’s expectations

Audita small percentage (10%?; 25%?) of claims are audited

delays refund; usually reduces refund

common (?) for first year companies

added scrutiny of reports

scrutiny of documentation

DocumentationNot submitted with claim; back-up for audit

Examples (more is better)

- time records (weekly or monthly)

- test plans/experiments

- source code (complete version history)

Documentation is CRA’s sword and your shield

More checked boxes lower chance of audit

Part III: What’s Changed

Software Startups Are Agile

• Less documentation

• Less time tracking

• More use of online tools (Jira, Pivotal, etc.)

• Daily “standups” replace more formal project meetings

CRA Is More Demanding• Fixation on “cheaters”

• Extra money for more audits

• More aggressive cost-recovery

• Probably trying to eliminate small claims

• Actively working to deny/reduce claims – usually citing “lack of documentation”

• Explicitly rejects agile methodologies

Part IV: Fight the Power

What to Focus on

• Time tracking against Tech. Obstacles

• Experiments

• Other stuff

Tech. Obstacles/Uncertainties• Components A & B were not designed to work

together.

• Will Component X perform adequately?

• There is insufficient technical documentation to determine if Component X is a good choice.

• Can I successfully integrate Component X into my existing framework?

• How will the system scale under load?

• No algorithm/tech exists that does what I need.

How to Find Tech. Obstacles

1. Ask about tech problems at standups

2. Things that take a long time

3. Map features to tech. obstacles

- common, but risky in audit

• Identify at project start

• OK to change/add tech. obstacles

• Document them somewhere

Time Tracking

• Need to assign developer time to each Tech. Obstacle

• Also have to record non-SR&ED time

• Use a spreadsheet or a tracking tool

• CRA can’t assess accuracy

Basic Time Sheetweekweek beginningbeginning SR&EDSR&ED non-SR&EDnon-SR&ED NotesNotes

Tech Obstacle 1Tech Obstacle 1 Tech Obstacle 2Tech Obstacle 2

12

10-Aug-09

2 17-Aug-09

324-Aug-09

4 31-Aug-09

5 7-Sep-09

6 14-Sep-09

One sheet per developerRequires 2 minutes/week

Tracking Tool

Tech. Obstacle 1

Tech. Obstacle 2

....

Non – SR&ED

Pick List Hours

• Require this for check-in

Experiments

CRA view: experiments are how TOs get resolved

•Developers don’t think this way, but often do

- explore alternatives

- decide what’s best based on testing

•What matters are the experiments

•Coding is “support work”

•Support work counts

How to Do ExperimentsJust like high school:

•Hypothesis (1 sentence)

•Description of experiment (1 sentence)

•Input data

•Test bed (code, framework, db, etc.)

•Results (Measure Something!)

•Analysis & Conclusions (1 sentence)

save everything!

The sentences are optional

Experimental Questions

Developers routinely ask questions that lead to CRA-type experiments:

•What’s the best way to implement this feature?

•What are the resource requirements for this feature?

•How will this feature impact performance?

Turning the Tables

Other Stuff

• quick and dirty is best

• the digital shoe box

• Tag emails or cc to SR&[email protected]

• record standups

• photograph whiteboards

• Etc.

Thanks!

Questions? [email protected]

Ineligible Work

• Developing/implementing a business process, work flow, game rules

• Simple UI changes

• Straightforward implementation of a known algorithm

• Some kinds of factoring

• Bug fixes on production code

• “reinventing the wheel”