Where engineering businesses often overlook R&D
In a recent article I compared the R&D Tax Incentive (R&DTI) process to a marathon rather than a sprint. In practice, most innovation within engineering businesses does not occur through a single breakthrough moment, but through engineers gradually working through design challenges - testing ideas, refining prototypes and adjusting designs as new constraints emerge.
One of the more interesting aspects of the R&DTI is that many businesses undertaking genuine R&D do not necessarily recognise it as such.
For engineering and product development businesses, work that feels like routine engineering problem-solving can sometimes involve resolving genuine technical uncertainty. As the 30 April deadline for registering R&D activities approaches (for companies with a 30 June year end), it can therefore be worthwhile stepping back and reviewing whether work undertaken during the year may in fact fall within the R&D framework.
In particular, the following situations are often where engineering businesses unknowingly undertake R&D.
Solving technical problems where the answer was not obvious
Many engineering projects begin with a technical objective - for example achieving a specific performance outcome, adapting equipment to operate reliably within challenging environmental or operating conditions, or designing a component to meet tight structural or environmental constraints.
In some cases the solution is relatively clear and can be achieved using established engineering methods.
In other cases, however, the path forward is less certain. Engineers may need to test alternative approaches, adjust design parameters or trial different configurations before identifying a workable solution.
Where the outcome could not be determined in advance using existing knowledge or standard engineering practice, the work may involve resolving technical uncertainty, which is a key feature of R&D.
Iterative design and experimentation
Engineering development rarely follows a straight line.
Components are redesigned, prototypes are modified, assumptions are revisited and new constraints emerge as projects progress. Engineers often work through these challenges by testing different options and refining designs as more information becomes available.
In many projects, these iterations occur as engineering teams work through unexpected technical constraints or performance issues that only become apparent once systems are tested in practice or deployed within complex operating environments.
Internally, this process is often simply viewed as working through the engineering problem.
However, from an R&D perspective, this type of systematic experimentation and iterative development can represent the core of an R&D activity. Because these activities occur naturally within project work rather than as a formally labelled research program, they are frequently overlooked.
Development work embedded within commercial projects
Another reason R&D is commonly missed in engineering businesses is that it is often embedded within commercial work.
A project may require designing equipment that has not previously been built, modifying materials to withstand demanding operating environments, or adapting a product to perform reliably within a client’s specific operating conditions - whether that involves hydraulic performance, structural constraints, environmental exposure, or integration with existing infrastructure.
For example, engineering teams may find themselves refining designs to address unexpected hydraulic behaviour, structural performance under load, or material durability in harsh environments.
Because this development occurs as part of delivering a contract, the work may simply be viewed as part of completing the project.
However, where engineers are required to resolve technical problems that cannot be addressed through established methods alone, the work may still fall within the scope of the R&DTI.
Documentation that already exists within the business
When businesses think about R&D claims, they often assume that formal research documentation must exist.
In reality, engineering businesses frequently already hold much of the evidence - often in informal forms of documentation - needed to explain how technical problems were investigated and resolved.
Design drawings, prototype revisions, engineering notes, test reports, internal project documentation and technical communications can all help demonstrate how a particular technical challenge was approached.
Reviewing this information while the details of the work are still fresh can make it significantly easier to determine whether R&D may have occurred.
The broader intent behind the incentive
It is also worth keeping in mind the broader policy objective behind the R&DTI. It is designed to encourage businesses to undertake development work that might otherwise not proceed because the technical outcome - and the return on that investment - is uncertain.
For engineering and product development businesses, recognising where informal R&D is already occurring can therefore have a practical impact beyond the claim itself. When experimentation and technical problem-solving are properly identified as R&D, businesses may be more willing to pursue challenging development work rather than stepping back from projects due to cost or uncertainty.
Taking a step back before the deadline
As the 30 April deadline approaches, many businesses focus on gathering information for activities they already know qualify as R&D.
However, it can be equally valuable to step back and consider whether problem solving and informal development work undertaken during the year - particularly work involving technical uncertainty or iterative design - may represent R&D that has not previously been identified.
For many engineering and product development businesses, genuine R&D occurs naturally as part of solving complex technical problems. The challenge is often simply recognising where that work sits within the R&D framework.
Reviewing projects with this perspective in mind before the 30 April deadline can often reveal development work that may otherwise have been overlooked.
