Claiming the R&D Tax Incentive is like training for a marathon
Outside of tax work, one of my long-standing passions is running marathons. Anyone who’s trained for one knows it’s not about a single heroic effort - it’s about consistency, structure, and respecting the process.
Over the years, I’ve noticed that the businesses who do the R&D Tax Incentive well - particularly software companies - approach it in a very similar way.
And the ones who struggle? They usually make the same mistakes people make when they decide to “wing” marathon training.
You don’t just wake up and run 42.2km
No one signs up for a marathon thinking:
“I’ll just see how I go on race day.”
At least, not if they want to finish.
Yet I often see software businesses approach the R&D Tax Incentive this way. They’ve been building product all year, and when tax time rolls around the question becomes:
“Can we just claim all of this as R&D?”
Just like marathon running, the result is determined well before the big day.
The work that matters happens long before claim time
When I’m training for a marathon, the key sessions aren’t glamorous:
early morning runs
long, steady efforts
tracking distance and recovery
adjusting when something doesn’t feel right
R&D claims work the same way.
Strong software R&D claims are built through:
identifying genuine technical uncertainty
forming hypotheses
running experiments
recording what was tried, what worked, and what didn’t
Trying to reconstruct this after the fact is a bit like trying to do all your training in the final week - technically possible, but rarely convincing.
Not every run is a race (and not all coding is R&D)
In marathon training, not every run is meant to be hard. Some runs are just about:
building endurance
maintaining consistency
supporting recovery
Not every session is a race.
In software development, the same distinction matters. While software businesses are often innovative by nature, not all development activity qualifies as R&D.
For R&D purposes, the real questions are:
What technical problem were you trying to solve?
Why wasn’t the solution already known?
What experimentation was required?
Routine development, maintenance, and bug fixes are important - but they’re more like easy mileage than race pace.
Failed experiments still count
Anyone who runs long enough has had:
training blocks that didn’t go to plan
injuries
races that ended early
Those experiences still contribute to learning and improvement.
One of the biggest misconceptions I see with the R&D Tax Incentive is that projects must succeed. In reality:
failed experiments can still qualify
abandoned approaches can still be eligible
learning what doesn’t work is often the point
In both running and R&D, progress is rarely linear.
Shortcuts usually catch up with you
In marathon training, shortcuts show up as:
skipping long runs
overtraining
ignoring recovery
In R&D claims, shortcuts look like:
claiming 100% of developer time
treating all software development as experimental
retrofitting documentation
relying on generic claim templates
In both cases, the consequences usually appear later - whether that’s injury or an uncomfortable conversation with AusIndustry or the ATO.
Consistency beats intensity
The runners who perform best over time aren’t the ones who train hardest for a short period - they’re the ones who train consistently year after year.
The same applies to software companies claiming the R&D Tax Incentive.
The best outcomes tend to come from:
a repeatable, disciplined approach
realistic assessments of what qualifies
documentation that reflects how development actually happens
a focus on defensibility rather than maximisation
The goal isn’t to “win” the R&D claim once - it’s to be able to claim confidently and sustainably.
Final thought
Marathon training and R&D tax claims reward the same mindset:
patience
structure
honesty about the process
respect for the rules
When software businesses approach the R&D Tax Incentive the same way they’d approach marathon training - with planning, discipline, and realistic expectations - the outcome is usually far better.
And in both cases, it’s not about starting strong.
| It’s about finishing well.
Further reading
If you’re looking for a more practical breakdown of what qualifies and what doesn’t, you may find this helpful:
