How the R&D Tax Incentive Applies to Software Development Companies

Welcome. If you run a software business in Australia, there’s a good chance you’ve heard of the R&D Tax Incentive — and an equally good chance you’re not entirely sure whether your work actually qualifies. In this video we’ll clear that up. We’ll look at exactly what kinds of software development are eligible, what aren’t, and how to claim correctly. I’m from the advisory team at Quantum House Australia, accountants and tax advisers, and we work with software companies of every size on precisely this question.

Here’s our plan for the next quarter of an hour. We’ll start with why this matters for tech businesses, and the figure that’s at stake. Then we’ll get to the heart of it — the core test of technical uncertainty — and use that to separate what qualifies from what doesn’t. We’ll cover the principle that catches most people out: claiming only the eligible portion of a project. We’ll look at the difference between core and supporting activities, the documentation your developers should keep, and an important point about who funded the work. Then a worked example, the common pitfalls, and how a claim actually comes together.

Let’s start with why this matters. Technology is one of the most active sectors in the entire R&D Tax Incentive programme. The incentive can return up to forty-three and a half per cent of your eligible R&D spend, and for a company investing ahead of profit, that can arrive as a genuine cash refund — money you can put straight back into hiring and building. But here’s the tension, and it cuts both ways. Some software businesses claim work that was never eligible, and find themselves exposed when the ATO looks closely. Others — and this is just as common — do genuinely qualifying R&D but never claim it, because they assume the incentive is only for people in lab coats. The reason both happen is the same: software businesses struggle to find the line between eligible and ineligible work, because so much of what feels innovative is, in the legislative sense, actually routine. And the ATO knows it — they’ve sharply increased their scrutiny of software claims in recent years. So the prize is real, but the boundary is everything, and that’s what the rest of this video is about.

Everything comes down to one concept: technical uncertainty. For an activity to qualify as core R&D, three things must be true. First, the outcome could not have been known in advance by a competent professional in your field. Second, the work is a systematic progression — a structured investigation, not trial and error. And third, it’s designed to generate new knowledge. The mental model to hold onto is the experimental cycle: you form a hypothesis, you run an experiment to test it, and you evaluate the result — which produces new knowledge, whether the experiment succeeded or failed. In software terms, that might look like hypothesising that a particular data structure could cut query latency below a threshold nobody had achieved, building a prototype to test it, and measuring the result. If you can’t frame your work that way — a real question, a test, and a finding you couldn’t have looked up — it probably isn’t core R&D.

So what kind of software work does qualify? A few common examples. Developing a novel algorithm, where the performance — or even the feasibility — isn’t known in advance. Creating a new machine-learning model that involves genuine research uncertainty: not just training an off-the-shelf model on your data, but where the approach itself is unproven. Building a new system architecture to solve a scalability or performance challenge that has no known solution. Or developing genuinely new APIs or integration frameworks. In every one of these, the common thread is the same — you need a documented hypothesis, a systematic approach to testing it, and recorded outcomes, including the experiments that didn’t work.

Now the other side — and this is where a lot of first-time claimants go wrong. Building software to a known specification doesn’t qualify, even if it’s a big build. Customising an existing software package doesn’t qualify. User-interface design and testing — no. Bug fixes and routine maintenance — no. Software developed where the commercial objective is the real driver, and any technical novelty is incidental — generally no. And the project management and administration around the work — also no. The trap is to assume that because something was hard, or new to your team, it must be R&D. If a competent professional could have predicted the outcome, it’s not technically uncertain — and it’s not R&D.

Here’s one of the most important principles in the whole video. Most real software projects are a mix — some genuine experimentation, wrapped in a lot of ordinary development. And you can only claim the experimental portion, not the whole project budget. This is the single most common overclaim error: a business takes its total development spend for the year and claims the lot. To do it properly, you identify the specific experimental activities inside the project, you apportion your costs — salaries, contractors, materials, and a reasonable share of overheads — to just those activities, and you document the basis for that split. In practice that often means looking at where your developers’ time actually went: the weeks spent proving out the uncertain module are claimable; the months spent on the standard build around it are not. Done well, that apportionment is what separates a defensible claim from a risky one — and it’s usually the difference between a claim that sails through and one that draws questions.

Within the eligible portion, there’s a further distinction the legislation draws: core versus supporting activities. Core activities are the experimental work itself — for instance, testing whether a novel algorithm can actually hit a performance target whose outcome is genuinely unknown. Supporting activities are things you do directly to assist that core experiment — building a test harness, or preparing datasets specifically for the experiment. Both can be claimed, but they’re treated differently, and a classic mistake is to lump everything in as ‘core’. That’s a review trigger. Be precise about which activity is which.

I’ve mentioned documentation a few times, so let’s be specific about what your development team should actually keep — because the ATO requires contemporaneous records, made at the time the work happens, not written up at year-end. For a software company that typically means: technical design documents; your sprint logs and planning notes; code repositories with annotated commits that show what was being tried; test results, including your failure records; and meeting notes that capture the technical challenges you were grappling with. The good news is that most of this is a by-product of how good engineering teams already work — you’re rarely starting from nothing. The key is to capture the why, not just the what: a commit message that says ‘tried approach B because approach A couldn’t hold throughput’ is worth far more to a claim than one that just says ‘fixed sync’. Here’s the hard truth: in a review, a claim without this evidence is extremely vulnerable — no matter how genuinely innovative the underlying work was. The work being real isn’t enough; you have to be able to show it.

There’s one more eligibility point that surprises people, and it’s about who paid for the work. If your R&D was funded by a third party — for example, you built the software under a client contract — that work may not be eligible for you to claim. The principle is that to claim, you generally need to bear the financial risk of the R&D, and you typically need to own, or have the right to exploit, the results. So if a client is paying you to build something and they carry the risk, that work is usually theirs to claim, not yours. The flip side is worth knowing too: if you’re developing your own product, on your own dime, and you bear the risk if it fails — that’s exactly the position the incentive is designed for. Before you assume a project is claimable, check the contract terms and who really carried the risk — this point catches a lot of agencies and development shops out.

Let’s make all of this concrete. Picture a company that spends five hundred thousand dollars over a year building a new SaaS platform. Most of that — the user interface, the standard database work, the third-party integrations — is ordinary development. Let’s say that’s three hundred and fifty thousand dollars, and none of it is eligible. But one module is different: a novel, real-time conflict-resolution engine, where the team genuinely didn’t know whether their approach would work. That experimental module cost a hundred and fifty thousand dollars. Only that hundred and fifty thousand is eligible — and at forty-three and a half per cent, that’s a refundable offset of around sixty-five thousand dollars. Notice what we did: we didn’t claim the five hundred thousand. We claimed the part that was genuinely R&D. That discipline is exactly what keeps a claim safe. And, as always, this is illustrative — every claim turns on its own facts.

Let me gather the pitfalls in one place, because they recur. First, claiming the whole project instead of just the experimental portion. Second, thin evidence of technical uncertainty — if you can’t articulate what was uncertain, the claim is weak. Third, confusing core and supporting activities. And fourth, assuming that because a product is commercially valuable, its development is automatically eligible. It isn’t — commercial value and technical uncertainty are completely different things. Every one of these is avoidable with the right approach from the start.

So how does a claim actually come together? Four stages. First, an eligibility assessment — we review your development activities and identify what genuinely qualifies. Second, we work alongside your technical team to identify and document the qualifying activities, in their language and with their evidence. Third, we prepare and lodge the AusIndustry registration — and remember, that has to be in within ten months of your year-end. And fourth, we include the claim in your company tax return, with the documentation structured to withstand review. Done in that order, with care at each stage, the process is genuinely manageable.

If you remember nothing else, remember these. Eligibility hinges on genuine technical uncertainty. Only the experimental portion of a project qualifies. Distinguish core from supporting activities. Keep contemporaneous technical records. Check who funded the work before you claim. And never assume that commercial value equals eligibility. Get those six right and you’re most of the way to a solid claim.

This is where Quantum House Australia comes in. We’re specialist R&D Tax Incentive accountants and tax advisers, and we work with software companies of every size. We start with a thorough eligibility assessment of your development activities — separating what qualifies from what doesn’t. We then work directly alongside your engineering team to identify and document the qualifying work, prepare your AusIndustry registration, and include the claim in your company tax return — with documentation built to withstand review. And if a claim is ever reviewed, or you have a matter that needs legal input, we can call on our colleagues at Australian Tax Experts — tax advisers and lawyers — so the accounting and the legal sit together in one place.

So here’s the question to leave you with: is your software team solving problems that have no known solution? If the answer is yes — or even maybe — you could have an eligible R&D claim, and it’s worth finding out. Quantum House Australia offers an obligation-free initial assessment. Visit quantumhouse-dot-com-dot-au, or call our Sydney office on one-three-hundred, eight-oh-nine, six-nine-seven. Thanks for watching — Quantum House Australia, accountants and tax advisers, setting a new standard.