SR&ED for AI and Machine Learning Companies

AI projects are fundamentally experimental — and that's exactly what CRA looks for. If your team is training models, tuning architectures, or solving inference problems that existing frameworks can't handle, you likely have a strong SR&ED claim. Here's what to document and how to avoid the most common mistakes.

Why AI work commonly qualifies

Machine learning is inherently iterative and uncertain. Choosing a model architecture, selecting training data, tuning hyperparameters, and optimizing inference pipelines all involve genuine technological uncertainty. CRA has consistently recognized that AI/ML development involving systematic investigation of technical unknowns is SR&ED-eligible.

AI and ML work that typically qualifies

• Model architecture research where standard architectures fail to meet accuracy, latency, or compute constraints for a specific domain
• Training data investigation — determining what data characteristics, augmentation strategies, or labelling approaches are required
• Inference optimization on constrained hardware where existing frameworks don't meet latency or memory requirements
• Novel loss function or training objective design for tasks where standard losses are insufficient
• Multi-modal learning and sensor fusion where temporal alignment or cross-modal integration required original investigation
• Uncertainty quantification or calibration in high-stakes applications where model confidence was not achievable with standard techniques
• Federated learning or privacy-preserving ML where novel protocol design was required

AI work that is less likely to qualify

• Fine-tuning pre-trained foundation models on new data using standard procedures
• Deploying existing models into production using documented frameworks
• Standard prompt engineering and LLM integration work
• Running experiments where the approach is fully documented and the uncertainty is operational, not technical
• Purchasing and integrating third-party AI APIs without original model development

AI SR&ED evidence examples

AI projects generate a lot of evidence. The key is organizing it so CRA reviewers can follow the narrative from uncertainty to systematic investigation to advancement.

• Training run logs with loss curves, accuracy metrics, and configuration snapshots
• Benchmark results comparing model variants against baselines and target metrics
• Hyperparameter search records (Weights & Biases, MLflow, TensorBoard exports)
• Architecture decision documents explaining why specific model choices were made and what alternatives were rejected
• GPU/compute usage records as evidence of systematic experimental activity
• Dataset version control and documentation of data preprocessing investigations
• Code commits showing iterative model development, ablation studies, and experimental branches

Common AI SR&ED documentation mistakes

• Claiming all model work as SR&ED without distinguishing routine fine-tuning from genuine uncertainty
• Using production performance metrics as evidence without showing the experimental process that achieved them
• Missing records of failed experiments — which are essential for demonstrating systematic investigation
• Describing business outcomes (e.g., 'improved conversion') instead of technical advancement
• Failing to document why standard approaches were insufficient for the specific problem

How sredy.io helps AI teams

sredy.io translates your AI research into CRA-ready T661 narratives. The platform structures your project descriptions around technical uncertainty, systematic investigation, and advancement — and helps your accountant file with confidence.

Documenting AI SR&ED work

AI and ML work often generates excellent evidence — the challenge is organizing it in a way CRA can follow:

• Training run logs with loss curves, accuracy metrics, and configuration details
• Benchmark results comparing model variants against baseline and target metrics
• Hyperparameter search records (W&B, MLflow, TensorBoard logs)
• Architecture decision documents — why specific choices were made and what alternatives were rejected
• GPU/compute usage records as evidence of systematic experimental activity
• Dataset version control and documentation of data preprocessing investigations