SR&ED Tax Credits for AI Development: A CPA's Guide

I built a SaaS product in 38 days using AI. Then I filed SR&ED tax credits on the work itself.

That sentence confuses most people. "SR&ED is for research labs and pharmaceutical companies. Not for a CPA building dashboards."

Wrong. SR&ED (Scientific Research and Experimental Development) is available to any Canadian-controlled private corporation that achieves technological advancement through systematic investigation. The key word is "advancement," not "laboratory."

I am going to walk through exactly how I approached the SR&ED filing on my own AI development work. Not theory. The actual process, with real examples from my build.

A note before we start: I am a CPA, but this post is not tax advice for your specific situation. SR&ED eligibility depends on the specifics of your project. Consult with a qualified SR&ED advisor for your filing. What I am sharing is my experience and my approach.

What SR&ED Actually Is

SR&ED is a Canadian federal tax incentive that provides investment tax credits (ITCs) for qualifying R&D activities. For Canadian-controlled private corporations (CCPCs), the enhanced credit rate is 35% on the first $3 million in qualifying expenditures. That rate drops to 15% above $3 million, but most small businesses are well under the threshold.

In simple terms: for every dollar you spend on qualifying R&D, you get 35 cents back as a refundable tax credit. "Refundable" is the key word. Even if your corporation has zero taxable income, even if you are running at a loss, you get cash back from the CRA. This is not a deduction that requires income to offset. It is a direct cash refund.

On salary expenditures, you can also claim a proxy amount for overhead. The proxy method lets you claim 55% of qualifying salary costs as overhead, without itemizing every supply and material. For a solo founder paying themselves a salary through a CCPC, this means your qualifying expenditure is salary times 1.55.

Run the numbers on that. If you pay yourself a reasonable salary and 30% of your time qualifies for SR&ED, the qualifying salary alone is meaningful. With the 55% proxy applied on top, the total qualifying expenditure grows further. At the 35% refundable rate, the result is real money returned to your corporation for work you were already doing.

Why AI Development Qualifies

The SR&ED criteria require three elements:

1. Technological uncertainty. You attempted something that could not be accomplished using standard practice or publicly available knowledge. You did not know at the outset whether it would work.

2. Systematic investigation. You followed a methodical approach: hypothesis, testing, analysis, conclusion. You documented what you tried, what failed, and what worked.

3. Technological advancement. You achieved new knowledge or capability that did not previously exist.

AI-powered business automation hits all three criteria when the work involves genuine investigation, not just applying well-documented techniques.

When I started building my dashboard system, there was real technological uncertainty across several dimensions:

Could an AI development workflow (Claude Code with CLAUDE.md persistence) reliably produce production-grade TypeScript software that compiles under strict mode across a 50+ file codebase? Nobody had published results on this for financial services applications.

Could a three-layer memory system maintain development context across 98 commits and 38 days without degradation? How many rules could the system accumulate before the AI started ignoring or contradicting them?

Could a non-developer direct AI to build a multi-tenant data transformation pipeline that accurately converts raw QuickBooks GL transactions into standardized financial metrics? The transformation requires handling multiple different chart of accounts configurations, multiple fiscal year start dates, and mixed currencies.

These are not rhetorical questions. I genuinely did not know the answers when I started. The investigation, testing, and resolution of these uncertainties is what makes the work potentially eligible for SR&ED.

What I Tracked

From day one, I built tracking into my development workflow. A pre-commit hook (a script that runs automatically every time I save code) captures every commit with metadata:

• Timestamp (to the minute)
• Files changed (specific list)
• Description of work performed
• Classification: experimental development, applied research, or standard engineering practice

Over the 38-day build, my tracking system logged every session. Four project categories. Timestamps, descriptions, and classifications, all captured contemporaneously.

This is critical. If you do not track your R&D activities as they happen, the CRA will challenge your claim. Reconstruction after the fact is a red flag. The CRA reviewer will ask: "How do I know you did not write this documentation after deciding to file?" If your tracking was automated and ran on every commit, that question answers itself.

I also maintained a learning log that captured what I tried, what failed, and what I changed. When the AI memory system started dropping rules after the ruleset exceeded a certain size, I logged the incident, documented the investigation (testing different memory architectures), and recorded the solution (three-layer system with auto-pruning). That documentation trail is exactly what SR&ED requires.

The Three-Part Test Applied to My Projects

Let me walk through how the SR&ED three-part test applies to specific parts of my build.

Project 1: AI Memory Persistence System

Technological Uncertainty: Can a three-layer memory system (permanent rules, active memory, session logs) maintain AI development context across hundreds of sessions without degradation? Specifically, will the AI follow accumulated rules consistently as the rule set grows? Will corrections made early in the project still be enforced months later?

Systematic Investigation: Built CLAUDE.md as layer one (permanent rules). Added MEMORY.md as layer two (active state). Added automated session logging as layer three (recent history). Tested rule adherence across sessions by deliberately triggering scenarios that had been corrected in earlier sessions. Measured drift and deviation over weeks. Identified a memory capacity issue where rules beyond a certain count were inconsistently followed. Implemented auto-pruning and a priority system for rules.

Technological Advancement: Developed a documented methodology for maintaining AI development context that produces consistent output across extended multi-session projects (38 days, 98 commits). This methodology, including the specific architecture, pruning algorithms, and self-learning protocol, did not exist in publicly available documentation at the time of development.

Project 2: Financial Data Transformation Pipeline

Technological Uncertainty: Can an AI-assisted development process produce a data transformation layer that accurately converts raw QuickBooks General Ledger data into normalized financial metrics (EBITDA, gross margin by service line, AR aging buckets, vendor expense pivots, customer concentration percentages) with zero calculation errors across multiple different client configurations?

Systematic Investigation: Built the transformation layer incrementally. Tested against known QuickBooks exports where I had manually calculated the correct answers in Excel. Validated every calculated metric: revenue matched to the penny, COGS by service line required resolving account mapping ambiguities, gross margin calculation required handling negative values from credit memos correctly. Identified rounding errors when aggregating monthly data into quarterly summaries. Discovered fiscal year boundary issues for clients with non-calendar fiscal years. Resolved chart of account mapping inconsistencies where the same economic activity was coded differently across clients.

Technological Advancement: Produced a reusable, configurable transformation pipeline that converts arbitrary QuickBooks GL exports into standardized financial metrics with verified accuracy across multiple distinct client configurations. The pipeline handles mixed fiscal years, inconsistent account naming, and non-standard QBO report formats.

Project 3: Automated Deployment and Quality Assurance Pipeline

Technological Uncertainty: Can a bash-based deployment script handle the full production deployment lifecycle for a solo developer with no DevOps background? Specifically: build verification, test suite execution, lint checking, branch management, deployment monitoring, automated rollback on failure, and post-deployment smoke testing, all without human intervention or manual decision points?

Systematic Investigation: Built the script incrementally over one week. Tested failure scenarios: what happens when the build fails (script exits before merge), when lint fails (script exits with diagnostic), when Vercel deployment times out (script rolls back the merge automatically), when a smoke test fails post-deployment (script notifies but does not auto-rollback since the code compiled correctly). Each failure scenario required a different recovery strategy. The rollback mechanism required solving an unexpected problem: when rolling back a git merge, uncommitted changes from the failed build process could block the rollback.

Technological Advancement: A documented, tested, automated deployment pipeline that reduces deployment risk for a solo non-technical operator to near zero. The pipeline has been validated across 40+ production deployments with zero incidents after implementation.

How to Structure Your Own Claim

If you are building AI-powered tools for your business and want to explore SR&ED eligibility, here is the approach I recommend.

Step 1: Start tracking now. Do not wait until filing season. Build a logging system that captures what you work on, when, and what the uncertainty was. If you use Git, your commit history is already half the documentation. Supplement it with a time tracking system that classifies activities as experimental development, applied research, or routine engineering.

My tracking system was a pre-commit hook that runs automatically. You could use Toggl, Clockify, or even a spreadsheet. The format does not matter. Contemporaneous capture does.

Step 2: Identify the technological uncertainty. "I built a website" is not SR&ED. "I investigated whether an AI development workflow could produce a reliable multi-tenant data pipeline for financial services applications" is potentially SR&ED. The distinction is the uncertainty at the outset. Did you know it would work when you started? If yes, it is standard practice. If no, it might be SR&ED.

Step 3: Document your systematic investigation. What hypothesis did you test? What did you try? What failed? What did you learn? What did you change? Write this down as it happens, not after the fact. My learning log served this purpose: every time an approach failed, I documented the failure, the investigation, and the resolution.

Step 4: Quantify your expenditures. Salary (or reasonable shareholder salary in a CCPC), AI subscription costs (these may qualify as materials), contractor fees if applicable, and overhead via the proxy method (55% of salary). If you pay yourself a reasonable salary and 30% of your time qualifies, the numbers add up quickly at 35% refundable.

Step 5: Work with a qualified SR&ED advisor. I am a CPA, and I still recommend working with a specialist. SR&ED filing is its own discipline. The CRA reviewers are technical and detail-oriented. A good SR&ED consultant will help you frame your work in the language the CRA expects and defend the claim if selected for review.

Common Mistakes to Avoid

Mistake 1: Claiming everything. Not all development work is SR&ED. Building a standard login page is routine engineering. Investigating whether an AI-generated authentication system can handle row-level security across multiple client tenants with different permission models is potentially SR&ED. Be honest about the line. Overclaiming damages your credibility for future filings.

Mistake 2: Reconstructing documentation after the fact. The CRA specifically looks for contemporaneous records. If your project description reads like a polished narrative written months after the work, it will not hold up. Messy, real-time notes with timestamps are more credible than polished retrospective summaries.

Mistake 3: Confusing business uncertainty with technological uncertainty. "I did not know if customers would buy this" is business uncertainty, not SR&ED. "I did not know if the AI could generate accurate financial calculations" is technological uncertainty. SR&ED is about whether something can be built, not whether it will sell.

Mistake 4: Ignoring the opportunity entirely. Most small businesses that do qualifying work do not file SR&ED because they think it is "only for big companies." If you are a CCPC doing genuine experimental development, you are leaving money on the table. The $3M small business threshold means the enhanced 35% rate applies to the vast majority of independent practices and small firms. That is a meaningful amount for a business at any stage.

Need Help?

I evaluate SR&ED eligibility as part of my fractional CFO services. If you are building AI-powered tools and want to understand whether your work qualifies, book a call. I will give you an honest assessment, not a sales pitch.

Next step: browse the free small business tax deduction guide.