R&D Tax Incentive and AI Build Work: The Documentation Side
When we build something for an Australian company that is genuinely experimental, where nobody could reasonably have known in advance whether the approach would work, we write down what was tried, what happened and what it proved, as it happens. That record is what a company’s R&D adviser needs. It can make a build materially cheaper after a claim without us discounting the work.
Read the next line twice, because it is the whole basis on which we will talk to you about this. We do not give tax advice. We do not assess whether your project is eligible. We never tell a client they will receive an offset. AusIndustry and the ATO decide eligibility, and your own accountant or a registered tax agent who specialises in R&D substantiates and lodges the claim. There is no separate register of R&D advisers, so the credential worth checking is registration as a tax agent with the Tax Practitioners Board. What we supply is the contemporaneous technical record, and an honest opinion on whether the work we are about to do is experimental at all. Frequently it is not.
Realistic ROI
Four Things Worth Understanding Before You Get Excited
The incentive is real, the rules are public, and most of the disappointment comes from four misunderstandings that surface late. General information only, not tax or financial advice.
Most software work does not qualify, and we will say so
Applying known techniques, configuring off the shelf software, wiring up documented interfaces and building something whose outcome was reasonably knowable in advance are all ordinary development. They are valuable, they are what most of our work is, and they are generally not eligible core R&D activities. The test is not whether the work was hard or new to your team. It is whether the outcome could have been determined in advance by a competent professional applying existing knowledge, and if it could, no amount of careful writing changes that.
The unit of the claim is the experiment, not the project
A build is rarely all experimental. Inside a six month programme there may be two or three genuinely uncertain questions and a great deal of ordinary engineering around them. The record has to isolate those questions and, for each one, give the regulator’s own five elements: hypothesis, experiment, observation, evaluation and logical conclusions. Keep them separable from the supporting work. Companies that write one broad narrative about their whole project at year end are the ones that struggle when someone asks for detail.
Contemporaneous means written while it happens
A record created as the work proceeds carries weight because it could not have been shaped to fit a claim. A reconstruction written eleven months later, from memory and a few commit messages, carries far less, and reconstructing it is miserable work that nobody enjoys paying for. The practical difference is small if you build the habit into the delivery process from day one: a short entry per experiment, written the week it happened, with the artefacts attached.
Optimism is the expensive option
Overstating what was experimental is not a clever tactic. It exposes the company to a review it would deserve, and the person who carries that exposure is the director signing the return, not the consultant who wrote a flattering narrative. We would rather hand your adviser a short, defensible record covering the two things that genuinely were uncertain than a long one covering everything we did. Your adviser will make the call about what goes in the registration, and a conservative record makes their job easier.
What a Contemporaneous Record Actually Contains
This is the shape your adviser will ask for, and it follows the elements business.gov.au sets out for a systematic progression of work based on principles of established science: hypothesis, experiment, observation, evaluation and logical conclusions. It is not paperwork for its own sake, and most of it is worth having even if you never claim a cent.
The knowledge gap
A short, honest statement of what was not known and could not be found. Which sources were checked, what the current publicly available approaches were, and why they did not resolve the question for this situation. This is the part that separates genuine uncertainty from unfamiliarity, and it is worth writing early because the search itself often reveals that somebody has already solved the problem, in which case the work is ordinary development and you have saved yourself money.
The hypothesis
The specific proposition to be tested, stated before the work rather than after it. Something that can be shown to be wrong: this retrieval strategy will hold accuracy above the threshold on messy production records, this approach will keep latency under the ceiling at realistic volumes. A hypothesis you cannot fail is not a hypothesis, and a record full of unfalsifiable statements reads exactly as badly as it sounds.
The experiment
The design of the test: the data used, the conditions held constant, what was varied, how success and failure would be measured, and how many iterations were planned. Systematic progression matters here. A record that reads as a sequence of controlled attempts is a different document from one that reads as a person trying things until something worked, even when the underlying week looked similar.
The observation
Results captured at the time, including the failures. Evaluation runs with dates, the measurements taken, the outputs that were wrong and how they were wrong. The failed attempts are the most persuasive material in the whole record, because a claim that every experiment succeeded first time is not describing an experiment. Keep the raw artefacts, not just the summary.
Evaluation and logical conclusions
Evaluation is a named element in its own right on the regulator’s checklist, so write it as one: the results measured against the hypothesis you stated, then what new knowledge was generated, what was rejected, and what the team decided to do next as a result. Where a hypothesis was disproved, say so plainly and record what that ruled out. Where the answer led to a further question, that becomes the next experiment and the chain continues. This section is what makes the record useful to your own engineers a year later, quite apart from any claim.
The evidence trail
Version control history, evaluation outputs, test data snapshots, meeting notes where a direction was chosen, and the timesheet or task records showing who spent time on which activity. Dated automatically by the systems doing the work rather than typed up later. Your adviser will ask how expenditure was apportioned between experimental and supporting activity, and this is the material that answers it.
The Same Build, With and Without the Record
| Task | Traditional | Documented as we build | Notes |
|---|---|---|---|
| Deciding what counts as experimental | Argued at year end from memory | Flagged at the point the question arose | Nobody remembers in June which week in October the accuracy problem was genuinely unsolved. |
| Recording a failed approach | Deleted and forgotten | Kept, dated, with what it ruled out | Failures are the strongest evidence that an experiment was real. They are also the first thing teams throw away. |
| Apportioning time | Estimated in a spreadsheet later | Task records tagged as the work happens | Apportionment is where reconstructed claims most often fall apart under questioning. |
| Evaluation results | Screenshot in someone’s chat history | Stored runs with dates and inputs | A reproducible evaluation is both better engineering and better evidence. You would want it anyway. |
| Explaining the knowledge gap | Written from scratch in month eleven | Captured before the work started | Writing it early sometimes shows the gap does not exist, which saves the claim and the build cost. |
| Separating core from supporting work | One narrative covering everything | Experiments isolated from ordinary build | A narrower record is usually stronger than a broad one. Your adviser decides where the line sits. |
| Handover to the R&D adviser | A long interview and a lot of guessing | A pack they can work from directly | Advisers charge for the reconstruction. Handing them a record shortens that engagement. |
| If the activities are reviewed | Reconstructed under time pressure | Already written and dated | The difference between an uncomfortable fortnight and sending a folder. |
Where Software R&D Claims Go Wrong
Treating the whole project as core R&D
A build almost always contains a small amount of genuinely experimental activity surrounded by a large amount of ordinary engineering, configuration, data migration, user interface work and testing. Registering the lot as core activity is the single most common overreach in software claims. Your adviser will want the experimental activities isolated and the supporting activities identified separately, and a record built that way from the start makes their job possible rather than adversarial.
Confusing new to us with new to the field
Teams routinely describe work as experimental because it was unfamiliar to them. That is not the test. If a competent professional in the field could have determined the outcome in advance using publicly available knowledge, it is ordinary development regardless of how much your team learned. Doing the background search honestly before you start is the cheapest way to find this out, and it occasionally saves you from building something that already exists.
Reconstructing the record at year end
Documentation written months after the fact, from memory and a handful of commits, is weaker evidence and considerably more expensive to produce. It also tends to be optimistic, because the person writing it now knows the answer and unconsciously describes the work as more systematic than it was. Build the habit into delivery instead: one short entry per experiment, written the same week, with the artefacts attached.
Missing the registration deadline
Registration with AusIndustry must be lodged within 10 months of the end of the company’s income year, and the claim itself goes through the company tax return. A company with a 30 June year end therefore has a hard date the following April. Excellent documentation for a year you did not register is worth nothing, so put the date in the calendar of whoever owns it and treat it as immovable.
Assuming an offset is a certainty and spending against it
We will never tell you that you will receive an offset, and you should be wary of anyone who does. Eligibility is determined by AusIndustry and the ATO, the claim is substantiated by your adviser, and outcomes vary. Making a build decision that only stacks up if a refund lands is a financing decision, not a technical one, and it belongs with your accountant and your board rather than with your integration consultant.
Nobody owning the record inside the business
The pattern that works has one named person, usually the technical lead or the finance manager, who owns the experiment log and reviews it monthly against timesheets. The pattern that fails has the documentation living with an external supplier who finishes the build and moves on. Ask for the record in a format you keep and can continue after we leave, and make sure someone internal has read it while the work is still fresh.
What We Do and What We Firmly Do Not Do
We record the experimental work as it happens
Where a build contains genuine technical uncertainty, we write the hypothesis before the work, capture the experiment design, log the observations including the failures, evaluate them against what we expected, and record the conclusions. Dated as it happens, with version control history and evaluation runs attached, handed to you in a format your adviser can work from directly.
We do not give tax advice or assess eligibility
We are not accountants and we are not registered tax agents. We will not tell you whether your project qualifies, we will not estimate an offset, and we will not tell you that you will receive one. AusIndustry and the ATO determine eligibility. Your accountant or a registered tax agent who specialises in R&D substantiates and lodges the claim. Everything on this page is general information only.
We will tell you when the work is not experimental
Most of what we build is competent application of known techniques, and that is not core R&D. If your build is configuration, integration of documented interfaces, or an approach whose outcome was knowable in advance, we will say so at scoping rather than write a flattering narrative you later have to defend. A cheaper honest answer beats an expensive optimistic one.
The effect on price is indirect, and we say so plainly
A well documented experimental build can end up materially cheaper for the company after a claim, without us discounting the work. That is a benefit your adviser realises, not a discount we control or guarantee. We charge for the build. Whether any part of it becomes an offset is between you, your adviser and the regulators.
How the Record Gets Built Alongside the Work
Five steps, none of which involve us expressing a view on your tax position. General information only, not tax or financial advice.
Identify the uncertainty at scoping, or rule it out
Before quoting we work out whether any part of the build has an outcome that genuinely cannot be determined in advance. We search for existing approaches first. If there is no real gap, we say so and the record stops here, which is the honest outcome for most projects.
Introduce your adviser early
If there is something experimental, we ask you to bring your accountant or a registered tax agent who specialises in R&D in at the start rather than at year end. They tell us what evidence they want and in what form. We write to their requirements, not to a template of ours.
Write the hypothesis before the experiment
Each uncertain question gets a short entry stating what is not known, what we expect, how it will be tested and what would count as failure. Written and dated before the work starts, so it cannot be shaped by the answer.
Capture results as they arrive, failures included
Evaluation runs, measurements, rejected approaches and the reasoning behind each change of direction, logged the week they happen with version control history and task records attached rather than summarised later.
Hand the pack to your adviser and get out of the way
At the end of each phase you get the experiment log, the evidence trail and the time apportionment records in a format you own and can keep maintaining. Your adviser decides what is registered and what is claimed. We do not.
Related Reading
Is My AI Project Eligible for R&D?
The honest test, applied to real software situations. Most projects fail it.
How to Write an AI Project Brief
Getting the uncertainty and the success measures stated before anyone builds.
AI Pilot to Production Checklist
What has to be true before an experiment becomes a system you rely on.
Custom LLM Development
Where genuine technical uncertainty tends to show up in language model work.
AI for CFOs and Finance Teams
The finance side of the house, including who should own this record.
AI Implementation Roadmap
Sequencing a programme so the experimental part is small and early.
FAQ
Building Something Genuinely New? Let’s Get It Recorded Properly
Book a scoping call. We will tell you honestly whether the build contains real technical uncertainty, and if it does not, we will say that too. General information only, not tax or financial advice. Phone (03) 9003 0111.
All discussions held in confidence. Australian-based consultants.