Skip to main content
zatersio

R&D Tax Records: Australian Software Teams Must Log Experiments

R&D Tax Records: Australian Software Teams Must Log Experiments

Sketch motifs framing the article title

Yes, software development can qualify for Australia’s R&D Tax Incentive when the work shows technical uncertainty resolved through systematic experimentation. To support a claim, you need contemporaneous records: a DISR registration number, experiment logs with hypotheses, exported task tracker time allocations, contracts and invoices, plus design and test results. Register within 10 months of your income year’s end.

TL;DR:

  • Routine coding, standard API integrations, ordinary bug fixes, internal administration, and reproducing commercial software generally fall outside eligible activities on their own.
  • Supporting activities qualify only when their dominant purpose is enabling a core experiment; document the connection, since unrelated tasks would have happened anyway.
  • Create dated evidence as work happens, including hypotheses, test results, tracker exports, commit references, timesheets, contracts, and invoices; retain records five years after lodging.
  • Register activities with DISR within 10 months after the income year ends and before lodging; registration is not approval, and descriptions must match internal logs.
  • A minimum spend threshold applies, but businesses commissioning eligible R&D through a registered Research Service Provider can use an exception to that threshold.
Zatersio
Build R&D-Ready Software
Zatersio builds bespoke software and AI-driven automation, with support for clients seeking to leverage the R&D Tax Incentive for eligible projects.

Table of Contents

Eligibility explained: the legislative tests for software R&D in Australia

The R&D Tax Incentive uses a specific test, and it is stricter than most founders expect. Core R&D activities must be experimental, grounded in a hypothesis about an outcome that is not already known or deducible by a competent professional, and resolved through a systematic progression of work based on scientific principles. For software, that means genuine technical uncertainty, not a feature you have not built yet but know how to build.

The sector guidance draws a hard line here: routine coding, standard API integrations, and ordinary bug fixing generally will not qualify on their own. There is also a minimum spend threshold to clear before the incentive applies, and a Research Service Provider exception exists for businesses that commission eligible R&D through a registered RSP rather than running it in house.

Two quick scenarios make the test concrete:

  • Likely eligible: building a new machine learning model to predict equipment failure from noisy sensor data, where the team cannot predict in advance whether the chosen architecture will converge on usable accuracy.
  • Likely ineligible: integrating a well-documented third-party payment gateway into an existing product, since the steps and outcome are already known to a competent developer.

Self-assessing against this test before you start logging anything saves time later and keeps your records focused on the activities that actually matter.

Core vs supporting activities and software-specific exclusions

Not every task on a project ticket counts the same way. Core R&D activities are the experiments themselves: the hypothesis, the build, the test, the result. Supporting activities are the work that enables those experiments, like setting up test environments or collecting data for an experiment, and they only qualify when undertaken for the dominant purpose of supporting the core activity.

  1. Core R&D example: testing three different concurrency models to resolve an unknown data race in a distributed system, with documented hypotheses for each attempt.
  2. Supporting R&D example: building a staging environment specifically to run those concurrency experiments.
  3. Excluded activities: internal administration, reproducing an existing commercial product’s functionality, and routine maintenance or customization of software for internal business use.

The dominant purpose test matters most for supporting activities. If a task would have happened anyway, for a reason unrelated to the experiment, it probably will not qualify. Document the link explicitly: note in the ticket or work log why the supporting task exists and which core experiment it feeds.

Record keeping: what contemporaneous documentation the ATO and AusIndustry expect

Contemporaneous means created at the time the work happened, not reconstructed from memory months later when a claim is due. The ATO’s record keeping guidance is explicit that the effectiveness of a claim depends on how well your records link the what, how, and why of an activity to the legislative criteria.

Statistic callout: Records for R&D tax claims must be kept for 5 years from the date you lodge the tax return containing the claim. If your income year ends 30 June 2026 and you lodge in March 2027, your retention clock runs from that lodgment date, not from when the work happened.

The acceptable evidence list is broader than most teams assume, and it does not require bespoke systems:

  • Project plans and design specifications written before experiments started.
  • Issue tracker exports showing ticket creation dates, assignees, and status changes.
  • Code commit references tied to specific experiment branches.
  • Screenshots of test results, error logs, or dashboard outputs at key milestones.
  • Signed contractor agreements and invoices tied to specific work packages.

Keep a simple working paper that maps each person’s hours to an activity code, and store the exported reports alongside the invoices they support. For a more detailed approach to building documentation habits that survive staff turnover, this process documentation guide covers templates worth adapting for an R&D context.

Pro Tip: Export your issue tracker data monthly rather than once at claim time. A rolling export with timestamps is far stronger evidence than a single end of year dump that looks assembled after the fact.

Monthly tracker records gathered into an archive

Registration and deadlines: DISR registration, how and when to register

You must register your R&D activities with DISR within 10 months after the end of the income year in which the activities happened, before you lodge your claim. If your income year ends 30 June 2026, your registration deadline is 30 April 2027.

The registration form asks for activity descriptions and project context: what the technical uncertainty was, what experiments you ran, and how the work fits into the broader project. Write these descriptions in plain, specific language rather than marketing copy.

  • Describe the uncertainty first, then the experiment, then what you learned.
  • Keep descriptions consistent with your internal logs; mismatches between the two are a common review trigger.
  • Registration is a prerequisite, not an approval. AusIndustry and the ATO can still review your claim against the contemporaneous evidence you kept.

Calculating and lodging a claim: schedule, deductions and apportionment

The ATO sets out a six-step approach to claiming: check eligibility, calculate aggregated turnover, determine the offset type, compute the offset, complete the schedule, and lodge it with your company tax return.

  1. Complete the R&D schedule. The 2026 instructions explain which labels apply for add-backs and notional deductions, and they were last updated 30 May 2026.
  2. Apportion your expenditure. Use timesheets, job cards, or exported reports to show what share of a developer’s or contractor’s time went to registered activities, and keep the working paper that shows your method.
  3. Capture contractor and associate payments separately, along with any feedstock adjustments or clawback events, so each figure in the schedule traces back to a specific invoice or agreement.

Working papers matter here as much as the final numbers. A reviewer wants to see the calculation trail, not just the total.

Common mistakes, audits and how reviewers assess claims

Most review triggers are avoidable. Late registration, inconsistent descriptions between the registration form and internal logs, missing contractor agreements, and weak links between claimed costs and specific activities are the frequent culprits.

AusIndustry and the ATO assess claims by looking for a single evidence thread: what was the uncertainty, how was it resolved, and why was the approach chosen. The ATO’s own guidance notes that contemporaneous evidence is judged qualitatively, and a summary written after the fact carries far less weight than a timeline built as the work happened.

  • Start contemporaneous logging immediately if you have not been doing it.
  • Backfill a gap period with whatever dated artifacts exist (commit history, emails, old tickets) and label them clearly as reconstructed.
  • Cross check your registration descriptions against your logs before lodging.

Pro Tip: If you discover a documentation gap close to a deadline, prioritize dated artifacts over narrative summaries. A commit timestamp is harder to challenge than a paragraph written from memory.

Practitioner checklist: building R&D documentation into your sprint workflow

Evidence capture works best when it sits inside the tools your team already uses, not as a parallel compliance exercise.

  • Add hypothesis and expected outcome fields to the ticket template for any experimental task.
  • Tag time entries against registered activity codes so exports map directly to the schedule.
  • Record contractor deliverables and invoices against the same activity codes at the time work is billed.
  • Keep three lightweight templates on hand: a daily experiment log, an experiment summary artifact, and a contractor work statement.

Our own approach to rapid MVP builds follows this structure from day one, so documentation exists because it was part of how the sprint ran, not because someone reconstructed it later.

Pro Tip: Build these fields into your ticket template once. After that, documentation is a byproduct of normal sprint work rather than a separate task someone has to remember.

Author perspective: making R&D documentation routine

The biggest gap I see is treating R&D documentation as a quarterly scramble instead of a daily habit. Teams that log hypotheses and results as part of standups and ticket updates end up with stronger claims and far less audit anxiety than teams that try to reconstruct a narrative in March. Small, consistent records beat a polished summary every time.

— Lakitha

How we help you build R&D-ready software from the start

We deliver working MVPs on a rapid schedule, and we structure the process so documentation, hypotheses, experiment logs, and test results, comes out of the build itself rather than a separate paperwork exercise afterward.

Zatersio

If you want a delivered project built with this discipline in mind, see our MVP development page or explore workflow automation for projects involving experimental process builds. You can check current project pricing and get a quote on our pricing page.

FAQ

Can I get the R&D Tax Incentive for software development projects?

Yes, software projects can qualify when the activity involves genuine technical uncertainty resolved through a systematic, hypothesis-driven process, as outlined in the sector guidance. Routine coding, standard integrations, and maintenance generally do not qualify on their own.

Can I get an R&D tax credit for software development?

Australia offers an R&D tax offset rather than a credit, and software development can be eligible when it meets the core R&D activity test for technical uncertainty and systematic experimentation. You still need to register with DISR within 10 months of your income year’s end and keep contemporaneous records to support the claim.

What is the 80% rule for R&D credit?

The applicable tests are the core and supporting activity definitions and the dominant purpose test described in the business.gov.au record-keeping guidance.

What is the role of R&D in software development?

Within the R&D Tax Incentive, R&D in software development means resolving a technical unknown through structured experiments, such as testing an unproven algorithm or architecture, rather than simply writing new features. The role is to isolate genuine uncertainty from ordinary engineering work so that the experimental portion can be documented and claimed.

Sources