1. Define the technical objective
The R&D objective is not the same as the commercial objective.
A company may want to launch a product, automate a process, reduce costs or meet a customer requirement. Those objectives explain why the project exists, but not why the underlying work qualifies as R&D.
A credible R&D objective should identify:
- the scientific or technological outcome sought;
- the limitation of the knowledge, technology or methods available when the work started; and
- the technical challenge that had to be overcome.
For example, "develop a faster transaction-processing platform" is a commercial or product objective. A potential R&D objective would identify the specific performance gap that existing architectures could not achieve and the technical work required to investigate it.
The R&D project may be narrower than the commercial project
A product-development programme can contain qualifying R&D alongside routine engineering, user-interface work, integration, regulatory activity, manufacturing preparation and commercial launch work.
The eligibility assessment should isolate the technical work directed at resolving the scientific or technological challenge rather than treating the whole commercial programme as R&D.
2. Establish novelty or technical risk
Novelty
A project can satisfy the novelty branch where the product, process or knowledge developed is first of its kind in Singapore and involves more than a minor or routine improvement.
Adopting an existing technology, configuring a commercial platform, customising a product or applying a known solution in a new context does not establish novelty by itself.
Where novelty is relied upon, supporting evidence may include prior-art or patent searches, technical literature, benchmarking and documented comparison with available solutions.
Novelty alone is not sufficient: the project must still have an R&D objective and involve a systematic, investigative and experimental study.
Technical risk
For many engineering, software and technology projects, technical risk is the more relevant route.
The question is:
Could a competent professional in the relevant field have readily determined how to achieve the required technical outcome using existing knowledge and established methods?
If the answer is no, there may be a genuine scientific or technological uncertainty.
Technical uncertainty can arise from areas such as material behaviour, scale-up, algorithmic or architectural performance, system interactions, reliability, accuracy, latency, security or technically uncertain combinations of existing technologies.
Commercial risk, tight deadlines, lack of internal expertise, supplier issues, regulatory uncertainty, ordinary debugging or normal engineering difficulty do not establish technical risk by themselves.
The test is objective: it is not whether the company's own team knew the answer, but whether an appropriately knowledgeable professional could have readily derived it from available knowledge and established methods.
3. Show a systematic, investigative and experimental study
A technical uncertainty is not enough on its own. The company must investigate it through a structured technical process.
A qualifying pattern typically includes:
The work may involve prototypes, simulations, controlled trials, modelling, test rigs, algorithmic experiments, alternative designs or performance benchmarking. The specific form depends on the project.
The important distinction is the purpose of the work. Testing that merely confirms a known design, verifies compliance, commissions equipment or checks that software performs to specification is generally routine. Testing is more relevant to R&D where it is used to distinguish between uncertain technical alternatives and the results determine the next investigative step.
The number of iterations is not decisive. Many iterations can still be routine; a smaller number of well-designed experiments can support R&D where they genuinely investigate a non-readily-deducible technical problem.
4. Define the project boundary
Many projects contain both qualifying and non-qualifying activities. Establishing where the R&D begins and ends is therefore central to the assessment.
The R&D phase generally starts once a scientific or technological objective has been identified and work directed at resolving that challenge begins. It generally ends when the experimental work reaches a technical conclusion, demonstrates the required functionality or is terminated.
Routine implementation, production rollout, standard commissioning, customer deployment, marketing, patent filing and ongoing support normally sit outside the R&D boundary.
Common non-qualifying activities also include routine quality assurance, ordinary debugging, standard configuration or integration, known-method optimisation, market research, commercial feasibility work and cosmetic or stylistic changes.
A project can also qualify even if it ultimately fails. Eligibility depends on the technical objective, uncertainty and experimental process, not on commercial or technical success.
How the test applies in practice
Software, AI and digital projects
Software and AI projects can qualify where they address a genuine technological limitation that cannot be readily resolved using established methods.
Potential examples include work on algorithms, architectures, data-processing methods, security, machine-learning methods or performance constraints involving accuracy, latency, robustness or computational efficiency.
Routine application development, user-interface work, business-rule implementation, standard API integration, data migration, maintenance, debugging and user-acceptance testing do not qualify simply because they form part of a large proprietary platform.
Using or fine-tuning an available AI model is not R&D by itself. The relevant question remains: what was technically unknown, and what experimental work was required to resolve it?
Manufacturing, engineering and physical products
Engineering and manufacturing work can qualify where established technical knowledge does not readily provide the required solution—for example, where there is genuine uncertainty around material behaviour, process parameters, scale-up, reliability, thermal or mechanical performance, chemical interactions or product integration.
Adjusting known settings within established operating ranges to meet an existing specification is routine engineering, even where experienced engineers and substantial testing are required.
Evidence that supports the eligibility position
The strongest assessment is based on evidence created while the project is being carried out.
Relevant records can include technical plans, design documents, prior-art analysis, specifications, hypotheses, models, prototypes, experimental protocols, source-control history, test records, issue logs, failed trials, redesign decisions and technical conclusions.
Formal R&D reports are not the only form of evidence. Contemporaneous emails, engineering notes, source-code history and working documents can also demonstrate what was unknown, which alternatives were investigated and what was learned.
How Reeve | R&D assesses technical eligibility
We structure the assessment around five questions:
- What was the scientific or technological objective?
- What was not known or readily deducible at the start?
- Why could established knowledge or methods not solve it directly?
- What alternatives were investigated, tested and learned from?
- Which activities belong inside the R&D project boundary?
The output is a defined technical R&D position that can be carried consistently into the expenditure analysis, documentation and wider claim—not simply an eligible / not eligible label.
Understand qualifying R&D expenditure
Tell us what your company is developing, what technical problem it was trying to solve and what work was undertaken. We can assess whether a qualifying R&D project can be identified and define the technical scope before moving into the wider claim.
R&D eligibility FAQs
Does software development qualify as R&D?
It can, where the work addresses a genuine technological challenge that could not be readily resolved using existing knowledge and potential solutions were investigated experimentally. Routine coding, customisation, integration and testing do not qualify on scale or complexity alone.
Does product development automatically qualify as R&D?
No. A wider product-development programme may contain a narrower qualifying technical R&D project, but commercial innovation and routine engineering do not establish R&D eligibility by themselves.
Does R&D need to be novel in Singapore?
Not necessarily. Novelty and technical risk are alternative routes under the R&D test.
Can unsuccessful R&D qualify?
Potentially, yes. Eligibility depends on the technical objective, uncertainty and experimental work rather than whether the final solution succeeds.
Can only part of a larger project qualify?
Yes. The qualifying technical core should be separated from routine engineering, implementation, commercial development and other non-R&D activities.