If your Australian startup is spending real money on technical experimentation, the R&D Tax Incentive may let you recover part of those eligible costs through the tax system. For companies with aggregated turnover under $20 million, the current program offers a 43.5% refundable tax offset on eligible R&D expenditure, which often functions like cash back after lodgement.

A lot of founders reach this point after the same sequence. Payroll is growing, GitHub is busy, Jira is full, and the finance lead is asking whether any of that product spend is claimable. The short answer is often yes, but only when the work and the records line up with the rules.

The part most guides miss is this: software claims usually don't fail because the team did nothing technical. They fail because nobody translated modern engineering evidence into a clean, compliant R&D story. The founders knew what was hard. The ATO and AusIndustry still need to see why it was technically uncertain, how it was tested, and what costs tie back to that work.

Table of Contents

• What is the R&D Tax Incentive and Why Should Founders Care
  • Why startup founders care more than they think
• How Does the R&D Tax Incentive Actually Work
  • It's an offset tied to work and costs you can substantiate
  • Who handles each part
• How Do I Know If My Startup Is Eligible
  • What counts as core R&D in software
  • What usually counts as supporting R&D
• How Is the R&D Tax Incentive Calculated
  • Which costs are usually in scope
  • Where software teams get the maths wrong
• What Are the Steps to Lodge a Claim
  • What founders can do this week
  • What the two-stage process looks like
• What Records Do I Need for a Software R&D Claim
  • How to turn delivery records into claim evidence
  • What good evidence looks like in practice
  • Common gaps founders should fix early
• How Should I Choose an R&D Tax Advisor
  • What to compare before you sign
  • R&D Advisor Models Compared
• R&D Tax Incentive FAQs
  • Can a pre-revenue startup claim the R&D tax incentive?
  • Does a failed technical project still count?
  • Can we claim software work done by offshore developers?
  • Do we need timesheets for software claims?
  • Where can I keep learning about software-focused claims?

What is the R&D Tax Incentive and Why Should Founders Care

Founders usually ask about the R&D tax incentive Australia rules when burn starts to matter. You've hired engineers, your platform isn't off-the-shelf, and you're solving problems that can't be answered by copying a tutorial. At that point, this isn't a side issue. It's a financing and documentation issue.

The scheme is a tax offset, not a grant application you pitch for. That matters because eligible companies don't compete for a funding pool. They self-assess, register eligible activities, support the claim with evidence, and include the relevant tax components in the company return.

It's also not a niche program used by a tiny corner of the market. In 2023–24, 13,901 companies registered and reported $17.7 billion in estimated R&D expenditure, up from $12.7 billion in 2019–20, according to published Australian R&D incentive statistics. That tells founders two things. First, the program is mainstream. Second, regulators see a lot of claims, so vague narratives don't hold up well.

Why startup founders care more than they think

For an early-stage software company, the practical value isn't just the offset itself. It's what that offset can do to runway, hiring plans, and how aggressively you can keep pushing technical work.

A few situations where it matters:

• You're pre-revenue: The business may still be eligible if it is an R&D entity and the activities and costs qualify.
• You're raising: Investors often ask whether the company has a repeatable process for identifying and documenting eligible R&D.
• You've built custom infrastructure: Internal platform work can matter just as much as customer-facing features, provided it meets the legislative tests.

Practical rule: If your engineers are trying to resolve technical uncertainty, don't wait until tax time to reconstruct what happened.

A lot of this comes down to discipline. Teams that treat R&D claims as an afterthought often end up with generic descriptions like “improved platform performance” or “developed machine learning capability”. That language is too loose. Founders need a record that shows what problem existed, why the outcome couldn't be known in advance, and what the team did.

If you want context on how platform-led preparation fits into the broader market, ClaimKit's company overview is a useful reference point for how newer workflows differ from older consultant-led models.

How Does the R&D Tax Incentive Actually Work

A common founder mistake looks like this. The team ships a difficult backend rewrite over six sprints, closes the Jira epic, merges dozens of GitHub pull requests, and only months later tries to describe the work as “platform optimisation” for an R&D claim. By then, the technical uncertainty is harder to prove, the experiment trail is patchy, and finance is guessing which costs belong to which project.

The incentive works best when you treat it as a tax and evidence process, not a year-end writing exercise. The benefit is linked to eligible R&D expenditure, but the outcome turns on whether you can connect the technical story to records your team already creates.

It's an offset tied to work and costs you can substantiate

Founders often confuse the program with a grant model. That creates the wrong workflow. You do the work first, register eligible activities with AusIndustry, then claim the offset through the company tax return with the ATO.

For software companies, that means two things have to line up:

• the activity must meet the R&D tests under the law
• the expenditure must be traceable to that activity and apportioned on a sensible basis

That second point is where claims often weaken. A polished narrative does not help if payroll, contractor costs, cloud spend, or overhead allocations cannot be tied back to the relevant project work.

Who handles each part

A clean claim usually runs through four layers.

1. Engineering and product define the technical projects
   The question is not whether the feature was valuable to customers. The question is where the team faced technical uncertainty and worked through it in a systematic way.

2. AusIndustry receives the activity registration
   This is where the technical description matters. Good registrations explain the unknowns, the hypothesis or approach, the experiments or iterations performed, and the result.

3. The ATO reviews the tax position if needed
   Here the focus shifts to expenditure, apportionment, entity position, and whether the numbers in the schedule can be supported.

4. Your adviser or platform pulls the evidence into claim-ready form
   Good support maps engineering artefacts to the legal tests. In software claims, that often means linking Jira tickets, sprint notes, GitHub commits, architecture decisions, time data, and cost reports into a file that would make sense to a reviewer.

That is the practical gap many generic guides miss.

In a strong software claim, the story does not start with a marketing description of the product. It starts with a specific technical problem, the competent professional standard, what could not be known in advance, and what records show the team tried. A Jira workflow by itself is not enough. GitHub history by itself is not enough either. Together, with decisions, testing evidence, and cost mapping, they become much more useful.

Strong R&D claims are usually plain to read. Clear project boundaries and evidence created during delivery beat retrospective summaries every time.

If you are assessing a platform-led workflow, ClaimKit's R&D claim platform is an example of how software teams pull evidence from engineering and finance systems before expert review and lodgement.

How Do I Know If My Startup Is Eligible

A common founder scenario looks like this. The team spent six months building a new product capability, shipped it, and assumed the whole build would qualify. Then the hard part starts. Which tickets were experimental, which were routine delivery, and what records prove the difference?

Eligibility turns on activities, not product ambition. For software startups, the practical question is whether part of the work involved genuine technical uncertainty and a systematic process to resolve it. That is a narrower test than “we built something new for customers.”

Company structure matters too. The incentive is a tax offset claimed by eligible companies, and the outcome depends in part on the company's size and tax position. The exact rates and mechanics are better dealt with in the calculation section. At the eligibility stage, the useful question is simpler. Did the company carry out eligible R&D activities, and can it show what happened with contemporaneous records?

What counts as core R&D in software

In software claims, core R&D usually sits where competent engineers could not determine in advance whether a technical objective was achievable, or which approach would work, without testing and evaluation.

That is where modern dev records become useful.

A Jira epic called “build recommendation engine” is not enough on its own. A stronger file shows the uncertainty the team faced, the options considered, the work performed to test them, and the result. In practice, that often means tying Jira tickets to GitHub commits, architecture notes, incident logs, test results, and release records.

Work that may point toward core R&D includes:

• Performance uncertainty: The team is trying to hit latency, throughput, or scaling targets that standard patterns did not reliably meet in the production environment.
• Algorithm or model uncertainty: Engineers are testing whether a proposed method can achieve acceptable technical performance under real constraints such as data quality, compute limits, or response time.
• Complex systems behaviour: Known tools or components interact in ways that create unresolved technical behaviour, and the team must test alternatives to determine a workable solution.

By contrast, straightforward implementation usually does not become core R&D just because the feature matters to the roadmap. If the team already knew how to build it using established methods, it is usually delivery work, not eligible R&D.

What usually counts as supporting R&D

Supporting activities can still be included where they are directly related to the core R&D activity.

For software teams, that may include test environment setup, technical analysis linked to the experiment, certain forms of data preparation, or engineering work that exists because the experimental activity exists. The connection needs to be clear. This is one of the first places weak claims fall apart under review.

Routine QA, customer-specific configuration, standard maintenance, general product management, and ordinary bug fixes are often outside scope. The label on the ticket does not decide the issue. The purpose of the work does.

The better founder question is: what did the team not know at the start, how did they test it, and which delivery records show that path?

A practical test for founders is to pick one project and review it backwards from the evidence. Can you point to the technical objective, the uncertainty, the hypotheses or alternatives considered, the experiments run, and the outcome? Can you match that story to the records your team already keeps in Jira, GitHub, sprint notes, and time or cost data? If not, the work may still be eligible, but the claim will be harder to defend.

If you want a deeper checklist built for software founders, this eligibility guide for startups is a useful next read.

How Is the R&D Tax Incentive Calculated

Once a startup has identified eligible activities, the next question is usually more direct: what expenditure can reasonably be included, and how does that flow into the offset?

The current rates didn't always look like this. On 1 July 2016, the original 45% refundable and 40% non-refundable offsets were reduced by 1.5 percentage points to 43.5% refundable and 38.5% non-refundable. Under the current rules, companies with aggregated turnover below $20 million can access the refundable offset, while larger firms use the non-refundable offset, as summarised in this program history reference.

Which costs are usually in scope

For software startups, the biggest cost categories often include employee wages connected to eligible R&D activities, relevant contractor costs, and portions of overheads that can be reasonably apportioned.

Common categories founders review:

• Developer and engineering salaries: Only the portion tied to eligible R&D activity is generally relevant.
• Technical contractor costs: These need careful treatment and clear links to the work performed.
• Cloud and tooling costs: Sometimes relevant, but only where the connection to the eligible activities is supportable.
• Overheads: These are rarely a simple “claim everything” exercise. Apportionment needs to be sensible and documented.

The practical formula founders use first is often rough but useful:

Eligible salary costs + eligible contractor costs + eligible overhead apportionment = total eligible R&D expenditure
Then apply the relevant offset rate for your entity type.

That first estimate helps finance decide whether the claim is material enough to prioritise properly.

Where software teams get the maths wrong

The errors usually aren't arithmetic. They're scope and evidence errors.

Typical problems include:

1. Treating the whole roadmap as R&D
   Commercial product delivery nearly always contains a mix of eligible and ineligible work.

2. Using role titles instead of actual effort
   A CTO or senior engineer may spend time across fundraising, hiring, architecture, delivery, and support. Titles don't determine claimable effort.

3. Forgetting cost narratives must match technical narratives
   If the project description says the uncertainty sat in one area, but the costs are loaded into unrelated workstreams, that inconsistency weakens the claim.

If your financial schedule can't be traced back to actual engineering activity, the problem isn't the spreadsheet. It's the evidence chain.

A founder doesn't need perfect precision on day one. But they do need a defendable method. That usually means mapping people, projects, and systems before anyone starts drafting percentages from memory months later.

What Are the Steps to Lodge a Claim

Lodging a claim feels more manageable once you separate it into two tracks. One is about registering the R&D activities. The other is about claiming the tax benefit.

The official business.gov.au overview of the Research and Development Tax Incentive is the best single public reference for the program and the agencies involved. Founders should keep that page handy because it anchors the process to the actual government workflow rather than blog summaries.

What founders can do this week

Before worrying about forms, do these practical tasks:

• List candidate projects: Pull the epics, initiatives, or technical workstreams that involved unresolved technical problems.
• Nominate one owner: Usually the CFO, finance lead, founder, or operations lead coordinates inputs across engineering and tax.
• Lock your evidence sources: Decide whether Jira, Linear, GitHub, Notion, Slack summaries, payroll files, and invoices are the systems you'll rely on.
• Create a claim folder: Keep exported records, payroll reports, contracts, architecture notes, and meeting documents in one place.
• Mark overseas work early: If any meaningful part of the technical work happened outside Australia, flag it immediately for review.

Those steps sound basic, but they prevent the most common EOFY scramble. By the time the team starts drafting the technical narrative, nobody should be hunting through old chats trying to remember what happened.

What the two-stage process looks like

The lodgement path usually works like this:

1. Register the R&D activities with AusIndustry
   This is the technical side. You describe the activities, the uncertainties, and the experimental progression.

2. Prepare the expenditure position
   Finance maps relevant salaries, contractor costs, and other eligible expenditure to those activities using a supportable method.

3. Lodge the tax components with the ATO through the company return
   The tax effect of the claim is reflected here.

4. Retain records in an audit-ready format
   Don't treat submission as the end. It's the point at which your evidence pack should already be organised.

A lot of founders leave this too late because they think the hard part is the form. It isn't. The hard part is assembling a coherent file where the technical narrative, the cost schedule, and the underlying records all agree.

If you want procedural help on the mechanics of documents, workflows, or platform support, the ClaimKit help centre is useful for seeing what a guided process can look like in practice.

What Records Do I Need for a Software R&D Claim

A software founder gets asked for evidence six months after year end. The team clearly did hard technical work, but the claim is now hanging on whether anyone can trace the uncertainty, the experiments, and the costs back through Jira, GitHub, payroll, and contractor files.

That is the fundamental record-keeping problem for software claims. Engineering systems are built to ship product. R&D claims need those same systems to show something more specific: what technical uncertainty existed, what the team tried, what happened next, and who incurred the cost.

As noted earlier, the legal test turns on the character of the activities and whether the company can substantiate them. For software companies, that usually means translating ordinary delivery records into a file that an advisor, reviewer, or auditor can follow without filling gaps from memory.

How to turn delivery records into claim evidence

The strongest software claims do not rely on a polished narrative written after the fact. They rely on contemporaneous records that already exist, then map them properly.

Useful sources usually include:

• Jira or Linear: tickets, sprint history, issue links, comments, labels, status changes, and assignees
• GitHub: commits, pull requests, branches, code review discussion, release tags, and deployment history
• Notion or internal docs: architecture notes, design options, failed approaches, meeting notes, and technical decisions
• Xero, payroll, and timesheets: salary support, super, and timing of expenditure
• Contracts and invoices: scope of work, technical deliverables, contractor identity, and billing periods

The practical test is simple. Can you pick one claimed activity and produce a clean trail from problem, to experiment, to result, to cost?

A useful way to structure that trail is below:

Many software claims often weaken at this point. A Jira ticket saying “improve performance” is not enough on its own. A stronger record explains the specific bottleneck, links to the branch or pull request where an approach was tested, and shows whether the result solved the issue or led to another iteration.

What good evidence looks like in practice

Good evidence has dates, names, and enough technical detail to show why the work was not routine.

For example:

• A ticket describing an attempt to reduce latency in a high-load workflow, linked to pull requests, benchmark results, and follow-up comments after the first approach failed.
• A design note recording why standard vendor documentation did not resolve the scaling issue in the company's environment.
• GitHub history showing multiple iterations on a model pipeline, with review comments explaining why earlier implementations were rejected.
• Payroll records that line up with the engineers named in those records for the relevant period.
• Contractor invoices that refer to the actual technical work performed, not generic “software development services”.

Software teams using modern tools already have much of this. The problem is usually fragmentation. Evidence sits across issue trackers, repos, chat, docs, and finance systems, and nobody has stitched it together into a claim-ready record set.

That broader discipline matters outside the Australian context too. This guide to digital record keeping for UK businesses is useful for the underlying principle: records that are scattered, vague, or reconstructed late cost more to defend.

Common gaps founders should fix early

The recurring issues are usually predictable.

• Tickets describe features, not uncertainty. Product language needs to be supplemented with technical context.
• Commits are too cryptic. “fix bug” or “refactor” tells a reviewer very little.
• Contractor files are thin. If the contractor did genuine R&D work, the paperwork needs to show what they did.
• Finance and engineering records do not align. The people in the technical story should match the expenditure schedule.
• Evidence only exists in Slack. Useful context can live there, but claims should not depend on informal chat threads as the main record.

I usually tell founders to review this before lodgement drafting starts. If the file cannot show uncertainty, progression, and cost linkage for each major activity, the claim needs more work before anyone writes the final narrative.

Some teams now use connected workflows to reduce manual reconstruction. ClaimKit's privacy and platform information explains one example, where records from tools like GitHub, Jira, Linear, Notion, and Xero are brought together so draft claim materials can be assembled for expert review and lodgement support.

A short product walkthrough makes that workflow easier to visualise:

The point is not that every startup needs another platform. The point is that software R&D claims stand up better when the evidence trail is built from the systems the team already uses, then organised in a way that matches the rules.

How Should I Choose an R&D Tax Advisor

Most founders don't just need technical tax knowledge. They need a process that fits how their company works.

That's where advisor selection matters. Some firms are built around partner-led consulting and manual workshops. Others use software to gather evidence first, then layer expert review on top. Neither model is automatically right. The better fit depends on your team, records, complexity, and appetite for hands-on involvement.

There's also a timing angle now. Recent budget coverage says the refundable turnover threshold is proposed to rise from AUD 20 million to AUD 50 million, and the minimum expenditure threshold from AUD 20,000 to AUD 50,000, but these reforms are not expected to take effect before 1 July 2028, according to Baker McKenzie's budget summary. That means startups near the current thresholds may need more careful planning over the next few years rather than assuming today's settings will stay unchanged forever.

What to compare before you sign

Start with process, not price.

Ask each advisor:

• How do you identify eligible activities? If the answer sounds like broad product summaries, keep digging.
• How do you test documentation quality? You want a methodology, not a promise.
• How do you map engineering records to expenditure? This is the centre of most software claims.
• Who reviews the technical narrative? General tax capability isn't the same as software R&D judgement.
• What happens if records are thin? Good advisors narrow, qualify, or defer parts of a claim. Weak ones overreach.

An advisor earns their fee when they tell you what not to claim.

It's also fair to compare market options by model. Traditional firms such as Treadstone, Prime Partners, Link R&D Advisory, and Bulletpoint may suit companies that want a more service-led engagement. Platform-led services can suit startups that want more transparency and tighter integration with engineering tools.

R&D Advisor Models Compared

If you're assessing consultant networks or referral options, ClaimKit's consultant information is one example of how newer providers structure expert review around a software-led process.

R&D Tax Incentive FAQs

Can a pre-revenue startup claim the R&D tax incentive?

Yes, a pre-revenue company may still be eligible if it is an R&D entity, undertakes eligible activities, and can support the expenditure and documentation. Revenue itself isn't the core test. Activity eligibility and substantiation are.

Does a failed technical project still count?

It may. Failure doesn't automatically disqualify a claim. In fact, many legitimate R&D activities involve experiments that don't produce the hoped-for result. What matters is whether the work involved genuine technical uncertainty and a systematic progression of work, not whether the project became a commercial success.

Can we claim software work done by offshore developers?

Generally, overseas work is a high-risk area and is usually ineligible unless the appropriate overseas finding has been obtained. Founders should isolate this early rather than blending it into the broader engineering narrative.

Do we need timesheets for software claims?

Not always in a rigid sense, but you do need a supportable way to show who worked on eligible activities and to what extent. Jira history, GitHub activity, sprint planning records, payroll reports, and contractor records often form part of that picture. Reconstructed estimates without underlying support are much weaker.

Where can I keep learning about software-focused claims?

If you want more practical guidance beyond the broad government summaries, the ClaimKit blog covers software R&D documentation, eligibility questions, and claim preparation issues in more operational detail.

---

If you're preparing an R&D claim and want a cleaner way to turn GitHub, Jira, Linear, Notion, and Xero records into draft claim documents with expert review before ATO lodgement, ClaimKit is one option to explore. It's built for software teams that want a more structured process than the usual spreadsheet-and-email scramble.