New Zealand's R&D Tax Incentive has been linked to NZ$6.77 billion in additional GDP, according to a five-year evaluation of the scheme published by the Ministry of Business, Innovation and Employment. That changes the way founders should look at the R&D tax incentive NZ. It isn't merely a year-end tax form. For a technical company with genuine development risk, it can help fund the work that keeps the product alive.
The hard part is separating real R&D from ordinary product work, then building enough evidence to support the claim. The opportunity is meaningful, but sloppy categorisation can turn a useful credit into a painful review. Here's how the scheme works for NZ software, SaaS, app and AI businesses, with a particular focus on the shift towards in-year payments in 2026.
The evaluation found that 1,752 firms accessed the RDTI, received an estimated NZ$1 billion in tax credits, and generated an estimated NZ$1.83 billion in additional R&D activity. It also estimated a GDP increase of NZ$6.77 billion, around 4.2 times the Government's investment. Those results give founders a practical reason to treat the scheme as part of funding planning, not just year-end tax administration.
The figures do not make every feature request eligible. They show that the policy is intended to influence real investment decisions. A founder deciding whether to retain an engineer, test a difficult technical approach or postpone a risky build is making a cash-flow decision. A 15% tax credit can affect that choice, particularly when a large share of the company's burn is NZ payroll.
The scheme began on 1 April 2019. It offers a 15% credit on eligible R&D expenditure, subject to a NZ$50,000 minimum annual eligible spend and a NZ$120 million cap on eligible expenditure in an income year. In practical terms, the Government helps fund technically uncertain, systematic work performed in New Zealand. It does not subsidise ordinary business activity just because a company describes it as such.
A credit claimed after the year closes still has value, but the company must first carry the development cost. That delay can matter more than the headline rate. Startups can have a sound long-term plan and still run out of cash before the next release, customer contract or funding round.
The 2026 policy shift changes that calculation. The Government has said the RDTI will move from a year-end-only claim towards in-year payments, with the stated aim of removing a key cash-flow barrier. The same Government announcement on tax changes says the internal software cap will fall from NZ$25 million to NZ$3 million. That is a material consideration for SaaS and AI companies whose eligible work sits inside software development.
In-year payments could make the RDTI a working-capital tool rather than only a retrospective tax benefit. The payment will not replace cash forecasting or funding discipline, but it may help a founder keep a technical team working through a tight quarter. Founders still forming the company should also review this guide on how to start a small business in NZ, because structure and record-keeping choices affect how easily the claim can be supported.
Eligibility follows the work, not the company's label. Describing a project as “AI”, “deep tech” or “innovation” does not support a claim if the underlying activity is routine. Inland Revenue requires the R&D to be directly related to, required for and integral to the activity. The expenditure must also fall within the eligible categories rather than the exclusions listed in the R&D tax incentive guidance.
Ask whether a competent professional could readily determine how to achieve the result using publicly available knowledge. If not, the work may contain qualifying R&D. The uncertainty must concern a technical outcome, rather than whether customers will buy the product or whether the project will make money.
A SaaS company testing a new data synchronisation method may have a qualifying core activity. A mobile app team solving an unresolved performance problem across difficult device conditions may also qualify. Adding a standard payment gateway, changing interface colours and fixing a known bug generally resemble ordinary development.
The boundary can run through one sprint. A developer may spend part of the week testing a new algorithm and the rest connecting a third-party API. The project name will not separate those activities. Timesheets, technical notes and commit records need to show the difference.
The policy targets core R&D activities performed in New Zealand. Overseas supporting activities are generally limited to up to 10% of total eligible expenditure when they support a core NZ-based activity. If the technical investigation takes place offshore while the New Zealand team only coordinates delivery, the claim is exposed.
Use this screening list before committing time to a claim:
The 2026 policy shift towards in-year payments makes disciplined classification more useful for cash planning. A claim that clearly separates eligible technical work from routine delivery is easier to support when the company needs working capital during development, rather than waiting until year-end.
Company structure affects payroll, contracting and record keeping. Founders comparing structures can review this guide to sole trader versus company in NZ, then obtain advice suited to their circumstances.
The practical test is whether the work resolves a technical uncertainty through a structured investigation. Product development surrounding that investigation may sit in the same repository, sprint or team, yet receive different treatment.
| Development activity | Likely treatment | Why it matters |
|---|---|---|
| Creating a novel machine-learning algorithm for a fintech product | Potential core R&D | The team may be resolving a technical uncertainty through testing |
| Building a proprietary data-processing pipeline | Potential core R&D | The result may depend on systematic investigation |
| Integrating a third-party API | Usually routine development | The technical method may already be known and documented |
| Configuring off-the-shelf analytics tools | Usually not core R&D | Configuration alone rarely resolves a technical uncertainty |
| Routine bug fixing and maintenance | Usually not core R&D | Known defects and ordinary upkeep generally lack the required uncertainty |
| Market research or customer interviews | Supporting or ineligible activity | Commercial discovery isn't the same as technical investigation |
Strong claims isolate the experimental work from the surrounding delivery work. For example, a team may investigate whether a new model can process noisy transaction data, then build a conventional dashboard to display the result. The model investigation may qualify. The dashboard work generally does not, even though both form part of the same product.
Eligible costs can include wages, contractor fees, depreciation on R&D equipment and consumables, provided they relate to qualifying work and meet the scheme rules. The working test is traceability. Can the company connect each cost to the technical investigation with evidence?
Time records help, but vague descriptions create problems. “Worked on platform” gives a reviewer little to assess. “Tested event-ordering approach against delayed inputs and recorded failure mode” identifies the technical work and its purpose. Contractor invoices need the same support. An invoice labelled “software development” may require project notes, tickets or technical records showing the problem investigated and the work completed.
Record the connection while the work is underway. Reconstructing it from invoices at claim time is slower and usually produces weaker evidence.
Supporting work may assist a core activity, but a new product idea does not turn every related task into core R&D. The eligible and ineligible categories still apply. Commercial launch activity, sales preparation, quality control and routine maintenance need to remain separate from technical investigation.
Practical rule: If you can't explain the technical uncertainty in a short paragraph, don't start by calculating the credit. Start by testing whether the activity belongs in the claim.
External engineering arrangements need a written scope that distinguishes experimental work from ordinary delivery. Teams using co-development software arrangements should still maintain RDTI records describing the actual technical work. A contract title or project label cannot establish eligibility by itself.
That separation also improves cash planning. As in-year payments arrive under the 2026 policy shift, clear cost allocation can help a business treat eligible R&D as working capital during development, rather than relying only on a retrospective year-end benefit.
The basic calculation is straightforward. Multiply eligible R&D expenditure by 15%, subject to the scheme's wider rules and limits. The tricky part is what happens next, particularly when the company has little taxable income.
The following examples apply the 15% rate to the eligible spend shown. They're calculation illustrations, not a determination that every dollar in each profile qualifies.
| Company Profile | Eligible R&D Spend | 15% Credit | Tax Position | Cash Benefit |
|---|---|---|---|---|
| Bootstrapped SaaS startup | NZ$200,000 | NZ$30,000 | Credit may offset tax payable | Cash depends on tax position and refund rules |
| Growth-stage app company | NZ$800,000 | NZ$120,000 | Credit may offset tax payable | Cash depends on tax position and refund rules |
| Well-funded AI platform | NZ$2,000,000 | NZ$300,000 | Credit may offset tax payable | Refund may be limited even where the calculated credit is higher |
The refundability rules matter most for loss-making companies. If a company is in tax loss, or its credit exceeds tax payable, it may receive a refund of up to NZ$255,000. Inland Revenue says that amount corresponds to about NZ$1.7 million of eligible R&D spend, subject to wage-intensity and related criteria, as explained in its guidance on RDTI credits.
That ceiling creates a practical distinction between the calculated credit and the cash received. An AI company with NZ$2 million of eligible spend may calculate a NZ$300,000 credit, but it shouldn't forecast NZ$300,000 of immediate cash without checking its tax position, wage intensity and refund limits. The benefit is strongest for technically staffed businesses with substantial NZ wage spend. It's less useful for a capital-light company whose delivery work is mostly offshore.
For a startup, the useful question isn't “What's our credit?” It's “When can this money affect payroll, contractors or the next build?” The move towards in-year payments in 2026 could make that forecast more useful, although founders should confirm the operating details before relying on projected timing.
Because the rules combine eligibility, tax treatment and refund conditions, specialist review can pay for itself when the claim is material. A general reference on business tax solutions from Allied Tax Advisors can help frame the wider tax conversation, but it shouldn't replace advice on your specific RDTI claim.
Weak claims usually fail on reconstruction, not engineering. Six months later, “we were building an AI feature” says little about the uncertainty, hypotheses, tests or results. Reviewers need a traceable record of what the team tried, why the answer was not known in advance, and how the work progressed.
A claimant must perform the R&D on its own behalf, meet the NZD 20,000 of eligible expenditure or depreciation in some cases threshold, and file a detailed R&D statement by the income-year deadline, as explained in IRD's technical guidance. Keep that evidence inside the engineering workflow. A separate compliance exercise tends to become incomplete when delivery pressure rises.
A practical system has four layers:
The tools can stay simple. Linear, Jira, GitHub, GitLab, Notion and a dependable payroll export can support a claim if the team uses them consistently. The important link is between the technical question and the cost claimed.
Retrospective notes often look too tidy. Genuine R&D includes dead ends, revised assumptions and approaches that failed. Preserve those rough edges. Failed tests can show that the team investigated uncertainty instead of following a known implementation path.
A clean repository proves that code exists. It doesn't, by itself, prove why the work was technically uncertain.
Assign one person to manage the claim calendar, while engineers own short technical records. Finance can reconcile wages and invoices. The founder should review the final boundaries, particularly where experimental work overlaps with commercial delivery. Good records also make the 2026 shift toward in-year RDTI payments easier to use as a working-capital tool, because the business can connect expected claims to payroll and build decisions before year-end.
The biggest mistake I see is including every sprint in the claim, including standard API integrations and known bug fixes. Those activities may matter commercially, but they do not automatically satisfy the RDTI test. Separate experimental investigation from routine implementation before assigning costs.
Offshore delivery creates another risk. Core R&D must be centred in New Zealand. Overseas supporting activity is generally limited to up to 10% of total eligible expenditure when it supports a core NZ activity, as explained in the IRD scheme guidance. Review team locations, contractors and project ownership before the claim period, not after invoices arrive.
The 2026 shift toward in-year RDTI payments makes these controls a cash-flow issue, not just a tax-compliance task. Reliable boundaries and current records let founders forecast payroll support and protect working capital before year-end.
A specialist adviser can help when teams span countries, contractors perform core work, software and hardware overlap, or the claim could affect runway. The adviser can test the boundary and challenge assumptions. They cannot create evidence the team never recorded.
A Wellington SaaS platform claimed NZ$180,000 in credits for a novel data synchronisation engine. Its strongest evidence wasn't the final architecture diagram. It was the sequence of failed approaches, test records and engineering notes showing why ordinary synchronisation patterns didn't solve the problem.
An Auckland mobile app developer separated qualifying algorithm work from routine user-interface development. The company used project tickets and time records to isolate the technical investigation. That boundary kept the claim credible and stopped ordinary design and screen-building work from inflating it.
A Christchurch AI startup, still pre-revenue, handled refundability rules and received NZ$240,000 in cash back. Its claim depended on careful treatment of NZ payroll, clear records of the experimental work and an early review of the refund conditions rather than a last-minute tax calculation.
These examples point to the same lesson. The RDTI rewards disciplined technical work, but it also rewards disciplined bookkeeping. A strong claim tells one consistent story through the code, the tickets, the payroll records and the R&D statement.
NZ Apps offers practical coverage of NZ and Australian software companies, app businesses and technology markets, along with a directory for founders and operators assessing local tools and partners. Visit NZ Apps to build regional visibility for your tech company and connect your work with the wider NZ startup ecosystem.
Add your NZ or Australian app or tech company to the NZ Apps directory and get discovered by founders and operators across the region.
Get ListedReach tech decision-makers across New Zealand and Australia. Sponsored and dofollow editorial links, permanent featured listings, and sponsored articles on a DA30+ .co.nz domain.
See Options