R&D Tax Incentive Examples: How to Write an R&D Application (Australia)

R&D Tax Incentive examples – what “good” actually looks like

If you’ve landed here, you’re probably searching for a clean example of what qualifies as R&D in Australia.
Not the fluffy kind. The kind that would still make sense if AusIndustry or the ATO read it later.

Most people don’t get knocked back because the work wasn’t real.
They get knocked back because the application doesn’t explain the uncertainty and the experimentation properly.
It reads like normal product development.
Or worse, a project update.

“If you can’t clearly explain what you didn’t know at the start, it’s hard to argue you were doing R&D.”

This page gives you a worked example you can model yours on.
It uses the “black box flight recorder” as a fictional project, because it’s a simple way to show the structure.
But the logic is exactly the same whether you’re building software, manufacturing kit, developing a medical device, or improving a process on a production line.

Eligible R&D usually has a moment where your team says – we don’t know if this will work, so we have to test it properly.

Before you scroll, here’s a quick reality check.
If your project has these ingredients, you’re usually in the right territory.

• There was a genuine technical unknown at the start – not just a deadline or a feature list
• You ran tests or trials to resolve it – prototypes, simulations, A/B tests, lab work, test rigs, pilots
• You learned something along the way – including failed attempts, dead ends, redesigns, rework
• You can show what you did and when – notes, commits, test results, tickets, photos, lab records

If that already sounds like you, you’ll get a lot out of the example below.
And if you’re not sure, that’s normal too.
A quick chat usually clears it up fast.

Book a 15-minute R&D check

“Two companies can do similar work.
One gets the incentive, the other doesn’t – because one can show the uncertainty and the experiments clearly.”

Alright, let’s get into the example and break it down step by step.

What people mean when they search “R&D tax incentive examples”

Most people aren’t actually looking for an “example application”.
They’re trying to answer a simpler question.
Does what we’re doing count as R&D, or are we kidding ourselves?

So here are a few quick, real-world style examples to calibrate your gut feel.
These aren’t full case studies, just the kind of scenarios we see every week.

Software

Eligible example – You’re building something where the hard part is technical uncertainty. For example, you’re testing different architectures to handle scale, latency, reliability, privacy, security, model performance, or data integrity. You run controlled tests, measure outcomes, and iterate based on results.

Not great – “We built an app”, “we added features”, “we integrated Stripe”, “we migrated to a new stack”. That might be valuable work, but value isn’t the test. Uncertainty and experimentation is.

Manufacturing and engineering

Eligible example – You’re trying to achieve a performance target that isn’t readily achievable with known methods. You design a prototype, change materials, adjust tolerances, run test rigs, record failures, and keep iterating until you can prove what works.

Not great – “We upgraded the line”, “we bought a new machine”, “we improved efficiency”. If it’s mainly implementation of known solutions, it’s usually not R&D.

Food, beverage and ag

Eligible example – You’re testing formulations or process conditions where the outcome is unknown. Shelf life, texture stability, fermentation behaviour, yield, contamination risk, drying profiles. You run batches, compare data, adjust variables, and document results.

Not great – “We developed a new flavour” or “we launched a new product range” without genuine technical uncertainty driving the work.

Construction and materials

Eligible example – You’re trialling a new material system, structural approach, acoustic/thermal performance solution, or installation method where it’s not obvious it will work in your conditions. You prototype, test, measure, and refine.

Not great – “We redesigned the building” or “we delivered a bespoke build” if it’s mainly standard engineering applied to a new site.

“If the work could be written up as a project plan and a delivery timeline, it’s often not R&D. If it needs test results to explain what happened, you’re usually getting warmer.”

Now, the tricky bit.
A lot of projects have some R&D buried inside them.
The mistake is claiming everything, or claiming the wrong bits.
That’s why the example below is structured the way it is – it helps separate core experiments from the surrounding build work.

If you want, book a quick call and I’ll tell you what’s claimable

The structure AusIndustry and the ATO expect (and why most “examples” miss it)

When people search “R&D tax incentive examples”, they’re usually looking for something they can compare their own project against.
Fair.
The issue is most examples online either skip the important parts, or they read like a textbook and don’t help you write your own.

A strong R&D Tax Incentive example isn’t about proving your product is clever.
It’s about proving you had a technical problem that wasn’t readily solvable, and you tested your way through it.
That’s the bit AusIndustry and the ATO care about.

“If the example doesn’t clearly show technical uncertainty and experimentation, it’s not really an R&D example – it’s just a project summary.”

In practice, good applications nearly always follow the same basic spine.

• Technical objective – what you were trying to achieve technically (not the commercial goal)
• Technical uncertainty – what you genuinely didn’t know at the start
• Hypothesis – what you believed might work and why
• Experiments – what you tested, how you tested it, and what changed between iterations
• Results – what you learned, including failures and dead ends

Once that structure is clear, you can separate the work properly.
This matters for both eligibility and the dollars.

• Core R&D activities – the experiments that resolve the technical uncertainty
• Supporting activities – work that directly supports those experiments
• Non-R&D work – delivery, implementation, rollout, BAU, client work, and general improvements

As you go through the worked example below, don’t copy the words.
Copy the structure.
Then swap in your actual project details and your real evidence.
That’s how you end up with something that reads like a genuine Australian R&D tax incentive example, not a template.

Before the worked example – a quick self-check for eligibility

If you’re still on the fence, this section will save you time.
Because the fastest way to waste weeks on the R&D Tax Incentive is to write a beautiful narrative… about work that was never eligible in the first place.

Here’s a simple self-check you can run on your project.
No legal jargon.
Just the common sense version.

1) Was there a genuine technical unknown?

Not “we weren’t sure customers would like it”.
Not “we weren’t sure we could deliver it by Friday”.
A technical unknown is more like – we don’t know if this approach will meet the performance requirement, and we can’t just look it up.

2) Did you actually test different approaches?

This is the experimentation piece.
Prototypes. Trials. Simulations. Bench tests. Controlled comparisons. Instrumented testing.
Anything where you can point to what you changed, what you measured, and what you learned.

3) Could a competent professional have worked it out without testing?

This is the one people miss.
If the solution was already obvious to someone experienced in your field, it usually isn’t R&D.
If the answer only becomes clear after testing, you’re in better shape.

4) Can you back it up with evidence?

You don’t need a lab coat.
But you do need records.
Tickets, commits, test results, prototype photos, design notes, version history, lab logs, field trial data.
Stuff that shows the progression.

If you tick most of those boxes, the worked example below will make a lot more sense.
And it’ll help you frame your own project in a way that matches how Australian R&D claims are assessed.

How to use the worked example on this page

Quick heads up before you dive into the black box example.
The goal isn’t to copy the story.
It’s to steal the format.
Because AusIndustry and the ATO don’t approve claims based on how interesting the project sounds.
They approve them based on whether the logic is clear and the evidence stacks up.

So here’s the best way to use what’s below.

• Replace the “black box” objective with your own technical objective – the measurable thing you were trying to achieve
• Swap the “technical challenges” for your real knowledge gaps – what you genuinely didn’t know at the start
• Turn your belief into a testable hypothesis – what you thought might work, and why
• List the experiments like an engineer would – what variables you changed, what you measured, what failed, what improved
• Be honest about results – failures and dead ends are often the most credible part

If your project has multiple streams (most do), don’t force it into one big blob.
Break it into separate experiments.
That’s usually the difference between an application that reads cleanly, and one that gets picked apart in a review.

One more thing.
You don’t need to sound “formal”.
In fact, overly polished write-ups can work against you, because they start to sound like marketing.
What you want is simple, technical, and specific.

If you want, book a time and I’ll map your project into this structure

Common R&D Tax Incentive mistakes we see when people try to write “examples” themselves

This is the part that catches people out.
Two companies can do similar work.
One gets through cleanly, the other ends up in a painful back-and-forth.
It usually comes down to a few very fixable mistakes in how the project is described.

If you want your application to read like a credible Australian R&D tax incentive example, watch for these.

• Writing in outcomes only – “we built X” without explaining the technical uncertainty and how you tested it
• Calling normal development “experimentation” – doing work in sprints isn’t the same as testing a hypothesis
• Skipping the failed attempts – people worry it looks bad, but it often makes the claim stronger
• Lumping everything into one activity – it becomes impossible to see what was actually core R&D
• Claiming the whole build – when only a portion of the work was actually resolving technical uncertainty
• No evidence trail – even good R&D can look weak if you can’t show version history, tests, notes, prototypes

If any of those feel familiar, you’re not alone.
Most of the time it isn’t fraud or anything dodgy.
It’s just that people write like they’re updating a stakeholder, not like they’re explaining a technical investigation.
Different job.
Different standard.

The worked example below is designed to avoid those traps.
It’s written in the same sequence we use when we’re trying to make a claim defensible.

Alright – here’s the worked example (and what to pay attention to)

From here on, I’m going to walk through a worked R&D Tax Incentive example using the black box flight recorder.
Again – it’s fictional.
But the structure is the same structure we use for real claims in Australia.

As you read it, don’t get distracted by the industry.
Focus on the moving parts that make it “R&D” in the government sense.

• Where the technical uncertainty is stated clearly, early
• Where the hypothesis is specific enough to test
• Where the experiments are described as controlled trials, not general progress
• Where failures and iterations show the progression of work
• Where it becomes obvious what is core R&D versus normal development

If you can mirror that logic in your own project, you’re already ahead of most applications we see.
Because most people start writing at the “what we built” part, then try to reverse-engineer the uncertainty later.
That’s backwards.

Ok. Let’s step into the example.
First up – the technical challenges and why they weren’t straightforward.

Step 1 – Start with the technical challenges (not the product story)

This is where most R&D Tax Incentive examples fall over.
They open with a product pitch.
Or a company background.
Or a “market opportunity”.
None of that is what AusIndustry is assessing.

A strong application starts with the technical challenges – the specific things you were trying to achieve that weren’t straightforward, and weren’t already solved in your field.
In other words, the reason you had to test.

For the black box example, I’m going to spell out the challenges first.
Then we’ll turn those into a clear hypothesis and experiments.
That’s the sequence that keeps the story clean.

If you’re using this as a template for your own project, this is the part where you want to be really concrete.
Avoid “we wanted to innovate”.
Instead, write the actual constraint you were pushing against – accuracy, heat resistance, throughput, latency, durability, stability, safety, noise, compliance, whatever it is in your world.

Step 1 – Identifying the technical challenges

Every defensible R&D Tax Incentive example starts the same way.
You explain the technical challenge in plain English, and you make it obvious why it wasn’t a simple engineering exercise.
If someone can read your first few paragraphs and say “yeah, that’s just implementation”, you’re already in trouble.

In the black box example, the technical challenges weren’t about making a nice product.
They were about whether it could survive and still function under extreme conditions.
That’s the key difference.

Here were the main technical challenges driving the R&D:

• Crash durability – could the recorder survive impact, heat and pressure without destroying the storage medium
• Data reliability – could it capture accurate flight data and cockpit audio without corruption or drop-outs
• Miniaturisation – could we fit the required technology into a compact device without compromising durability or performance

Notice what’s happening here.
Each challenge has a measurable technical constraint, and none of them are “we wanted a better product”.
They’re “we don’t know if this will work in these conditions”.
That’s what technical uncertainty looks like in a real R&D claim.

If you’re reading this because you want to write your own R&D application, do a quick swap in your head.
What’s your equivalent of “crash durability”?
Maybe it’s latency at scale.
Maybe it’s yield.
Maybe it’s stability over time.
Maybe it’s strength-to-weight.
Same concept.
Different industry.

Step 2 – The hypothesis and the experiments (this is the part that proves it’s R&D)

This is the section that separates a real R&D Tax Incentive example from a nice story about building something hard.
Because “hard” isn’t enough.
You need to show you approached it like a technical investigation.

In practical terms, AusIndustry and the ATO want to see two things.

• A hypothesis – what you believed might work, and why it was plausible
• Experiments – how you tested that belief in a planned and measurable way

If your application jumps straight from “we had a problem” to “we built the solution”, it reads like normal development.
The missing piece is the testing that sits in the middle.

For the black box example, the hypothesis could be framed like this:

“We believe that by combining high-durability materials with a redesigned internal layout, we can create a flight recorder that withstands extreme crash conditions while still reliably capturing and storing critical flight and audio data.”

Then the experiments need to do the heavy lifting.
Not a list of tasks.
Actual testing.
So in this example, that looks like:

• Material tests – comparing different materials and seals for heat resistance, impact resistance, and waterproofing
• Prototype trials – building versions, breaking them, then redesigning based on what failed
• Data capture validation – testing whether recorded data remained accurate and retrievable after stress testing

The reason this works is it shows progression.
You’re not claiming you knew the answer.
You’re showing how you worked it out.
That’s what “systematic experimentation” looks like when it’s written properly.

Step 3 – Describing the R&D activities clearly (core vs supporting)

This is where the example turns into something you can actually model your own application on.
Because it’s not enough to say “we experimented”.
You need to describe the activities in a way that makes it obvious what was core R&D, what was supporting, and what was just normal build work.

A quick rule of thumb that keeps things clean:
Core R&D activities are the experiments that resolve the technical uncertainty.
Supporting activities are only claimable when they directly support those experiments.
Everything else might still be important work, but it’s usually not R&D for the incentive.

In the black box example, you can see that split pretty clearly:

• Core R&D – testing materials and designs to survive extreme conditions, then validating whether data remained intact
• Core R&D – crash and heat simulations to see what failed and why
• Supporting activities – building prototypes and setting up test environments so the experiments could happen
• Supporting activities – data capture trials to confirm the recording system performed under stress

When you write this section for your own project, aim for specificity.
What was tested.
What changed between versions.
What was measured.
What passed or failed.
That detail is what makes the application read like a genuine R&D tax incentive example, not a generic summary.

Step 4 – Outcomes matter, but not in the way most people think

Most people assume the R&D Tax Incentive is about proving you succeeded.
It isn’t.
It’s about proving you generated new knowledge through testing.
Sometimes that ends in a working solution.
Sometimes it ends in “well, that didn’t work, and here’s what we learned”.
Both can still be R&D.

This is also where a lot of applications accidentally shoot themselves in the foot.
They write the outcome like a marketing case study.
All wins, no setbacks, no iterations.
It reads like the result was obvious from day one.

In the black box example, the outcomes section should do three jobs:

• Show what changed between iterations – what you modified based on test results
• Be clear about failures – what didn’t work, and why it didn’t meet the technical requirement
• State the new knowledge – what you now know that you didn’t know at the start

If you’re using this as a template, don’t be afraid of writing about the messy middle.
The dead ends and failed prototypes are often the most believable part of the whole story.

Step 5 – Linking the story to the dollars (without making it messy)

Once the technical story is solid, the next question is simple.
What can you actually claim?

This is where a lot of people get nervous – and fair enough.
Because even if the R&D work is real, the ATO side is where claims often get clipped.
Not because anyone’s trying to do the wrong thing, but because the records don’t line up cleanly with the R&D activities.

The safest approach is to work backwards from the activities.
If an expense can’t be linked to the core or directly supporting activities, it’s usually where trouble starts.

For most businesses, the main buckets of R&D expenditure that need clean support are:

• Wages and salaries – time spent on eligible R&D activities, ideally supported by a reasonable time basis
• Contractors and external providers – clearly scoped to the eligible activities, with invoices that make sense
• Materials and consumables – used directly in prototyping, trials or testing
• Depreciating assets – where equipment is used in conducting the experiments

If you’re reading this because you want an example you can copy, this is the part you don’t want to copy blindly.
The categories might be similar, but the evidence needs to match how your business actually operates.

If you want a quick sanity check, the call is usually pretty simple.
We look at what you did, how it maps to core and supporting activities, and whether the records you have will stand up later.

If you’ve read this far, you’re already ahead of most applicants

If you’ve made it to the end, you’re not the “just lodge it and hope” type.
That’s a good thing.
Because the R&D Tax Incentive is rarely the problem.
It’s the way the claim is written and supported that usually causes pain later.

If you take one thing from this page, let it be this.
A good application reads like a technical investigation, not a project update.
Clear uncertainty.
Clear experiments.
Clear learning.
Then the costs line up behind it.

If you want, we can do a quick call and I’ll tell you where you sit.
Eligible, borderline, or not really.
And if you are eligible, I’ll point out what would make the claim stronger and more defensible.