On longer car rides we often play “I spy with my little eye” and other guessing games with our daughter. Obviously, at almost seven she is a complete pro at these games. We play them on demand and, interrupted by taking turns choosing the music or the odd spilt water bottle, the activities are delightfully chaotic distractions.

In the moment, for her it’s all fun and games while we enjoy hearing less “are we there yet?”. Over time, outcomes of stronger family connection and new deduction skills might spill over and benefit society. I am not here to propose a tax incentive for car games, but to try and make our topic intuitive without much jargon.

The legal criteria for the NZ RDTI use concepts adapted from earlier overseas regimes. They are ultimately designed as a decision tool for what government does and does not subsidise. A simplified core activity definition is similar enough to this:

A “core guessing game activity” means an activity that

• is conducted using a systematic approach of clear rules and clues (AND)
• has a material purpose of building new skills or improved family connection (AND)
• has a material purpose of resolving uncertainty about what another player is thinking.

We can assess different games against them. In our favourite "Guess Who?" game, one of us secretly picks a person while the rest of the family try to identify them by asking questions. It meets the criteria when we take turns picking and guessing, stick to yes/no clues and never make it too easy or reveal the answer until someone has worked it out.

Ad hoc guessing, like “Guys, guess who I just spotted!”, does not have clear rules and the answer might be obvious, not uncertain. Equally, playing “Guess who?” as a diagnostic tool in a dementia ward has no purpose of building skills or family connection.

The real criteria have extra qualifiers and exclusions – but this simple version will do for our purposes.

The Motu 2025 evaluation found that while ultimate approval rates for General Approvals and Supplementary Returns are high (92–96% more recently), the need to identify and separately record core and supporting activities within a single project emerged as a major compliance cost.

Practical classification of core and supporting activities remains confusing – especially in the digital technology sector. Part of this confusion comes from treating them as natural buckets that R&D activities automatically fall into. Explainer material reiterating official guidance passages more or less verbatim does not help either. Whether accompanied by simple explanations or detailed technical examples, people are left wondering if their R&D activity "is" core or supporting or how it fits into the buckets. Neither the legislation nor the IR1240 guidance actually work like that.

The problem is the same, whether you are planning pre-approval for the next three years or mapping work retrospectively before the deadline. The definitions are not hard to understand once you take a closer look - but how to use them effectively in practice to structure applications that are complete, defensible and can be processed with little friction needs a practical decision model.

For many digital claims, the separation of activity mapping for the General Approval application (GA) from expenditure attribution in the Supplementary Return is necessary, so we focus on the former here while recognising that both need to be considered early on.

The goal is not a single “correct” structure, but confident scoping of activities and an application structure supported by your real work and records, with an eye on the trade-offs between recovery and compliance cost.

Hopefully, laying out a way of thinking that has emerged from my experience helps you structure the application and makes more of the choices obvious when you work through the guidance and your own records.

What we mean by “core activity” and “supporting activity” depends on the context. Throughout material on the NZ RDTI they appear in three distinct senses, and which one is meant may not always be obvious:

• The categories defined in the Income Tax Act 2007 and interpreted in IR1240.
• The work that is “conducted” day-to-day in a business.
• The description in an application that maps the work to the criteria

Sometimes, “core activity” and “supporting activity” denote the legal categories. The guidance uses this first sense where it says “the definition of a core R&D activity”.

When used in the second sense the term identifies real R&D work: “The work on the predictive analytics engine could be core R&D activity”.

Finally, when the guidance says “to claim” you “must have a core R&D activity” / “you may also have supporting R&D activity”, it is using the third sense. Here, “core activity” and “supporting activity” mean the descriptions that make up an application.

Untangling these three senses helps turn a compliance headache into practical thinking for RDTI application strategy.

Across many applications that I have seen, a common interpretation sees “core” as important and “supporting” as unimportant. This is not how the distinction actually works. Look at this short conversation:

Nana: “Did you guys play I spy?”

Daughter: “We took turns choosing the music. We had fun playing together! I picked the sky and said it was blue. Papa could not hear me and closed the window. It took them ages to guess. On Mama’s turn I spilled my whole water bottle.”

Nana: “Haha, that was not part of the game.”

Daughter: “We had to change clothes to keep playing.”

Nana: “I’m sure you would have changed anyway.”

The way this dialogue mixes game-play activities with others makes it messy in a similar way to real R&D projects - especially in the digital sector - but more about that later.

Obviously, closing the window, picking music, and the spilt water bottle are not helpful in describing an “I spy” game at all. The evidence lies in her mentioning turns, clues and guesses. Having fun with the family shows a purpose of strengthening family connection. This “pure game-play” and purpose are the central subject of any core activity description.

Similarly, a core R&D activity is typically evidenced by the open scientific or technological questions you are not certain can be resolved, the experiments and investigations planned to answer them, the learnings from success and failure, and the resulting changes to your solution or approach.

Yet, when you look at the reality in the car, the pure game-play is only half the story.

Say we are on our way with a broken aircon. Despite the hot temperatures, we might have closed the window so we could hear each other properly for the game. We might have discussed whose turn it was after an interruption. Perhaps we needed to clarify some rules. These activities are not part of the game-play, but necessary for playing the game in real life and we would never do them if it was not for the game.

Two insights matter for supporting activities:

• The nature of the activity is only secondary for its eligibility.
• The definition refers to the whole reality, not just to the pure game-play description.

The first one follows the observation that the legal criteria lack any reference to the nature of a supporting activity. With the exception of specific exclusions that we are not going into here, a supporting activity is entirely defined by its relationship with a core activity:

Supporting R&D activity means an activity that

The second key unlocks the last clause “conducting a person’s core R&D activity”. Here, “core R&D activity” refers to the real day-to-day R&D work in a business, not to the focused core description inside an application. Closing the window is not part of the game-play, but it is an integral part of “conducting” this real game. It is required and, given the broken aircon, only done for this reason.

Neither closing the window before parking the car nor changing the clothes are eligible. While the latter is required to continue the game, its main purpose is to restore comfort, not to continue the game, so we would do it anyway.

These examples are obvious constructs, but the purpose and necessity of real R&D activities can be just as obvious to someone who understands R&D. Clear activity descriptions focused on the relevant criteria let assessors do their work efficiently. Ambiguous descriptions lacking recognisable purpose or relationship with the core raise questions and can slow down the application process, creating extra work for everyone.

Say we play a guessing game that is new to my daughter’s friend. If we follow the game rules and keep the guessing real, this could qualify as a core activity in its own right. What if the main purpose is to teach the friend before the car ride, so she can join the ‘real’ game later? In the bigger picture, the same rounds could qualify as supporting to that later core. This shift in perspective does not change the activity, but in the new context it has a different main purpose.

Core and supporting activities are lenses, not natural buckets that any real activity has to automatically fall into.

The guidance is clear that you should exercise judgement about the level at which to describe the core activity - whether related uncertainties are grouped or separated.

This is consistent with how real R&D works. Uncertainty is often nested because breaking down bigger problems into smaller ones is at the heart of science and engineering and becomes unavoidable as problems become big or uncertain enough.

When looked at in isolation, resolving a smaller problem may well meet the core criteria. In the wider context, the same activity has the main purpose of resolving the bigger one and is required for this – it no longer has to meet the core activity criteria to be eligible supporting activity. In many real situations these relationships are not hierarchical and the same activity can be supporting several core activities.

IR1240 says that core activity can include “designing and documenting the systematic approach” and that “documenting the R&D results” could qualify as supporting. It is not a flaw that “documenting” appears in both lists, nor is it coincidental. It is a hint that these are meant as helpful examples that assume a context, not rigid rules.

The legal criteria can only be applied to a bounded activity - not to an undifferentiated stream of work. Deciding what to apply the tests to is what creates the buckets as a feature of your application map.

Often this choice of how to slice and dice your activities can generate alternative maps that are all defensible. Which one is the most beneficial depends on your exact situation.

For more on how assessors view clear boundaries and over-claiming risk, see 10 Things I Wish Every RDTI Applicant Knew (especially point 8).

If it still feels a bit unnatural to think of your digital R&D projects in terms of core and supporting activities, then that’s because it is.

Over the years, the different rates at which software development practice and the legal criteria have changed have created a lag. The policy-driven legal constructs of core and supporting activity have a long history. Their main criteria are still very similar to the 2007 version of the NZ RDTI and essentially unchanged since 2019.

Some exclusions in Schedule 21 reveal an increasingly dated software development model where routine debugging, bug testing and beta testing are distinct activities. With the adoption of CI/CD, continuous testing, and agentic software development, these aspects are increasingly interleaved and automated. However, “Continuous delivery” or “agentic development” do not describe core R&D any more than “our daughter runs the show” describes a guessing game.

From an RDTI perspective, eligible software development activities can appear interrupted or performed alongside unrelated delivery work. Interrupting the “I spy” game does not change its game-play.

There is still work to build prototypes and test technological ideas to learn if the underlying software engineering, computer science or architecture problem can be resolved. There is still work on algorithms, system designs, models, protocols, technical components or complex systems with uncertain behaviour.

The execution of the work may be carried out directly by people, with AI assistance, or substantially by AI systems. What matters is the planned, systematic approach to experimenting and investigating in an attempt to resolve the technological uncertainty. Prompting an app into existence is not the same as systematically working out how to solve a problem that nobody knows how to solve.

Not every team discussion is automatically eligible, but discussions to analyse failed experiments and decide what to try next may be. The relevant activity is not the retrospective or refinement meeting. It is the ‘evaluation of experimental results’ and ‘planning the next steps’ that happen as part of a meeting, outside of it or across all meetings for six months.

This can leave a remaining problem where an eligible activity, although supported by your project documentation, is not recorded as a separate expenditure item, but as part of a larger item.

Apportionment is a standard way the tax system deals with mixed activities, such as home-office claims or vehicle use. The RDTI uses the same basic idea of identifying the portion of expenditure that relates to the eligible activity, on a reasonable and supportable basis.

When all individual activities are defensible as clear steps of the systematic approach to resolve uncertainty, a simple core-only application can work. With increasing project complexity, this approach tends to create muddied or overly complex core activity narratives and splitting out supporting activities has clear benefits.

Consider developing specialised software to monitor or capture test results. There is usually no uncertainty inside that work itself and you might think of it as a fundamental part of your experimental approach. However, it is often much cleaner and easier to focus the systematic approach description on the experimentation and the reasons behind it. The same software development can meet supporting activity criteria given its main purpose and necessity to run or evaluate the core experimentation.

A clear application structure upfront reduces unnecessary compliance risk. It can also prevent having to restructure the application following an RFI, which can significantly increase compliance cost and is no longer feasible after the deadline.

Supporting activities can also open recovery opportunities that are not available for core activities:

• They can be performed outside of New Zealand and up to 10% of the total eligible expenditure can be claimed as overseas expenditure.
• They can be claimed for the “prior year”, giving them retrospective timing flexibility that core activities do not have.
• Some excluded core activities can still qualify as supporting activities.

The real value of these options depends on your project and records. Whether the activity is worth claiming is ultimately your judgement as the claimant. What passes the tests is up to the review process.

Once you have legally defensible alternatives, the flexibility is real but has clear limits and constraints. The application has to stay consistent with the real work as well as the law, and the records have to support it. If your choice results in higher eligible expenditure this does not mean ineligible activity has been magically described as eligible. It means that the alternative choice leaves eligible expenditure unclaimed. In any case, those judgement calls form part of your tax position and should be documented.

The level at which to describe the core activity is often the main structural decision. Once that level is set, the choice then remains what goes inside the systematic approach versus what is described separately as supporting activity. Simply choosing the top-level problem as the core is not automatically the best strategy because the uncertainty can become harder to express at that high level. Also, the bulk of supporting activity might map much more naturally to a specific level through your records.

Working with the design of the regime rather than against it, the flexibility of supporting activities suggests aligning them more closely with your actual expenditure and project records where defensible, while keeping the core activity description focused so it clearly demonstrates eligibility.

Going beyond a single core activity may have limited pay-off for very simple applications. For many applications in the middle ground, 20% of the effort is worth 80% of the outcome.

Applications for complex R&D programmes can have a much further point of diminishing returns. Depending on the complexity it can pay to map core activities at different levels to find an optimal overall mapping. Supporting activities only make sense relative to a core, so the quality of the mapping depends in part on how cleanly all activities fall into place. Where alternative defensible mappings exist, treat your expenditure and project records as constraints and choose the most practical overall mapping.

Capturing the remaining 20% takes more careful analysis of both the technical work and the legal tests. Ultimately, the quality of the claim comes down to the quality of the judgement used to bound and place the activities. Solid judgement comes from real R&D understanding, built through lived experience and strengthened by practice in the RDTI regime.