A successful R&D Tax Incentive application usually comes down to two things: registering eligible activities within 10 months of your financial year-end and lodging the tax claim with the ATO, supported by contemporaneous evidence from the tools your team already uses. If you're a software startup, the strongest claims often aren't built from memory at EOFY. They're built from Jira tickets, GitHub commits, technical notes, and clean finance records captured as the work happens.

If you're building product, hiring engineers, closing customers, and trying to make sense of the R&D Tax Incentive at the same time, the process can feel harder than it should. The upside is big enough that it's worth taking seriously. For companies with aggregated turnover under AUD 20 million, the refundable offset is tied to the company tax rate plus an 18.5 percentage point premium, which the OECD describes as equivalent to a 43.5% refundable tax offset at a 25% company tax rate, and the annual eligible R&D expenditure ceiling is AUD 150 million in OECD guidance on Australia's R&D support settings.

What trips most founders up isn't the idea of R&D. It's the translation layer between agile software work and a compliant claim. That's where discipline matters. Good claims don't just say the team worked on something difficult. They show the uncertainty, the experiments, the failures, the decisions, and the spend trail.

If you want context on how this kind of workflow is being built into modern claim preparation, ClaimKit's background gives a useful snapshot of the platform-driven model now emerging alongside traditional advisers.

Table of Contents

• Your Guide to the R&D Tax Incentive Application
  • What founders usually get wrong
  • What to do this week
• Are We Actually Eligible for the R&D Tax Incentive
  • A founder level eligibility check
  • Core and supporting activities in software teams
• What Evidence Do We Need from Our Tech Stack
  • What good evidence looks like in practice
  • How to organise evidence before EOFY pressure hits
• How Do We Write the Technical and Financial Narrative
  • Turning engineering work into project descriptions
  • Linking costs to activities without guesswork
• How Do We Lodge the Application and What Are the Timelines
  • The two stage lodgement path
  • R&D Application Approaches Compared
• What Common Pitfalls Cause Startup Claims to Fail
  • The mistakes that show up again and again
• R&D Tax Incentive Application FAQs
  • Can software development qualify as core R&D activity
  • What counts as a supporting activity in a startup claim
  • What if our records are messy but the work was real
  • Where can we read the government overview

Your Guide to the R&D Tax Incentive Application

A common startup pattern goes like this. The company has shipped hard technical work across the year, the CFO asks about the R&D Tax Incentive in June, and engineering is then expected to reconstruct months of uncertainty, experiments, and staff time from memory. That is where claims get weak.

A good application starts much earlier and uses records your team already creates. For software startups, the strongest claims usually come from a clean chain between Jira or Linear tickets, GitHub pull requests, architecture notes in Notion, and finance records that show who worked on what. If those systems already reflect the problem, the experiments, and the outcome, the application becomes far easier to defend.

The process itself is straightforward. You register eligible activities through the R&DTI Customer Portal, then claim through the tax return process with the ATO. What usually determines whether the claim stands up is not the form. It is whether the technical story and the underlying evidence match.

That is why this deserves founder attention, not just a year-end handoff to finance. The cash impact can be material, and the review risk is real. Teams that treat the claim as an evidence exercise from day one are in a much better position than teams trying to write a polished story after the fact. The ClaimKit team working with software startup R&D claims sees this pattern constantly.

What founders usually get wrong

Startup founders usually miss the claim in three places.

• They treat all software work as eligible. Some software development qualifies. Routine feature delivery, debugging, migration work, and standard integration work often do not.
• They assume the write-up can happen later. It can, but the quality drops fast when the team is relying on memory instead of contemporaneous records.
• They expect the adviser to fill the gaps. An adviser can structure the application and pressure-test the logic. They cannot create evidence your systems never captured.

Practical rule: Build the claim the same way you would prepare for diligence. An external reviewer should be able to trace the technical problem, the experiments run, the result, and the related costs without guesswork.

What to do this week

Pick one project that felt technically uncertain, even if it was not the biggest commercial priority. Then test whether your existing stack already holds enough evidence to support it.

Start with:

1. Jira or Linear issues that show the problem definition, proposed approaches, blockers, and test work.
2. GitHub pull requests that show branches, iterations, rejected options, and implementation changes.
3. Notion or internal docs that record hypotheses, design decisions, and what the team learned.
4. Finance records that connect payroll, contractors, and software spend to the people and projects involved.

If those records tell a consistent story, the application work becomes much more manageable. If they do not, fix the process now while the next round of development is still fresh.

Are We Actually Eligible for the R&D Tax Incentive

A familiar startup scenario. The team spent six months wrestling with model performance, rewrote part of the pipeline twice, and shipped something that finally worked. At claim time, the founder asks a reasonable question: was that R&D, or just hard product development?

That question matters because software claims usually fail at the activity level, not the company level. A startup can be cutting-edge, VC-backed, and shipping difficult technology, yet still have projects that do not meet the test. Eligibility turns on what the engineers were trying to resolve, how they went about it, and whether the records show genuine experimentation rather than routine delivery.

For software teams, I use a simple screen based on the program rules and the way AusIndustry and the ATO examine claims in practice. The work should point to four things: a permitted purpose, technology at the centre of the problem, an experimental method, and a knowledge gap the team could not close with existing professional know-how. Miss one, and the claim gets harder to defend.

A founder level eligibility check

Before drafting anything, test the project against questions your engineering lead should be able to answer clearly:

• What was technically uncertain? The team did not know in advance whether the method would work, or which method would work, and the answer was not obvious to a competent professional.
• What experiments were run? There was a process of testing, comparing, measuring, and refining, not just building to a spec.
• What new knowledge was sought? The project aimed to learn something about feasibility, performance, scalability, architecture, or method.
• Can the team explain it plainly? If the project only makes sense as a list of tickets or commits, it is not ready for claim drafting.
• Do the records exist in your normal systems? Good claims can usually be traced through Jira, GitHub, design docs, and finance records without rebuilding the history from memory.

A quick software example helps. Trying to reduce inference latency where standard approaches failed may support an R&D position if the team tested competing methods and learned from the results. Reworking a standard API integration, fixing defects, or implementing a known architecture pattern usually will not.

Core and supporting activities in software teams

Founders also need to separate core activities from supporting activities early, because otherwise software claims often become too broad.

Core activities are the experimental steps themselves. In a startup context, that could be testing alternative retrieval strategies, trialling different orchestration patterns to solve a non-obvious reliability problem, or evaluating competing data processing methods where the outcome was uncertain.

Supporting activities are more limited. They include work done for the core experiments, such as preparing a test dataset, provisioning an environment used for the experiment, or analysing results produced by the trial. The connection has to be tight. If a task would have happened anyway as part of ordinary product delivery, it often belongs outside the claim.

This is the trade-off founders need to understand. Broader claims can look attractive on a spreadsheet, but weak boundaries create review risk. Narrower claims, tied to specific experiments and supported by records from the tools the team already uses, are usually easier to defend and easier to cost correctly.

Strong startup claims are specific about the technical problem, disciplined about scope, and traceable back to ordinary delivery records.

If your team wants more worked examples for software companies, ClaimKit's eligibility guide is a useful reference.

One practical habit improves this step fast. Ask your CTO or engineering lead to nominate one person per project who can explain the technical uncertainty in plain English, point to the Jira issues or GitHub pull requests where the experiments happened, and identify what the team learned. If nobody can do that, the project usually needs more scoping before it goes into the application.

For teams building a tech-stack-native process, ClaimKit gives software startups a way to organise evidence from systems like GitHub and Jira without relying only on spreadsheets and interviews.

What Evidence Do We Need from Our Tech Stack

At this stage, most software startups either strengthen the claim or weaken it badly. The challenge isn't that teams lack evidence. It's that the evidence is scattered across GitHub, Jira, Notion, Slack, drive folders, and the finance system, with no clear map between the work and the eligibility criteria.

Recent commentary around Australian claims has highlighted exactly that problem: startups often struggle to translate GitHub, Jira, and Notion artefacts into compliant R&D evidence, while the ATO expects more detailed claim basis disclosure and retained records in this discussion of documentation expectations for modern software teams.

What good evidence looks like in practice

Strong evidence is usually timestamped, specific, and connected.

A Jira ticket is useful when it captures the unresolved technical problem, the options considered, and the acceptance criteria for the experiment. A vague ticket like “improve sync engine” doesn't help much. A ticket that says “test whether queue partitioning resolves duplicate event ordering under current load constraints” is much stronger.

GitHub can be even better because it shows progression. Branch history, pull request discussion, commit comments, and abandoned approaches often reveal real experimentation. That matters because the claim needs to show more than effort. It needs to show a method.

Notion or internal docs become valuable when they record the hypothesis, design decisions, test outcomes, and conclusions. Founders often underestimate this. A short technical memo written during a sprint can carry more weight than a polished retrospective drafted months later.

How to organise evidence before EOFY pressure hits

The cleanest approach is to build an evidence pack around each R&D project. Not around the whole business. Not around the whole product roadmap.

Use a simple folder or workspace structure:

• Project summary: One page describing the technical objective, uncertainty, and expected experimental path.
• Activity trail: Linked Jira issues, GitHub branches, pull requests, and design notes.
• Decision records: Notes showing why one approach failed and why the team tried another.
• Time basis: Records showing who worked on the project and when.
• Cost support: Xero exports, payroll records, invoices, and contractor support tied back to the project.

If an engineer leaves tomorrow, could someone else reconstruct the project's experimental story from the records alone? That's a good test of whether your evidence is strong enough.

A practical workflow that works well for startups is to tag relevant tickets and PRs as R&D during the year rather than searching for them later. That gives finance and engineering a shared language. At claim time, you're curating evidence, not hunting for it.

This is also where a platform model can help. Some startups use a traditional adviser and manually export artefacts into shared folders. Others use internal spreadsheets. Another approach is a connected workflow where GitHub, Jira, Linear, Notion, and Xero data are pulled into a draft claim process. ClaimKit fits into that category by using integrations to assemble AI-drafted technical narratives and financial schedules with expert review before lodgement.

What doesn't work well is relying on memory. Founders often remember the commercial urgency of a project, but the claim turns on technical detail. Without those contemporaneous records, the application becomes more opinion than evidence.

How Do We Write the Technical and Financial Narrative

Once the evidence is in decent shape, the drafting becomes much easier. The key is to stop thinking like a founder pitching product value and start thinking like an assessor reading for technical method.

An R&D activity registration must include a Project Description covering nine mandatory elements, and each element requires 1,000 to 4,000 characters. Those elements include Project Objective, Hypothesis, New Knowledge, Technical Uncertainty, Experiments, and Conclusions.

Turning engineering work into project descriptions

Most poor drafts fail because they sound like product roadmaps. They talk about what the business wanted to build, not what the engineering team didn't know.

A better drafting method is to write each project in this order:

1. Objective
   State what the team was trying to achieve in technical terms. Keep it concrete. “Improve platform scalability” is weak. “Determine whether a new event-processing architecture could maintain data consistency under the target concurrency profile” is stronger.

2. Hypothesis
   Write the proposition the team tested. It should be capable of being wrong.

3. Technical uncertainty
   Explain why the answer wasn't known at the start. Many claims collapse here. If the issue was mainly time, budget, customer preference, or implementation effort, it isn't the right kind of uncertainty.

4. Experiments and evaluation
   Describe what was done, what was tested, how results were assessed, and what changed after each result.

5. Conclusion and new knowledge
   Set out what the team learned, even if the outcome was that one path failed.

Don't write the claim as a success story. Failed attempts often provide the clearest evidence that the work was genuinely experimental.

Linking costs to activities without guesswork

The financial narrative should mirror the technical one. If the technical story is project-based, your costs should be project-based too.

That means finance needs a reasonable basis for linking expenditure to the eligible activities documented in the registration. For startup teams, that often involves a combination of payroll mapping, contractor records, software costs, and time allocation records supported by delivery tools.

A practical weekly routine helps:

• Have engineering leads review tagged R&D work: This keeps the technical scope realistic.
• Reconcile payroll against active R&D projects: Don't wait until tax return time.
• Store contractor scopes and invoices with project notes: If the invoice is vague, the supporting records need to do more work.
• Tie finance labels to the same project names used in engineering tools: Naming drift creates avoidable confusion.

For teams that don't want to build the drafts manually, the ClaimKit blog shows how software-first claim preparation is moving toward structured evidence capture and draft generation rather than long interview-only processes.

The point isn't to produce beautiful prose. It's to produce a narrative that matches the evidence trail and can be followed by someone outside your company.

How Do We Lodge the Application and What Are the Timelines

By the time most founders ask about timing, they're already too close to the deadline. The R&D tax incentive application is unforgiving on this point.

The process has two separate lodgements. First, you register the activities through the R&DTI Customer Portal with AusIndustry. Second, you lodge the supplementary return with the ATO alongside the company tax return. The critical timing rule is that the activity registration must be lodged within 10 months of the company's financial year-end, and missing that deadline means the claim for that year is lost, as set out in the verified application methodology and compliance notes provided in the brief.

The two stage lodgement path

For a startup with a standard 30 June year-end, the registration deadline falls on 30 April of the following year. That date should already be on your finance calendar.

The sequence usually looks like this:

• Step one: Identify projects and confirm they're ready to be written up.
• Step two: Prepare the project descriptions and supporting evidence.
• Step three: Lodge the activity registration in the portal.
• Step four: Finalise expenditure schedules and include the claim through the tax process with the ATO.

If your team leaves the technical drafting until after year-end, the risk isn't just stress. The quality of the claim usually drops because the evidence is harder to recover and explain.

R&D Application Approaches Compared

Startups generally choose between DIY preparation, a traditional advisory firm, or a software-enabled model with expert review. Different businesses suit different approaches.

There isn't a universal right answer. Early-stage founders who are highly organised may start with a lighter-touch process. Teams with multiple projects, fast hiring, and messy records usually need more structure.

One practical thing to ask any provider is how they handle evidence from engineering and finance systems. Another is how transparent the draft and review process will be. If the method feels like a black box, that can become a problem later in a review.

For teams comparing workflows and data handling, it's also sensible to check how records are managed in the provider's systems, including their published privacy information.

What Common Pitfalls Cause Startup Claims to Fail

Most startup claim failures aren't caused by obscure technicalities. They come from a short list of recurring mistakes that are visible well before lodgement.

ATO data from 2023-24 shows 38% of R&D applications faced rejection or adjustment, with common reasons including lack of clear technical uncertainty in 22% of cases, failure to demonstrate new knowledge generation in 18%, and insufficient linkage between activities in 15%.

The mistakes that show up again and again

The first problem is confusing product complexity with technical uncertainty. A feature may be hard to build, commercially important, and expensive, but that doesn't make it eligible R&D. You need to show what was unknown and why experimentation was required.

The second is weak articulation of new knowledge. Startup teams often know they learned something, but the claim doesn't say what that knowledge was. It needs to be explicit. What capability, limitation, method, or result became known through the work?

The third is poor linkage between supporting activities, costs, and the core experiment. Claims get bloated when every adjacent activity gets swept in. That's where finance schedules and technical narratives drift apart.

Use these fixes early:

• Document failed paths: A dead-end branch, rejected architecture note, or abandoned ticket sequence can be valuable evidence.
• Write short monthly summaries: Don't wait for EOFY to explain what the team learned.
• Map costs to projects, not departments: Department-level allocations are harder to defend.
• Review claims before lodgement with a sceptical lens: Ask what an assessor would question first.

If you want specialist help checking those weak points before submission, ClaimKit's consultant network page shows the kind of expert review model some startups now use instead of a purely manual claim process.

R&D Tax Incentive Application FAQs

Can software development qualify as core R&D activity

Yes. Software can qualify where the team is trying to resolve a genuine technical uncertainty through a planned process of testing, comparison, and evaluation. In startup claims, the dividing line is usually clear once you look at the artefacts. A Jira epic, linked GitHub branches, test results, and an architecture note will often show whether the work was experimental or just delivery. Routine implementation, standard integrations, and feature work with a known path usually fall outside core R&D.

What counts as a supporting activity in a startup claim

Supporting activities are the tasks directly connected to running or assessing the core experiment. For software teams, that can include setting up an isolated test environment, preparing data used in the experiment, or analysing logs and benchmark outputs tied to the result.

The hard part is scope. Product planning, customer support, release coordination, and general platform upkeep may sit nearby in the same sprint, but that does not make them part of the claim. Founders should map each supporting task back to a specific experiment, ticket set, or repo history so the connection is visible.

What if our records are messy but the work was real

That happens often, especially in early-stage teams that shipped fast before anyone thought about AusIndustry or ATO review.

Start with systems that give you clean timestamps and user attribution. GitHub commits, pull requests, Jira or Linear tickets, calendar entries, Notion pages, Slack decisions, and finance exports usually provide enough to rebuild a credible sequence of work. Then separate what you can prove from what you only remember. A narrower claim with clear evidence is usually safer than a broader claim built on reconstruction alone.

Where can we read the government overview

The government program overview is a reasonable starting point, as noted earlier in this guide. After that, startups usually need process help more than high-level summary. Questions like how to connect GitHub commits to a technical narrative, how to explain failed experiments, and how to tie payroll costs back to project evidence are where claims are won or lost. For that kind of practical guidance, ClaimKit's help centre is one example.

If your team is building real software R&D but your evidence is spread across GitHub, Jira, Linear, Notion, and Xero, ClaimKit is built for that workflow. It prepares AI-drafted claim materials from your existing records, then routes them through expert review and ATO lodgement support, so you can turn day-to-day engineering artefacts into a cleaner R&D tax incentive application.