Most government support for business R&D in New Zealand — primarily the RDTI and RDLTC, and to a lesser extent the New to R&D Grant — requires technical work to be framed in the language of tax legislation and RDTI eligibility rules. While tax-based incentives have become the dominant model internationally, New Zealand’s two-stage process (General Approval followed by later reconciliation at Supplementary Return) creates some distinctive compliance dynamics.

In practice, three recurring patterns tend to appear in applications and account for many of the issues that arise: language problems around communication and presentation, content problems relating to the presence or absence of substantive technical information, and structural problems in how the application itself is organised and scoped.

In my experience assessing General Approval applications, content and language problems frequently contribute to RFIs at that stage. This is reflected in official guidance emphasising clear technical descriptions and the demonstration of uncertainty.

Structural problems, by contrast, do not trigger early RFIs and are sometimes not identified and resolved until expenditure must be matched against approved activities at the Supplementary Return stage. This can contribute to more significant compliance costs later in the process. The 2025 Motu evaluation noted challenges in Supplementary Return processing and attributed them largely to operational and resourcing constraints. Unresolved structural problems in applications at the General Approval stage may be a contributing factor as well.

Language problems can make claims or evidence hard to understand and often trigger RFIs based on presentation alone.

In my experience, language problems often arise from how applicants handle the specific language and examples in the official guidance:

Sometimes, the use of language in the guidance is ignored. This can lead to a situation where structured experimental work is described as “trial and error”, even though the guidance uses these terms to describe activities that lack a systematic approach and are therefore ineligible. Another example is where the examination of existing technological solutions is referred to as “market research” – which is excluded, not only in the guidance but in the legislation itself.

Conversely, applications that simply copy guidance language verbatim can cause RFIs if this reads as unsubstantiated claims or raises doubt about what actually happened. For example, applications might claim “hypothesis formulation” as a supporting activity despite no formal scientific hypothesis having been formulated or documented.

In both cases RFIs can often not be avoided when language directly contradicts the interpretation of official guidance or unevidenced claims are made in language that is a direct copy from official documents.

Another recurring issue is hype or buzzword language that sounds technical but carries little substance — especially common in software and AI related fields. People often feel they already understand the underlying technology or the associated technical language because they interact daily with apps or AI tools. As technology gets commoditised and goes mainstream, technical-sounding terms start drifting into everyday meanings. Common examples I have seen many times in applications include “API”, “training” and “agent”.

This creates an illusion of explanatory depth (Rozenblit & Keil, 2002). Recent research shows that using tools like ChatGPT to help draft or describe technical work often leads people to overestimate the quality of their output, with the effect being stronger among those who consider themselves more AI-literate (Fernandes et al., 2025). To an assessor who knows the field, this kind of language can read as not descriptive of the actual R&D work. In these cases, it may not be possible to clearly pinpoint and ask specific questions about what is unclear resulting in fairly general RFIs seeking a better understanding of the R&D activities as a whole.

Digital technology has been among the more active areas for RDTI claims, so this type of language issue appears frequently in practice. While pure language problems are relatively easy to fix – by asking what was actually meant – that asking itself still creates additional compliance cost and delays when necessitating a RFI.

In my experience, content problems are the most common direct triggers for RFIs. These issues are also the most widely discussed in official RDTI guidance and other public material where they are usually tied to or derived from the legislative criteria.

They include widely understood issues such as lack of evidence of uncertainty, unclear descriptions of what was tried, how it was measured, and what changed.

Scientists and engineers tend to think about R&D in terms of problems, experiments, methods, constraints, tradeoffs or prototypes. Tax and RDTI specialists frame it around defined activities, legal tests and eligibility criteria. This creates a real translation gap — and strong claims or advice depend on bridging both perspectives.

Text can read as empty claims when it describes how the team works rather than the systematic approach taken to resolve a specific technical uncertainty. A brief process description followed by concrete technical details is usually fine — it just adds length. However, when the entire account is essentially a more verbose version of “We use agile”, the required systematic approach is clearly missing from the content.

Content problems come in two directions: what is missing or unclear, and — conversely — claims that include activities which should not be claimed. In practice, several content-related RFI triggers stem from the official lists of excluded activities, which are not always front-of-mind for applicants. These exclusions (for example, certain routine testing, quality control, market research, or specific software activities) are highly context-dependent — whether something falls inside or outside the rules often depends on the purpose and details of the work or on uncertainty being addressed.

Some content gaps are relatively easy to spot and fix through an RFI. This is the case with a lack of evidence of uncertainty, or a missing systematic approach. I have experienced many RFI meetings where an engineer or scientist who is directly involved in the R&D work explains what they do in their language and the full picture suddenly becomes visible filling in the gaps naturally.

The core structural issue is how R&D work is bounded and partitioned into claimable units within an application.

Structural problems tend to be more fundamental than content or language problems. While content and language issues can often be addressed locally through an RFI without reworking the whole application, structural issues are generally harder to identify and resolve once the General Approval Application was filed.

These kinds of problems often arise when there is a mismatch between an application text and how the legislation structures R&D activities. They also arise from how R&D is recorded, how expenditure is accounted for, how - or when - R&D is actually performed vs claimed.

They can manifest in loose categorical boundaries like core vs supporting activities, temporal boundaries such as tax periods or deadlines, or mapping issues between activities and expenditure.

From experience, the way activities are scoped and bounded commonly creates ambiguity or inconsistency when:

• Open scope language (“including but not limited to”) is used to describe activities.
• Boundaries get fuzzy between R&D and normal commercial production or process improvement work.
• Activities are described outside the claimed period or assigned wrong dates and timeframes
• Near-identical applications are submitted years later without any information on progress.

One approach that often carries several of these risks is describing the ‘core activity’ in broad terms as a larger body of work, supported by a list of examples. Depending on specifics, this can trigger RFIs when the overall description is too vague and does not meet the legal requirements. In other cases, it may still be assessed as eligible, but later create difficulties when expenditure is assigned.

In any case a clear mapping between the actual work, internal records and the General Approval material is necessary. This task can be difficult and requires people who understand both the technical detail and the regime’s rules in practice.

Any undetected problem has the potential to perpetuate ambiguity or an information gap through the entire RDTI process and might cause delays at each step or repeated or late queries.

Structural issues, in particular, appear to remain under-discussed publicly. When not caught at the General Approval stage they can create real friction later when expenditure must be matched to approved activities at the Supplementary Return stage.

New Zealand’s two-stage RDTI process in part explains this pattern. General Approval is assessed primarily for technical eligibility of R&D activities by scientific and technological experts. Supplementary Return, by contrast, requires those approved activities to be linked to the business’s actual records and expenditure. When the boundaries and scope in the General Approval are not sufficiently clear or well-defined, it becomes difficult to confidently and defensibly map actual work and costs to the approved activities later — even if the application passed the technical tests at the first stage.

Assessors have limited visibility into how the described activities map to the business’s actual work, records, and expenditure. Without clear mapping, it is difficult to determine whether an issue is simply loose drafting or a more substantive misalignment that may later exclude eligible expenditure from the approved scope.

Their role is to assess what has been submitted against the legislative tests, not to optimise applications. Given the somewhat ‘messy reality’ of real applications, there is always a balance between sending additional RFIs (thereby directly increasing compliance cost for the business) versus processing what is already clearly supported.

This is likely one of the reasons why problems can remain invisible until the Supplementary Return stage, when real expenditure must be matched to activities that were explicitly approved. Work that was assumed to be within scope may have never been explicitly approved — because it was never explicitly applied for in the first place.

This pattern seems consistent with findings from the five-year RDTI evaluation, which notes that administrative friction has shifted from General Approval toward Supplementary Return processing.

It can also create a false sense of security, particularly when General Approval is perceived as straightforward, or when applications are prepared quickly with AI assistance while skipping the mapping exercise.

Where the General Approval does not accurately reflect how the business performs and records its R&D, problems often remain hidden until the Supplementary Return stage. Given the 15% incentive rate, these additional costs can significantly reduce the overall benefit of the claim.

RFIs are the main mechanism for catching unclear applications. Genuine R&D activities are generally given an opportunity to respond and clarify, though this can involve time and distraction.

Some problems are straightforward to fix by rewriting the application. Others require deeper changes in how the business documents, records, plans and scopes its R&D.

The RDTI doesn’t have to become the organising principle for everything. The discipline it encourages around timing, boundaries and clear recording can still improve how teams manage their R&D over time.

Getting both the technical content and the structural framing right from the start avoids friction — whether that shows up as RFIs at General Approval or as mismatches later at Supplementary Return.