Building new technology is expensive before it is profitable. You are paying engineers, running tests, rebuilding features and solving problems that may not have an obvious answer – all while protecting runway. This guide to R&D tax claims explains how Australian startups can approach the R&D Tax Incentive with the discipline it deserves, without turning it into another founder admin project.

The opportunity can be meaningful, particularly for businesses investing heavily in software, engineering, biotech, advanced manufacturing or data-led product development. But a claim is not a reward for being innovative. It is a tax incentive for eligible experimental activity, supported by evidence. That distinction drives almost every successful claim.

What the R&D Tax Incentive is designed to support

The Australian R&D Tax Incentive is intended to encourage companies to take genuine technical risks. In plain English, the work needs to involve resolving scientific or technological uncertainty through a systematic process of experimentation.

For a startup, this might mean testing whether a machine-learning model can achieve a required level of accuracy with limited training data. It could mean developing a novel method of processing a difficult material, or determining whether a new software architecture can meet strict performance, security or scalability requirements where the answer was not already known.

The key question is not whether the product is new to your business or new to the market. It is whether competent professionals could have known the outcome in advance, based on publicly available knowledge. If the answer was uncertain and your team designed and assessed experiments to resolve it, you may have eligible R&D activity.

The incentive is generally delivered through a tax offset. Eligible companies with aggregated turnover below $20 million may qualify for a refundable offset, calculated at the company tax rate plus 18.5 percentage points. That can make the program particularly valuable for pre-profit startups. Larger companies can access a non-refundable offset, with the benefit linked to their R&D intensity.

The precise outcome depends on your company structure, turnover, tax position and expenditure. It is worth modelling the expected benefit before treating it as committed cash in your forecast.

A guide to R&D tax claims: start with the activity, not the costs

A common mistake is collecting a pile of payroll and contractor invoices, then trying to make them fit an R&D narrative at year-end. Start at the other end. Identify the technical problem, the uncertainty, the hypotheses and the experiments undertaken to test them. Then map costs to those activities.

Eligible work is broadly divided into core R&D activities and supporting R&D activities. Core activities are experimental activities whose outcome cannot be known or determined in advance on the basis of current knowledge, and which are carried out to generate new knowledge. Supporting activities are directly related to those core experiments.

For example, a SaaS business building a new reporting dashboard is unlikely to qualify simply because it required development effort. Standard implementation, user interface design, routine coding and configuration are usually business-as-usual product development. But if the team is testing competing approaches to solve a genuine data-processing limitation that existing methods cannot resolve, parts of that work may be eligible.

This is where founders need to be candid. Most product roadmaps contain a mix of qualifying and non-qualifying work. The aim is not to claim every development dollar. It is to identify the experimental component accurately and build a defensible connection between the work performed and the expenditure claimed.

The evidence that makes a claim credible

Good R&D records are not glossy innovation reports created after the fact. They are the practical working documents your team used while trying to solve the problem.

Your evidence should show what you were trying to achieve, why the outcome was uncertain, what alternatives you considered, how you tested them, what happened and what you learned. Engineering tickets, design notes, experiment plans, test results, repository history, technical meeting notes and time records can all help tell that story.

For each project, write a short technical narrative in language a smart non-specialist can understand. It should cover the baseline capability, the unknown, the hypothesis, the experimental method and the findings. Avoid vague claims such as “developed a world-first platform” or “used cutting-edge AI”. Specificity matters more than buzzwords.

Time tracking deserves particular attention. Salaries are often the largest component of an R&D claim, but a developer’s full year is rarely spent on eligible work. Use contemporaneous records where possible, supported by project allocation, calendars, sprint documentation and manager review. A reasonable method is better than a perfect-looking number with no evidence behind it.

Which costs may be included?

Once activities have been assessed, eligible expenditure may include a proportion of employee salary costs, contractor costs, prototype materials, cloud and software costs used in R&D, and certain overheads. Depreciating assets and overseas activity have additional rules, while some overseas work may require approval before it is undertaken.

There are also traps. Marketing, fundraising, customer support, ordinary quality assurance, commercial production, routine bug fixing and research conducted outside Australia are not automatically eligible. Neither are costs merely because they relate to a product that contains R&D.

Payments to associates require care, as the timing of deduction and payment can affect eligibility. Connected entities, grants, government recoupments and R&D conducted for customers can also change the calculation. If your startup is part of a group, has overseas developers or receives non-dilutive funding, get the structure reviewed early rather than assuming a standard approach applies.

The deadline founders should put in the calendar now

Registration is a separate step from lodging your company tax return. For companies with a 30 June year-end, an application to register eligible R&D activities is generally due by 30 April following the end of that income year. A late application may be possible in limited circumstances, but it is not a deadline to treat casually.

Registration is not the same as the government endorsing every dollar in the claim. It tells the relevant department about the activities you intend to claim. The tax offset is then claimed through your company tax return and R&D schedule.

Build the process into your annual finance calendar. A practical rhythm is to identify potential projects at the start of the financial year, review evidence quarterly, conduct a detailed eligibility assessment after year-end, register by the deadline and finalise the tax return once costs have been reconciled.

This approach also improves cash-flow planning. The R&D benefit may be valuable, but timing depends on registration, tax return lodgement, assessment and any questions raised along the way. Do not spend it before it lands.

A practical internal process for lean teams

You do not need a dedicated tax department to manage this well. You do need ownership. Usually, the CTO or technical lead owns the technical narrative, while finance owns cost extraction, payroll reconciliation and the tax return process. The founder or CFO should challenge assumptions, make sure the claim matches the company’s commercial reality and sign off on risk.

At the end of each quarter, ask three questions: What technical uncertainties are we actively trying to resolve? What experiments have we run and what did we learn? Which people and costs were directly involved? A 30-minute review while the work is fresh can save days of reconstruction later.

Keep the R&D project register separate from your broader product roadmap. Your roadmap records what the business wants to ship. The R&D register records where the team could not know the answer upfront and had to test its way forward. They will overlap, but they are not the same document.

When to bring in specialist support

The right time to seek help is before registration, not after a claim has been drafted around a target refund. A specialist can pressure-test whether projects meet the legislative definition, interview technical staff, identify evidence gaps and coordinate the technical and tax components of the claim.

That does not mean outsourcing your judgement. Founders and technical leaders remain the people who know what was actually attempted, why it was difficult and whether a claimed activity was genuinely experimental. The best advisers make that knowledge clearer and more defensible rather than putting generic language around it.

Startup Nerd can bring finance, tax and technical claim coordination into one working process, which is useful when a fast-moving team does not have spare capacity to manage multiple advisers. The priority is a claim that supports your runway without creating a compliance headache for future you.

Treat R&D as a disciplined record of technical learning, not a retrospective funding exercise. When your documentation follows the work as it happens, your claim becomes easier to prepare, easier to explain and far more useful in the financial plan that keeps your startup moving.