Most of an R&D Tax Incentive claim for a software or deep-tech company is an engineering argument. The finance team prices it and a director declares it, but whether the activities are eligible depends on what the CTO's team did and what they wrote down while doing it.
Experiment or delivery: where AusIndustry draws the line
A core R&D activity is an experiment whose outcome a competent professional could not have known in advance, run as a systematic progression from hypothesis to experiment, observation, evaluation and conclusion. AusIndustry's software guide is blunt that methodology does not decide it: working in agile, waterfall or any other way does not, by itself, make an activity eligible or ineligible.
The same guide lists routine work that is generally not core R&D: integrating a third-party API by following vendor documentation, assembling interfaces from standard components, building dashboards from established patterns and migrating data with known tools. Some of it can still be a supporting activity when it directly relates to a core experiment.
An illustrative contrast. A team needs vector search over 50 million embeddings to answer within 100 milliseconds on a fixed memory budget, and no published method they can find achieves it. They hypothesise that a two-stage quantised index with re-ranking will, record benchmark runs as they vary the codebook size, and conclude which configurations fail and why. That is a candidate core activity (see performance and scale engineering). The same quarter, the team adds single sign-on with a vendor SDK. That is delivery.
What your systems already hold
AusIndustry lists the engineering artefacts that evidence an experiment: spike tickets, design notes, architecture decision records, test plans, logs and performance graphs. It also says "it is the content of the records, rather than the format" that counts. A pull request titled "fix" shows almost nothing. A ticket that states the hypothesis, links the benchmark and records the conclusion is strong support, though it still shows what was done, not that the work was eligible: that rests on whether the unknown was genuine. Most teams already have this material scattered across GitHub, Jira and design docs; the work is connecting it to the activity it evidences.
Drafting the technical fields
The main activity text fields hold up to 4,000 characters each. The portal accepts only standard keyboard characters, so pasted bullet symbols cause an error that surfaces only after the activity is saved and reopened. Within those limits:
- Write the hypothesis as it stood before the work: the intended result, the method and why it might not work.
- Name the knowledge gap, not the feature. "Build recommendations" is a product; "whether sparse interaction data can support ranking at this precision" is a question.
- Keep each core activity to one technical idea. AusIndustry warns that bundling too many activities into one can blur the description and affect eligibility.
Where engineering-led claims go wrong
The ATO's software alert, TA 2017/5, targets claims that register a whole product build as R&D and testing that does not test a hypothesis. The usual cause is a CTO asked in April to summarise a year of work from memory. The fix is boring: for work that genuinely tests an unknown, a hypothesis written down before the spike starts and a conclusion written down when it ends. Writing a hypothesis for routine delivery does not change what it is.