The Australian R&D Tax Offset is a government incentive that provides companies with a cash refund or tax reduction for eligible research and development expenditure. For startups with under $20 million turnover, this can mean getting 43.5 cents back for every dollar spent on eligible R&D.

If you're running a software startup, this usually becomes urgent around EOFY. You've paid engineers, contractors, cloud bills, and product costs all year, and now you're trying to work out which work may qualify, what evidence you need, and whether your claim will stand up if someone reviews it later.

Table of Contents

• Your Guide to the Australian R&D Tax Offset
• What Is the R&D Tax Offset and Is My Startup Eligible
  • What counts as eligible activity
  • Where software teams usually get it wrong
• How Is the R&D Offset Calculated for Tech Startups
  • What the refundable offset means in practice
  • Which costs usually sit inside the calculation
• What Evidence Do I Need for a Software R&D Claim
  • What contemporaneous evidence actually looks like
  • A simple evidence stack for engineering teams
• What Is the Yearly Process for Claiming the Offset
  • The annual rhythm that works
  • What to do this week
• How Should I Choose an R&D Tax Adviser
  • The main service models
  • Questions worth asking before you sign
• What Are the Most Common Pitfalls and Compliance Risks
  • The mistakes that cause avoidable problems
• Your R&D Tax Offset Questions Answered
  • Can I claim if my startup is pre-revenue
  • Can I amend a prior year claim
  • What happens if AusIndustry or the ATO reviews the claim
  • Are there changes coming that founders should watch
  • Do I need an adviser

Your Guide to the Australian R&D Tax Offset

Most founders first look into the R&D tax offset when cash is tight and product development is expensive. That timing is normal, but it also creates bad habits. Teams leave records too late, treat all software work as R&D, or hand their adviser a pile of invoices and hope it all sorts itself out.

For Australian tech startups with aggregated turnover under $20 million, the incentive may provide a 43.5% refundable R&D tax offset, which is the company tax rate plus an additional 18.5% premium. For pre-revenue startups in a tax loss position, that can mean up to $435,000 cash refund for every $1 million spent on eligible R&D, as explained in this startup eligibility overview.

That's the upside. The trade-off is that the program rewards disciplined claims, not broad ones.

Practical rule: A narrower claim with strong records is usually safer than a wider claim built on vague descriptions.

Founders generally need to answer four questions early:

• Is the entity eligible? You need the right company structure and turnover profile.
• Is the work R&D? New product work isn't automatically experimental work.
• Can you prove it? Timesheets alone rarely tell the full technical story.
• Who will prepare the claim? The right process often matters as much as the tax position.

If you want a software-friendly workflow rather than a generic tax checklist, it helps to start with tools and evidence pathways that fit how your team already works. That's where modern platforms such as ClaimKit enter the conversation.

What Is the R&D Tax Offset and Is My Startup Eligible

The Australian program is designed for companies doing eligible research and development in Australia. At a practical level, that means your startup needs the right entity, enough eligible expenditure, and work that fits the legal definition of core or supporting R&D activities under the government guidance on the R&D Tax Incentive eligibility rules.

A quick visual helps before getting into the detail.

What counts as eligible activity

The minimum eligible R&D expenditure is AUD 20,000 per income year, and eligible activities must be classified as core R&D or supporting R&D under the official eligibility criteria. The same guidance also makes clear that software development for internal administration is excluded.

For software startups, the distinction matters:

The phrase that trips teams up is “generating new knowledge”. If your engineers are applying known patterns, standard libraries, and accepted architecture decisions to deliver a feature, that may still be strong engineering, but it isn't automatically claimable R&D.

Where software teams usually get it wrong

The biggest issue isn't usually effort. It's classification.

A startup may spend months building a difficult feature, but difficulty alone doesn't make it R&D. What matters is whether the team faced technical uncertainty and used a systematic process to test possible solutions.

Later in the process, it helps to hear someone walk through the distinction in plain English.

Three quick checks are useful before you invest time in a claim:

1. Unknown outcome
   Could the team show that capability, method, or performance wasn't known at the start?

2. Systematic work
   Did the team run experiments, comparisons, iterations, or technical tests rather than only carry out a roadmap item?

3. Direct linkage
   Can you separate the experimental work from delivery work, customer support, and BAU engineering?

If you can't point to the uncertainty, the hypotheses, and the test results, the claim usually gets weaker very quickly.

How Is the R&D Offset Calculated for Tech Startups

For eligible Australian companies with aggregated turnover under AUD 20 million, the refundable offset is 43.5%, calculated as the applicable tax rate plus an 18.5% premium, and refundable amounts are generally paid within eight to twelve weeks after lodgement of the company's income tax return, according to these R&D Tax Incentive statistics and offset details.

What the refundable offset means in practice

The easiest way to think about it is this. You don't get money back for total spend. You may get a refund or tax reduction based on the portion of spend that is both eligible and properly documented.

Take a simple software example. If a startup has $100,000 of eligible developer salary tied to qualifying R&D activities, a 43.5% refundable offset would translate to $43,500 if the company is eligible for the refundable treatment and the expenditure is accepted. The same logic means $200,000 of eligible spend would translate to $87,000.

That's why founders should be careful with internal planning models. The right number isn't “engineering payroll”. It's “documented eligible engineering payroll and related qualifying costs”.

Which costs usually sit inside the calculation

For tech startups, eligible expenditure often includes a mix of people costs and directly connected project costs. In practice, teams commonly assess items like:

• Employee wages for engineers and technical staff directly engaged in eligible work
• Contractor fees where the contractor arrangement fits the rules
• Cloud and hosting costs where they relate to the R&D effort
• Hardware depreciation, travel, and overheads where the connection is supportable through records

Those cost categories are outlined in this startup-focused explanation of eligible R&D expenditure.

A few boundaries matter just as much as the headline rate:

• The cap matters. The refundable framework doesn't apply without limit.
• The timing matters. Refunds aren't immediate cash on request. They follow registration, tax return preparation, and lodgement.
• The evidence matters. Weak substantiation can reduce the amount that survives review.

Commercial view: Treat the rd tax offset as a financing lever, but never as guaranteed operating cash.

Larger companies can fall into the non-refundable side of the regime, which works more like a tax reduction than a cash refund. For early-stage startups, the practical question is usually whether you fit the refundable profile and whether your activity records support the spend you're planning to include.

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

Most software claims hinge on the quality of evidence. The technical argument may be sound, but if the evidence is thin, reconstructed late, or disconnected from the codebase, the claim becomes much harder to defend.

That's not a theoretical problem. William Buck notes that 43% of Australian SME claims are rejected annually due to inadequate documentation distinguishing experimental software development from standard maintenance in its discussion of the documentation problem in R&D incentive claims.

What contemporaneous evidence actually looks like

For software teams, contemporaneous evidence means records created as the work happens, not months later when finance asks for support. Good evidence usually lives in engineering systems already in use.

Useful examples include:

• Jira or Linear issues showing the technical uncertainty, proposed approaches, and iteration history
• GitHub commits and pull requests showing what changed, who changed it, and when
• Notion docs or architecture notes capturing the problem statement, assumptions, and test outcomes
• Xero records and payroll files linking costs to the people and periods involved

A strong claim usually maps these records into a coherent narrative. It should show the experimental objective, the technical uncertainty, the sequence of work, and the expenditure connected to that work.

If your team needs a broader primer on what auditors tend to look for in documentation quality, this guide to audit evidence is worth reading because it explains the difference between records that merely exist and records that support a position.

A simple evidence stack for engineering teams

What works is rarely glamorous. It's usually a disciplined capture process and a sensible review loop.

Here's a practical setup founders can implement:

1. Tag candidate R&D work early
   Add a label in Jira or Linear for projects involving technical uncertainty. Don't wait until March or April.

2. Keep design intent close to the tickets
   A one-page note in Notion that explains what the team didn't know at the start is often more useful than a polished retrospective.

3. Link code to decisions
   Pull requests should reference the relevant issue or experiment thread.

4. Separate experimental work from routine work
   If the same engineer does platform maintenance in the morning and experimental work in the afternoon, your records should show that distinction.

5. Review monthly, not annually
   Finance and engineering should meet briefly each month to confirm what still looks claimable.

One option founders look at is ClaimKit consultants, particularly if they want AI-drafted claim materials, expert review, ATO lodgement support, and integrations with GitHub, Jira, Linear, Notion, and Xero in a single workflow. Traditional advisers can also work well, but the key is whether they can turn raw product data into evidence, not just write a narrative after the fact.

The best software claims read like a product development record, not like marketing copy rewritten for tax.

What Is the Yearly Process for Claiming the Offset

The claim process works best as a yearly operating rhythm, not a once-a-year scramble. Startups must register eligible activities with AusIndustry within 10 months after the end of their income year, and for a standard 1 July to 30 June year that deadline is 30 April of the following year, as outlined in this claim timing guide for startups.

The annual rhythm that works

A clean process usually looks like this across the year:

• Start of the financial year
  Identify which product or engineering streams may involve real technical uncertainty. Decide where evidence will live.

• During delivery
  Keep project notes, issue history, code activity, and cost records current. This is when the claim becomes easier or harder.

• After 30 June
  Reconcile the projects, strip out ineligible work, and match costs to the remaining technical activities.

• Before 30 April
  Finalise the AusIndustry registration for the relevant income year.

• With the tax return
  Apply the expenditure schedules and lodge through the normal tax process.

A lot of founders ask whether they can register before the work starts. They can't. The registration happens after R&D activities have commenced, not before, which catches teams that want to “pre-approve” everything.

What to do this week

If your records are patchy, don't start by drafting legal language. Start with operations.

If you're working with an external platform or adviser, review the service terms and process expectations before you hand over data. Founders save time when roles are clear early.

How Should I Choose an R&D Tax Adviser

Most startups don't need the cheapest adviser. They need the adviser whose process matches how the company builds software.

That's an important distinction. Some firms are strong on tax interpretation but weak on engineering evidence. Others move quickly but expect your team to do all the heavy lifting. The right choice depends on your internal capacity, your appetite for process, and how much of your claim depends on proving software experimentation rather than straightforward scientific work.

The main service models

A simple comparison helps.

Treadstone, Prime Partners, Link R&D Advisory, and Bulletpoint all sit somewhere in that broader market. Some founders prefer a traditional advisory relationship. Others want a system that pulls evidence directly from their stack and keeps drafts, schedules, and lodgement steps visible.

You can also review ClaimKit's background and operating model if you want an example of the connected-platform approach.

Questions worth asking before you sign

Don't ask only about fees. Ask how the work gets done.

• How do you identify eligible software work? If the answer is mostly interviews at year end, expect gaps.
• How do you handle GitHub, Jira, Linear, Notion, and Xero data? Manual copy-paste can become expensive fast.
• Who reviews technical narratives? You want subject-matter review, not just formatting.
• What will my team need to do internally? Good advisers reduce effort, but none eliminate it.
• How visible is the draft claim? Black-box processes make finance leads nervous for good reason.

A fair adviser comparison comes down to process fit. The more your claim depends on reconstructing engineering decisions, the more you should value evidence collection and transparency over glossy sales language.

What Are the Most Common Pitfalls and Compliance Risks

Most startup errors fall into one of two buckets. Either the team claims work that isn't really R&D, or it under-documents work that may have been eligible.

The mistakes that cause avoidable problems

The first trap is assuming all software development counts. It doesn't. Product engineering, integrations, bug fixing, internal tools, and customer-specific delivery can all be valuable work without meeting the R&D threshold.

The second trap is building evidence retrospectively. Founders often remember the problem accurately but can't show the sequence of experimentation in a way that matches dates, code history, and expenditure.

A third risk is contractor treatment. The Registered Service Provider exception is frequently misunderstood, and the ATO guidance notes a 28% rejection rate for claims involving third-party developers in 2025 where startups assumed contractor spend qualified without verifying the provider's status through the RSP eligibility rules for the R&D Tax Incentive.

Common trouble spots include:

• Routine work dressed up as experimentation
• Missing records for technical uncertainty
• Poor separation between R&D and BAU engineering
• Incorrect assumptions about third-party developer costs
• Turnover and entity issues picked up too late

For founders who want more practical reading on process failures and claim hygiene, the ClaimKit blog is a useful place to compare different documentation approaches.

Compliance mindset: If a reviewer opened your claim file tomorrow, would the evidence explain the work without your founder memory filling in the gaps?

Your R&D Tax Offset Questions Answered

The R&D tax offset can be a meaningful source of non-dilutive support for software startups, but only when the claim is built on actual technical uncertainty, disciplined records, and a preparation process that matches the way the company operates.

Can I claim if my startup is pre-revenue

Yes, eligible companies can still access the incentive even if they aren't profitable. The key issues are entity eligibility, qualifying activities, and whether the company fits the refundable side of the program.

Can I amend a prior year claim

In some situations, companies explore amendments or corrections, but the practical answer depends on timing, prior registrations, and what evidence exists for that period. If the records were never captured properly, an amendment may be more difficult than founders expect.

What happens if AusIndustry or the ATO reviews the claim

A review usually turns into a documentation exercise. The team may need to explain the technical uncertainty, the experimental steps, and how the expenditure schedule was built. Startups with organised issue history, code records, and financial support are usually in a much better position than those relying on memory.

Are there changes coming that founders should watch

Yes. Measures announced to commence on 1 July 2028 would increase the aggregated turnover threshold for refundable access from AUD 20 million to AUD 50 million, limit refundability to businesses operating for less than 10 years, raise the maximum eligible expenditure threshold from AUD 150 million to AUD 200 million, and lift the minimum expenditure threshold from AUD 20,000 to AUD 50,000, according to Baker McKenzie's summary of the planned 2028 R&D Tax Incentive changes. Those are future measures, not current rules, but they're worth tracking if you're planning beyond the next raise.

Do I need an adviser

Not always, but many software startups benefit from one because the hard part isn't filing a form. It's identifying eligible activity, mapping evidence from engineering tools, and preparing a claim that's technically coherent and financially supportable.

---

If you want a more structured way to prepare an R&D claim, ClaimKit gives startups a workflow that connects engineering and finance records, drafts claim materials using your existing tools, and routes everything through expert review before ATO lodgement.