Is it eligible?

Is fine-tuning a large language model eligible R&D?

Sometimes eligible

Sometimes. Fine-tuning an LLM is core R&D only when a competent ML engineer could not predict, from published methods and results, whether your fine-tuning approach would reach a stated target, and you resolve that by planned experiments. Running a documented recipe on your own data to an expected improvement is applying known methods, not R&D.

Reviewed by George WalchFacts last verified

When it qualifies

Keeping tool calling while adapting to legal text

An illustrative legal software company fine-tunes an 8B open-weights model on Australian case summaries and needs citation accuracy above 90% while keeping function-calling accuracy within 2 points of the base model. Published forgetting mitigations (replay mixes, regularisation) report general-domain benchmarks, not tool-use retention under this data mix, and its ML lead records that no paper predicts the result. It plans four variants, varying replay ratio and adapter rank against a frozen eval set, and each result sets the next variant.

When it does not

Instruction-tuning a support bot on old tickets

A company formats 20,000 resolved support tickets to its model provider's fine-tuning guide and runs the provider's default job, expecting better tone and fewer wrong answers, and gets exactly that. Nothing was unknown to a competent ML engineer beforehand, so there is no core activity, and the ticket cleaning is not supporting R&D either because there is no experiment for it to support.

The evidence that supports it

  • A dated review of model cards, technical reports and papers on the fine-tuning methods considered, written before the first run, stating why none settled the target.
  • An experiment plan per family of runs naming the base model, the variable changed, what was held fixed, the eval set and the pass threshold.
  • Experiment tracker runs with loss curves and per-checkpoint eval scores, linked to the plan they tested.
  • Versioned held-out eval sets (with hashes or tags) so variants are compared on identical data.
  • Notes on each abandoned variant and the reasoning that chose the next one.
  • Pull requests that change the training objective, data mix or adapter code, with their dates.

Fine-tuning is not a category the law knows. Division 355 asks the same thing of a fine-tune as of any software work: was there a technical outcome nobody could determine in advance, and did you resolve it by hypothesis, experiment and evaluation? For most fine-tuning the honest answer is no, because the recipes are published and they work. For some, the answer is yes.

What AusIndustry says about fine-tuning

AusIndustry's page on AI-related activities gives a fine-tuning example that may be core: investigating a novel fine-tuning strategy "whose effects are not well-understood", where established methods had failed to resolve a scaling problem. The same page lists adjusting parameters such as learning rate as unlikely to be core when "the effect of changing the parameter is well understood". It also says plainly that using AI in development does not make an activity eligible. So the line does not run between fine-tuning and other work. It runs between applying a fine-tuning method and investigating one.

Three questions for any fine-tune

  1. What is the target? A measurable threshold, for example extraction F1 of 0.92 on a held-out set from a 7B model served under 300 ms on one GPU. "Make the model better at our domain" is a goal, not a hypothesis.
  2. What does published work say? Model cards, technical reports, papers on parameter-efficient methods, vendor fine-tuning documentation and public community fine-tunes all count as available knowledge. If they show a standard recipe reaching your kind of target under comparable conditions, the outcome was usually knowable. A published recipe does not settle every task, though: where your data, constraint or combination of targets differs in a way that matters, record why the published results do not carry over.
  3. What would a competent professional predict? If an experienced ML engineer would say the standard recipe will work and it just needs compute, there is nothing to test.

Where the answers leave a real gap, the work of building and running each variant is the experiment itself. Cleaning and formatting data to a model's documented input requirements is listed by AusIndustry as unlikely to be core; it can be a supporting activity when it exists for a genuine experiment.

Eval noise is not uncertainty

Every fine-tune's eval scores move between runs and seeds. That is not the uncertainty the law means. In Coal of Queensland [2021] FCAFC 54 the Full Federal Court separated an activity's outcome from the precise data it produces: not knowing the exact number in advance does not mean the outcome could not be known. Ask whether an ML engineer could have known your approach would clear the threshold, not whether they could have guessed the third decimal place.

Edge cases peculiar to fine-tuning

  • Vendor fine-tuning endpoints. When you upload examples to a provider's hosted job, you control the data and a handful of settings, not the method. Any genuine question usually lives in the data mix or the objective, and must be framed that way. The wider position on hosted models is on the third-party AI APIs page.
  • Distillation. Training a small model on a larger model's outputs is assessed the same way: published distillation results for your task and size settle many cases.
  • Retraining on fresh data. Once the approach works, rerunning it each quarter on new data is business as usual. A core activity ends when its uncertainty is resolved.
  • Hyperparameter sweeps. A sweep can be the way you test a stated hypothesis, but a sweep does not create one.

Training a model from scratch raises different questions, covered under training machine learning models. For how AI companies group this work into activities, see R&D for AI companies, and for the GPU bill, cloud compute costs.

Frequently asked questions

Does using LoRA, QLoRA or another adapter method change the answer?
No. The method's name decides nothing. Applying a well documented parameter-efficient method at its published settings is using known techniques. Investigating an adapter configuration or training objective whose effect under your memory, latency or data limits has not been published may be an experiment, if you planned and evaluated it as one.
Our fine-tune did not beat the base model. Is that work lost?
Not if it was a planned experiment. A disproved hypothesis is still a conclusion. The failed variants support the uncertainty case when your review of published methods and the result you expected were recorded first, though they do not prove it on their own. See the page on failed experiments for how to record them.
Is a brand new base model enough to make fine-tuning uncertain?
Not by itself. A recent release still has a model card, a technical report and, within weeks, community fine-tunes. Check those before you start and record what they did and did not show. A gap exists only if that search leaves your specific question open.
Can we claim the GPU time we rented for fine-tuning runs?
The share used for registered experiments can be claimed as R&D expenditure (a notional deduction under s 355-205), apportioned on a reasonable basis. Serving the fine-tuned model to customers is production use. Your accountant confirms the figure that goes in the ATO schedule.

Sources

  1. AusIndustry (business.gov.au): Artificial intelligence-related activities and the R&D Tax Incentive
  2. AusIndustry (business.gov.au): Software development sector guide for the R&D Tax Incentive
  3. Income Tax Assessment Act 1997 (Division 355), Federal Register of Legislation

The R&D Tax Incentive is a self-assessment program. This page is general information, not tax, legal or financial advice; eligibility depends on your circumstances and you should seek independent advice for them.