Why R&D Time Tracking Is No Longer Optional in FY2027

We are four and a half months into FY2027. For most New Zealand businesses claiming the RDLTC or RDTI, the evidence that will support - or undermine - your next R&D claim is being created right now. Not in March. Not at year-end. Now.

The most consistent gap we see in first-time and repeat claimants alike is time allocation records. Not the technical narrative. Not the expenditure calculation. Time records - specifically, contemporaneous evidence of how much of each person's working time was spent on eligible R&D activities.

What the Wage Intensity Test Actually Requires

The RDLTC has a gatekeeping test that many businesses only encounter after it's too late: wage intensity must be at least 20% of your total labour costs. If R&D labour represents less than one dollar in five of your wage bill, you don't qualify - regardless of how good the rest of the claim is.

Wage intensity is calculated as:

> R&D labour costs / Total labour costs >= 20%

Labour costs include salaries, wages, employer KiwiSaver contributions, and ACC levies. They include your own salary if you're the founder doing the R&D. They include contractors if those contractors are doing R&D.

The numerator - your R&D labour costs - is not your total payroll. It's the portion of each person's time that was spent on eligible R&D activities. If a developer spends 40% of their time on core R&D and 60% on product maintenance, you can only include the 40%.

Which means IRD needs to see evidence of the 40%.

What "Evidence" Actually Means

IRD doesn't prescribe a specific format for time records, but they do expect something contemporaneous - recorded at or near the time the work was done, not reconstructed months later from memory.

In practice, acceptable evidence includes:

Timesheets or diary entries noting what project or activity each block of time was spent on. These don't need to be precise to the hour, but they need to exist, and they need to be dated.

Project management tools - Jira tickets, Linear issues, GitHub commit logs - can support a time allocation argument, but only if they actually capture the R&D work and can be mapped to a person and a period. Export logs at year-end are not the same as contemporaneous records.

Narrative records describing what R&D activities were undertaken each period and by whom. If a team member writes a short summary each week describing the R&D problems they were working on, that record has real evidentiary value.

What doesn't work: asking people to estimate, from memory, in March, how much time they spent on R&D during the prior April. IRD has seen that approach before, and it rarely withstands scrutiny.

The RDTI Time Allocation Requirement

The RDTI doesn't have a wage intensity test, but it has the same underlying documentation requirement: your eligible labour costs must be calculated based on actual time allocation, and that allocation must be supportable.

For MBIE's General Approval process, you describe your R&D activities. For the Supplementary Return, you calculate the expenditure. The expenditure calculation for labour requires apportionment - and apportionment requires records.

MBIE audits R&D claims. In our experience, the most common audit question is: how did you arrive at the percentage of time this person spent on R&D? If the answer is "we estimated it at year-end," that's a risk. If the answer is "we have period-by-period allocation records from each team member, here's the dataset," the audit conversation is much shorter.

Why August Is the Right Time to Fix This

Four months in means you still have eight months of FY2027 to capture properly. If you started tracking in April, good. If you haven't started yet, August is still early enough to matter.

By contrast, if you wait until February 2027 to think about this, you're working with three months of clean data and nine months of reconstructed estimates. Reconstructed estimates are difficult to defend and may result in a reduced claim - or a declined one.

The compounding effect of good records works in your favour: every week of properly captured time allocation is a week of data you don't have to estimate later.

What a Minimal, Workable System Looks Like

You don't need enterprise timekeeping software. The minimum viable system is:

One entry per person per period. Each team member who does R&D records their allocation once per period - weekly, fortnightly, or monthly depending on your team's rhythm. They note what percentage of their time went to R&D activities, which activities specifically, and a short description of what they worked on.

Captured close to the time. The record should be made within days of the period ending, not weeks. The more contemporaneous, the stronger the evidence.

Stored somewhere retrievable. A spreadsheet is fine. A document management system is fine. What you need is the ability to produce the records if asked - organised by person, by period, and by project.

Tied to your FY. Your records should align with the R&D scope you're claiming under: the fiscal year, the activities you've identified as eligible, and the team members who are involved.

The Connection to Claim Value

Time allocation drives claim value directly. Consider a team of five, where three people each allocate 50% of their time to R&D, and two people allocate 10%:

3 x 50% = 1.5 FTE of R&D labour
2 x 10% = 0.2 FTE
Total: 1.7 FTE of eligible labour

If average salary is $120,000, eligible labour is roughly $204,000. At the RDLTC rate, that's approximately $57,000 in cash credits per year.

Increase those allocations by 10 percentage points through better identification and capture of R&D time, and the credit increases by roughly $10,000. Do that for three years and you've recovered an additional $30,000.

The records aren't administrative overhead. They are the claim.

Setting Up for FY2027

If you don't have a time tracking system in place for this financial year, here's what we recommend:

Identify your eligible activities. What are the core R&D activities your team is working on? Name them - even informally. These become the categories your team tracks against.

Identify your R&D team members. Not everyone will have meaningful R&D allocation. Focus on the people who do.

Pick a period frequency and stick to it. Weekly is ideal. Fortnightly is workable. Monthly is the minimum.

Start this week. Have each R&D team member complete their first record. A retrospective entry covering the past few weeks is better than nothing - but make it clear this is the last retrospective entry, and that future records are completed within a day or two of each period ending.

Review at six months. Around the end of October, check: are the records being maintained? Does the aggregate allocation look reasonable? Is wage intensity likely to clear 20%? If something needs adjusting, you have time.

The claims that succeed in April 2028 will be built on records that are being created right now. August is not too late to start.