The Small Business Technology Investment Boost gave eligible businesses with turnover under $50 million a 20% bonus deduction on up to $100,000 of eligible tech spend incurred between 29 March 2022 and 30 June 2023. That program ended in 2023, but for Australian tech startups doing genuine software or technical experimentation, the more powerful ongoing incentive is often the R&D Tax Incentive, which can return 43.5 cents for every dollar spent on eligible R&D.

That's the counterintuitive bit. Many founders still spend time looking backwards at the small business technology investment boost, even though the practical job in 2026 is building a repeatable R&D process that captures evidence as work happens. The startups that handle this well usually don't treat R&D claims as a once-a-year finance exercise. They treat them as an operating system across product, engineering and finance.

If you're pre-seed to Series A, the biggest lever usually isn't learning more tax jargon. It's making sure Jira tickets, GitHub commits, Notion specs, Linear issues and Xero coding create a clean trail of technical intent, experiments, failures and cost allocation from day one.

Table of Contents

• How Do You Know if Your Startup Is Eligible for the R&D Tax Incentive
  • What founders should check first
  • What eligible software work often looks like
  • What to do this week
• What Is the Best Way to Document R&D Activities
  • Build evidence capture into the tools you already use
  • What good contemporaneous evidence looks like
  • A low-friction operating rhythm for startups
• How Can You Model the Financial Return on Your R&D Claim
  • Build the model from source systems, not from memory
  • A board-ready way to forecast the return
  • The process playbook matters more than the formula
  • What improves forecast accuracy
• When Should You Engage an R&D Tax Advisor
  • The two main models in the market
  • How to decide which model fits
  • What founders can do before signing anyone
• What Are the Common Pitfalls and Key Deadlines to Watch
  • The mistakes that show up most often
  • The deadline mindset that actually helps
  • What founders should fix this week
• Frequently Asked Questions About Tech R&D Claims
  • Can software development qualify for the R&D Tax Incentive?
  • Can SaaS subscriptions be included in an R&D claim?
  • Can you claim both the Small Business Technology Investment Boost and the R&D Tax Incentive?
  • Should founders use an advisor for their first claim?
  • What should a startup do this week if it thinks it may be eligible?

How Do You Know if Your Startup Is Eligible for the R&D Tax Incentive

Eligibility is usually clearer than founders expect. The hard part is not the rule set. The hard part is separating genuine technical experimentation from normal product delivery, then setting up a process that proves the difference without a year-end reconstruction exercise.

For software startups, I use four filters before we spend real time on a claim. The company has to be the right entity type. The claim needs enough eligible spend to be worth pursuing. The work itself has to involve technical uncertainty and a structured attempt to resolve it. The team also needs records that can be traced back to the systems they already use, not a polished story written months later.

What founders should check first

Start with a fast screen:

• Entity test: Is the claim being made through an eligible company structure, rather than a sole trader setup or an informal side project?
• Spend test: Have you incurred enough eligible R&D expenditure in the year to clear the program threshold?
• Activity test: Did the team work through a real technical unknown using a systematic process of testing and evaluation?
• Evidence test: Can finance and engineering tie that work back to tickets, commits, design notes, payroll records, contractor invoices, and vendor costs?

The activity test usually decides the outcome.

A team building a new data pipeline may have eligible work if reliability, performance, or scalability could not be resolved with established methods and the team had to test competing approaches. A team customising a Shopify theme, wiring up a standard API integration, or configuring a common CRM workflow is usually doing implementation work. That can be commercially important and still fall outside the incentive.

A simple rule helps here. If a competent engineer could reasonably predict the solution using existing knowledge and standard practice, the work is less likely to qualify as R&D.

What eligible software work often looks like

Definitions help, but examples are faster. These patterns are usually more useful than broad statements about innovation:

I usually ask the CTO or engineering lead for three plain-English answers before we model a claim:

1. What exactly was uncertain at the start?
2. Which approaches did the team test, and why?
3. What did the team learn, including dead ends and failed attempts?

Clear answers are a good sign. Vague answers usually mean one of two things. The work was not strong R&D, or the business failed to capture the evidence while the work was happening.

That second problem is fixable, and it matters more than many founders realise. Strong claims are built from ordinary delivery data captured continuously in Jira, GitHub, and your finance stack. That is why I treat eligibility as an operating process, not just a tax opinion.

What to do this week

Pick one project with a credible technical unknown. Pull the Jira epic, GitHub activity, architecture notes, and payroll or contractor cost data for the relevant period. Then write a one-page summary that states the uncertainty, the approaches tested, and the outcome.

If that summary can only be written from memory, your next task is not expanding the claim. It is fixing the evidence workflow. Teams comparing support options can review R&D consultants used by Australian companies and look closely at whether they help set up repeatable documentation processes, not just end-of-year claim drafting.

What Is the Best Way to Document R&D Activities

The best documentation system is the one your engineers will use. That usually means you don't create a separate evidence process from scratch. You turn your existing delivery stack into an evidence machine.

The weak version of R&D documentation happens at year end. Finance sends a spreadsheet, engineering tries to reconstruct six months of intent from memory, and every answer sounds cleaner than the work really was. The stronger version captures the mess in real time, because real experimentation is messy.

A useful benchmark for any modern workflow is whether your process protects data handling and access controls as carefully as it handles technical evidence. Teams that care about this usually review a provider's privacy approach for R&D documentation workflows before connecting source systems.

Build evidence capture into the tools you already use

For software teams, the raw material is already there:

• Jira or Linear: problem statements, acceptance criteria, blocked tasks, technical unknowns
• GitHub: commit history, pull requests, branches, code review comments
• Notion: architecture notes, experiment logs, product specs, retros
• Xero: contractor costs, software costs, payroll mapping, invoice dates

The trick is to add just enough structure that these tools become defensible records.

For Jira or Linear, I'd make sure tickets for candidate R&D work include short fields or templates covering the uncertainty, proposed approach and test outcome. For GitHub, commit messages and PR descriptions should explain why a change was attempted, not just what changed. “Refactor auth service” is weak. “Test token refresh strategy to reduce session failure under concurrent load” is much stronger because it shows technical purpose.

What good contemporaneous evidence looks like

Good evidence isn't polished. It's specific.

A strong record often includes:

• a ticket describing the technical problem
• a design note showing competing approaches
• commit history reflecting iteration
• test outputs or failure logs
• a short retrospective showing what the team learned

Weak records usually have only release notes and founder memory.

The easiest claims to defend are the ones where engineering artefacts tell the story before finance writes a single sentence.

That's why automated workflows matter. If your evidence capture depends on one finance lead chasing five developers every June, the process won't hold at scale. A better operating model pulls structured information from systems like GitHub, Jira, Linear, Notion and Xero throughout the year, then drafts technical narratives from those records for expert review before lodgement.

Here's a walkthrough of what that looks like in practice:

A low-friction operating rhythm for startups

A simple monthly rhythm works better than a heroic EOFY clean-up.

Try this:

• At sprint planning: Tag work that contains genuine technical uncertainty.
• During development: Require meaningful PR descriptions and keep failed experiment notes.
• At month end: Finance exports payroll and contractor data, then maps people and costs to candidate projects.
• At quarter end: Product and engineering review whether each project still looks like R&D or has shifted into routine implementation.

This process is boring in the best way. It reduces narrative rewriting later, and it helps founders spot when a project no longer supports a credible claim.

How Can You Model the Financial Return on Your R&D Claim

A weak R&D model causes two problems fast. It overstates cash you may never receive, and it hides which engineering work is creating claim value.

The model that works in practice is simple enough for the board pack and strict enough for review later. Start with eligible spend by project, tie that spend back to the evidence your team is already creating in Jira and GitHub, then run upside, base-case and conservative scenarios. That approach turns the claim from a year-end estimate into an operating forecast.

For context, the Small Business Technology Investment Boost was narrower and time-limited. It provided a 20% bonus deduction on up to $100,000 of tech spending for businesses with under $50 million turnover, applicable for costs incurred between 29 March 2022 and 30 June 2023, as outlined on the Australian Government's technology investment boost page.

The R&D Tax Incentive serves a different purpose. For software startups, it can change hiring timing, runway planning and how confidently the team funds experimental work.

Build the model from source systems, not from memory

The cleanest model has four layers:

1. Identify candidate R&D projects
2. Map people and non-payroll costs to those projects
3. Apply a defensible R&D percentage to each cost line
4. Estimate the offset under a conservative and expected case

That sounds basic. The difference is operational discipline.

If engineering tags candidate R&D work during the year, finance does not need to reconstruct everything from release notes in June. Jira tickets, GitHub pull requests, sprint labels and payroll exports become the working papers behind the forecast. I have found that claim quality improves fastest with this approach, because the financial model stays tied to actual delivery records instead of broad assumptions.

For many startups, the main cost lines are:

• developer and data science salaries
• eligible contractor costs
• cloud or tooling costs directly tied to experimental work
• consumable project costs where relevant

If you need the current program rules before building the forecast, the official R&D Tax Incentive guidance for businesses sets out the framework.

A board-ready way to forecast the return

Assume a startup has identified $100,000 of eligible R&D spend. Using the commonly referenced 43.5% refundable tax offset for eligible companies in this category, the indicative benefit is $43,500.

That headline number is the easy part. The core modelling work is in the allocation.

A useful finance view looks like this:

I would not put a single-point estimate in front of a board unless the evidence trail is already clean. A tighter habit is to model three cases:

• Conservative case: lower apportionment where project records are thin
• Expected case: finance view based on current evidence capture
• Stretch case: used internally, not as the headline forecast

That framing helps founders make decisions without treating the claim as guaranteed cash.

The process playbook matters more than the formula

The formula is short. The workflow is what determines whether the number survives review.

Teams get better results when finance owns the model, engineering owns project tagging, and both functions review allocations monthly or quarterly. That cadence catches scope drift early. It also shows when a project has moved from genuine technical uncertainty into routine implementation, which should change the forecast before the claim is drafted.

If you want that workflow connected to source evidence rather than split across spreadsheets, docs and inbox threads, an R&D claim workflow platform for startups can centralise project records, cost schedules and draft narratives in one place.

What improves forecast accuracy

These habits tend to hold up:

• monthly cost mapping by project
• conservative apportionment where records are mixed
• one finance owner and one engineering owner
• scenario planning based on identifiable technical work
• direct links from the model back to Jira, GitHub and payroll records

These habits usually create problems:

• claiming all engineering payroll without allocation logic
• treating general software subscriptions as automatically eligible
• forecasting the benefit before confirming the technical basis of the claim
• relying on founder memory to explain project uncertainty after year end

When Should You Engage an R&D Tax Advisor

The short answer is earlier than most founders think. Not because the form is hard, but because evidence quality is set by product and engineering habits long before finance starts drafting the claim.

The right time to bring in support is usually when one of these becomes true: your first serious claim is approaching, your projects are getting technically complex, or your cost base is large enough that weak allocation would create unnecessary risk.

The two main models in the market

Most founders choose between a traditional consultant-led process and a software-enabled workflow with expert review.

Here's the practical difference:

Founders will often recognise names like Treadstone, Prime Partners, Link R&D Advisory and Bulletpoint when they start comparing providers. Those firms can be a fit, especially where the company wants a conventional advisor relationship and is comfortable with interviews, document requests and spreadsheet-driven collation.

A software-led model suits a different kind of startup. If your team already works in GitHub, Jira, Linear, Notion and Xero, it makes sense to capture evidence from those systems rather than rebuild the story in Word documents at year end.

How to decide which model fits

I'd choose based on operational fit, not just fee structure.

• Pick traditional support if your case is unusually complex, the internal team wants a high-touch process, or you need heavier strategic input.
• Pick a software-enabled process if your startup wants transparency, faster turnaround and a workflow that mirrors how engineering already works.
• Avoid both models if you expect someone else to fix weak records after the fact. That rarely ends well.

A good comparison point is how much black-box work sits between your raw evidence and the final claim. Founders who want to understand that pipeline should spend time reading actual practitioner content, not just landing pages. A useful place to do that is the ClaimKit blog on R&D claim workflows and documentation.

The best advisor model is the one that makes your evidence stronger before EOFY, not the one that writes the prettiest narrative after EOFY.

What founders can do before signing anyone

Ask four questions in the first meeting:

1. How do you identify eligible projects in software teams?
2. How do you map payroll and cloud costs to those projects?
3. What source documents do you rely on most heavily?
4. What does review look like before ATO lodgement?

The answers will tell you whether you're buying a process or just a document.

What Are the Common Pitfalls and Key Deadlines to Watch

Most R&D claim problems aren't caused by edge-case law. They come from ordinary operating mistakes. Teams leave evidence too late, blur experimental work with routine engineering, or code costs too broadly in the ledger.

One issue worth calling out from the old Small Business Technology Investment Boost rules is cost misclassification. Training is covered under the Skills and Training Boost and not the technology boost, which made it a common cause of claim adjustments according to this guide on technology investment boost mistakes. The broader lesson carries over to R&D claims: founders need clean category boundaries.

The mistakes that show up most often

Some patterns repeat across startup claims:

• Leaving documentation to EOFY: Engineers forget why a certain approach was experimental, and the narrative gets flattened into hindsight.
• Mixing BAU and R&D work: A product squad can work on both in the same sprint. If you don't separate them, your salary allocation gets weak fast.
• Overclaiming software tools: General business software, ordinary admin tools and generic subscriptions often need careful treatment.
• Poor project boundaries: If one epic contains routine feature work and a genuine technical experiment, finance needs a way to split them.

A related risk is scrutiny after lodgement. If you want a plain-English overview of how reviews can unfold, this piece on ATO R&D tax claim scrutiny is a useful read for founders and finance leads.

The deadline mindset that actually helps

The easiest way to miss important dates is to treat the claim as a single annual task. It's better to run a calendar with internal deadlines before the formal ones.

I'd keep these practical checkpoints:

• Monthly: close payroll mapping and tag candidate projects
• Quarterly: review project eligibility with engineering leads
• Pre-EOFY: clean up unresolved coding issues, contractor records and missing experiment notes
• Before registration and lodgement windows close: get the narrative and financial schedules reviewed while the team still remembers the work

Missing a formal deadline hurts. Missing the internal deadline three months earlier is usually what caused it.

If your team needs operational guidance rather than theory, a searchable R&D help centre with process articles and support content can be useful for working through documentation and timing issues in plain English.

What founders should fix this week

Do a one-hour audit of your current stack.

Check whether:

• Jira or Linear issues distinguish experimental work from delivery work
• GitHub PRs explain technical intent
• finance can map payroll to projects
• contractor statements of work match the work done
• cloud invoices can be tied to the relevant activity

If two or more of those are shaky, the claim process isn't your problem. Your operating system is.

Frequently Asked Questions About Tech R&D Claims

Can software development qualify for the R&D Tax Incentive?

Yes, but only when the work involves genuine technical uncertainty and a structured attempt to resolve it. Shipping product features alone isn't enough. A startup building a new algorithm, testing competing architectures, or working through unresolved scaling behaviour may have a stronger basis than a team implementing standard integrations or UI changes.

Can SaaS subscriptions be included in an R&D claim?

Sometimes. The key question is whether the cost relates directly to eligible R&D activities, and whether you can explain that link with records. Infrastructure used in experimentation may be more relevant than ordinary business tools like CRM, HR or sales software.

Can you claim both the Small Business Technology Investment Boost and the R&D Tax Incentive?

Potential overlap can exist in principle, but the categories need careful treatment. The Treasury consultation position noted that expenses must be already deductible under taxation law to qualify for the technology boost, which implies there may be overlap with R&D deductions if costs are properly categorised, as discussed in this guide on claiming the technology investment boost.

The problem in practice is segmentation. If a cloud environment, software tool or contractor engagement supports both experimental development and ordinary operations, the company needs a defensible allocation method. Founders should be very cautious about assuming one pool of spend cleanly fits multiple incentives without detailed review.

Should founders use an advisor for their first claim?

Usually, yes, especially if the company has never translated product and engineering work into an R&D narrative before. The first claim often sets the pattern for future years. A good process doesn't just help with one filing cycle. It teaches the team how to capture evidence continuously.

If you're comparing providers, it helps to look at who built the process, how reviews happen, and whether the platform or advisor understands software teams. The ClaimKit about page gives a useful snapshot of one human-reviewed, software-enabled model in the market.

What should a startup do this week if it thinks it may be eligible?

Start small and stay concrete:

• Choose one project: Pick the clearest example of technical uncertainty from the last year.
• Pull the artefacts: Gather tickets, PRs, design notes, test outputs and cost records.
• Write the experiment story: What was unknown, what did you test, and what did you learn?
• Map the costs: Identify which people, contractors and tools supported that work.
• Review the gaps: If the evidence is thin, fix the process now for the current year rather than forcing a weak retrospective claim.

Most founders don't need more theory. They need better capture, cleaner allocation and earlier review.

---

If you want a faster way to turn engineering activity into a defensible R&D claim, ClaimKit is worth a look. It connects with tools like GitHub, Jira, Linear, Notion and Xero, uses AI to draft claim materials, and pairs that output with expert review and ATO lodgement support. For startups that want less spreadsheet chasing and more continuous evidence capture, that workflow can be a much better fit than the usual EOFY scramble.