R&D Tax Credits for Software Companies in New Zealand
How NZ software and SaaS companies can claim R&D tax credits for development work that involves genuine technical uncertainty.
Software companies are among the most common claimants of R&D tax credits in New Zealand, and for good reason — much of what software teams do involves genuine technical problem-solving. But the line between routine development and eligible R&D isn't always obvious. This guide explains what software R&D qualifies and how to build a strong claim.
Does Software Development Count as R&D?
The short answer: sometimes, but not always.
The RDTI requires that activities involve resolving scientific or technological uncertainty. In software, this means the work must go beyond applying known techniques to known problems. Building a standard CRUD application using well-established frameworks is not R&D, even if it's technically complex.
What makes software development eligible is the presence of genuine uncertainty about whether or how something can be achieved.
What Qualifies: Examples
Machine learning and AI development
Training models where the outcome is uncertain — for example, experimenting with different architectures to achieve acceptable accuracy on a novel dataset. The uncertainty might be: "Can we achieve 95% accuracy on this classification task given the noise in our data?" or "Will this model generalise to unseen data in production?"
Performance and scalability challenges
Building systems that must handle scale or performance requirements beyond what existing solutions can achieve. For example: "Can we process 10 million events per second with sub-100ms latency on commodity hardware?" If the answer isn't known in advance, this is R&D.
Novel algorithms and data structures
Developing new algorithms to solve problems that existing approaches can't handle efficiently. This could be a new search algorithm, a novel compression technique, or a custom scheduling system.
Natural language processing
Building systems that understand, interpret, or generate human language — particularly when dealing with domain-specific terminology, multi-lingual content, or context-dependent meaning where existing models fall short.
Security and cryptography
Developing new security protocols, encryption methods, or vulnerability detection approaches where the effectiveness is uncertain until tested.
Real-time systems
Building software that must operate within strict timing constraints (robotics control systems, financial trading platforms, IoT devices) where meeting requirements involves resolving technical unknowns.
What Doesn't Qualify: Examples
Standard web and mobile applications
Building a website, mobile app, or API using established frameworks (React, Rails, Django, Flutter) and standard patterns. Even if the app is complex and takes months to build, if you're applying known techniques to known problems, it's not R&D.
System integration
Connecting existing systems via APIs, setting up databases, deploying to cloud infrastructure, or configuring third-party services. These are engineering tasks, not R&D.
Bug fixing and maintenance
Resolving defects in existing software, updating dependencies, or maintaining production systems. These are routine operational activities.
UI/UX design
Creating user interfaces, designing user flows, or conducting usability testing. Design decisions may be creative, but they don't involve scientific or technological uncertainty.
Data migration
Moving data between systems, transforming data formats, or building ETL pipelines using standard tools and techniques.
Structuring Your Claim
Software companies often struggle to separate R&D from non-R&D work because developers frequently switch between the two. Here's how to structure a clean claim:
Define R&D projects clearly. Each project should have:
- A stated hypothesis or uncertainty ("We believe X is possible, but we don't know if...")
- A systematic approach to resolving the uncertainty
- Clear start and end criteria
- Documentation of what was tried and what was learned
Track time by project. Use your project management tools (Jira, Linear, GitHub Projects) to tag tasks as R&D or non-R&D. At the end of the year, you can pull reports showing how much time each developer spent on R&D tasks.
Separate spikes and experiments from feature work. If a developer spends two weeks experimenting with a new approach before building the production feature, those two weeks are likely R&D (resolving uncertainty). The subsequent feature build using the proven approach may not be.
Common Software R&D Claims
Here's what a typical software company claim might look like:
| Category | Annual Cost | R&D % | Eligible |
|---|---|---|---|
| Senior developers (4) | $560,000 | 55% | $308,000 |
| ML engineer (1) | $150,000 | 80% | $120,000 |
| QA engineer (R&D testing) | $110,000 | 40% | $44,000 |
| Cloud computing (ML training) | $36,000 | 70% | $25,200 |
| Specialised software licences | $12,000 | 100% | $12,000 |
| Total eligible | $509,200 |
RDTI credit at 15%: $76,380
If the company is in a tax loss (common for startups), the RDLTC at 28% could deliver even more.
Documentation Tips for Software Companies
Write technical narratives. For each R&D project, document:
- What problem you were trying to solve
- Why existing solutions were insufficient
- What approaches you tried
- What results you observed
- What you concluded (success, failure, or pivot)
These narratives are the core of your General Approval application and should be written by the developers involved, not just management.
Use version control as evidence. Your Git history, branch structure, and pull request descriptions provide a chronological record of your R&D work. Experimental branches, spike PRs, and technical design documents all support your claim.
Record failed experiments. R&D doesn't have to succeed to be eligible. If you spent three weeks testing an approach that ultimately didn't work, that's still R&D — you resolved the uncertainty (the answer was "no, this approach doesn't work"). Document these failures; they strengthen your claim by demonstrating genuine investigation.
SaaS-Specific Considerations
SaaS companies have some unique considerations:
Product vs platform R&D: If you're building a SaaS product, distinguish between feature development (often not R&D) and platform or infrastructure R&D (more likely to qualify). Building a new multi-tenant architecture, developing a novel data processing pipeline, or creating a custom query optimiser could all involve genuine technical uncertainty.
Customer-funded R&D: If a customer is paying you to build something that involves R&D, the expenditure may still qualify, but you need to ensure you retain the intellectual property and bear the technical risk.
Open source contributions: If your developers contribute to open source projects as part of resolving technical uncertainties in your product, that time may qualify.
Getting Started
If you're a software company that hasn't claimed R&D tax credits before, start by:
- Listing your technical challenges from the past year — problems where you didn't know the solution in advance
- Estimating time spent on those challenges vs routine development
- Calculating potential benefit using the 15% RDTI rate (or 28% RDLTC if you're in a loss)
- Gathering documentation from your project management tools and Git history
At Get Tax Credits, we specialise in helping software companies navigate this process. Our AI-powered platform analyses your development activities and financial data to identify eligible R&D and calculate your potential credit.