This pillar is arguably the most critical and often the most challenging to substantiate. The project must involve an element of novelty or, more commonly, address a technical risk. This concept is defined by IRAS as a “scientific or technological uncertainty that cannot be readily resolved by a competent professional in the relevant field”.

This definition sets a high bar. It is not enough for a project to be new to the company or even new to Singapore if the solution is readily deducible using existing knowledge and standard industry practices. The core of this pillar is the presence of genuine uncertainty. Examples of activities that may satisfy this test include:

• Integrating two or more technologies for the first time, where the outcome of the integration is uncertain.
• Using existing technology to produce new goods or deliver services in fundamentally new ways.
• Developing a new process to manufacture a product, even if the final product itself is not new.
• Fundamentally changing the physical characteristics of a product, beyond cosmetic alterations.

The phrase “not readily resolved by a competent professional” is the true gatekeeper of the R&D incentive. It fundamentally shifts the nature of the required documentation and the internal processes needed to generate it. While the “Objective” and “SIE Study” pillars are largely procedural—requiring evidence of planning and systematic execution—the “Technical Risk” pillar is substantive. It compels the taxpayer to prove a negative: that the solution was not obvious, not straightforward, and not achievable through the application of standard engineering or scientific principles.

This has profound implications for how a company should prepare its R&D claim. The claim ceases to be a simple accounting exercise of tallying salaries and material costs. It transforms into a technical thesis, where the central argument is the inherent difficulty of the problem being solved. The primary evidence is no longer financial ledgers but technical documents: literature reviews, patent searches that show a lack of prior art, detailed records of failed experiments, and expert opinions that attest to the project’s challenges. Consequently, the primary authors of the R&D claim’s justification must be the engineers and scientists who lived the uncertainty. The finance and tax teams play a crucial, but supporting, role in costing the activities and structuring the claim. This reorientation is essential for building a defensible position that can withstand IRAS scrutiny.

The final pillar mandates that the R&D activity must be conducted in a structured and methodical manner. It must be a “Systematic, Investigative, and Experimental study in a field of science or technology”. This requirement distinguishes genuine R&D from ad-hoc problem-solving or random trial and error.

The key elements of an SIE study include:

• Systematic: The work must follow a logical progression based on a plan. This often involves iterative processes where hypotheses are formulated, tested, and modified based on the results.
• Investigative: The activities must be designed to explore and uncover new information to resolve the technical uncertainties identified under the second pillar.
• Experimental: The project must involve a series of structured steps to test potential solutions. This can include modeling, simulation, prototype development, and systematic trial-and-error methodologies.

Crucially, the outcome of the project is irrelevant to its qualification. R&D tax benefits can be claimed regardless of whether the project was successful. In fact, well-documented evidence of unsuccessful attempts and the steps taken to learn from them can be a “persuasive indicator that the outcome is not readily deducible,” thereby strengthening the claim under the “Technical Risk” pillar. The entire process, from initial hypothesis to final conclusion—including all failures along the way—must be documented to demonstrate that a rigorous SIE study was undertaken.

A Blueprint for Best Practices

While the e-Tax Guide explains the “what,” the R&D Assurance Framework provides a clear indication of the “how.” This framework is an initiative that allows taxpayers with significant and consistent R&D activities to apply for upfront certainty on their claims for up to three Years of Assessment.15 Eligibility requires a company to have at least five in-house R&D projects and qualifying expenditure of at least S$500,000 in the year of application.

However, the true value of the framework extends to all taxpayers, not just those who apply. The application form for the R&D Assurance Framework effectively serves as a public statement of IRAS’s “gold standard” for internal controls and documentation. A careful analysis of the application’s requirements reveals a detailed checklist of best practices. Key requirements include:

• A Documented Evaluation Process: The applicant must declare that it has “a documented evaluation process for evaluating whether non-routine projects meet the conditions of the R&D Tax Measures”.6 This points to the need for a formal, written internal procedure for identifying and vetting potential R&D projects.
• Contemporaneous Documentation: The form explicitly requires confirmation of “contemporaneous documentation to show how the expenses for qualifying R&D projects are identified and accounted for”.6 This signals that records created after the fact are viewed with skepticism; the best evidence is that which is generated in real-time as the R&D work progresses.
• Specific Record-Keeping: The application demands sample records to demonstrate cost tracking, providing examples such as “Timesheets to verify the amount of time spent on R&D (vs non-R&D) activities” and “Cost breakdown and invoices to link other expenses to R&D”.
• Comprehensive Project Listing: Applicants must provide a complete list of all projects undertaken, both those claimed as R&D and those considered routine, to demonstrate a clear and defensible selection methodology.

This framework’s application form is, in essence, a compliance blueprint available to all. While the US system requires taxpayers to analyze complex court cases to infer documentation standards, Singapore’s system provides a more direct, if less widely understood, roadmap. A prudent taxpayer can reverse-engineer these requirements to build an audit-proof documentation file from the ground up. By structuring internal R&D project management and accounting systems to align with the framework’s application criteria, a company can proactively address the very questions IRAS is likely to ask during a review, significantly strengthening its claim and minimizing compliance risk.

For particularly complex or contentious cases, IRAS may refer a claim to its Technical Advisory Panel for review. This panel consists of experts from various scientific and technological fields who advise IRAS on the technical merits of a claim. The existence and use of this panel further underscore the technical, rather than purely financial, nature of the R&D claim review process. It reinforces the necessity for documentation to be not only financially accurate but also scientifically robust and clearly articulated in a way that a technical expert can understand and validate. This reality places a premium on the quality of technical write-ups, lab notebooks, and other evidence that speaks directly to the project’s scientific or technological challenges.

• Patent Search Results & Literature Review Summary: A report summarizing the initial research (from Activity I, though the activity itself doesn’t qualify) that demonstrates no existing public knowledge or commercially available product meets the project’s technical objectives. This proves the “novelty” aspect.
• Technical Memoranda from Lead Scientist/Engineer: Contemporaneous notes detailing the specific scientific uncertainties. For Activity III, this could be a memo titled “Challenges in Achieving Crystalline Structure in Polymer Blend XYZ.” For Activity IV, it might be “Uncertainty in Sensor Response Time for Real-Time Thermal Feedback Loop.”
• Documentation of Alternative Approaches Considered: Records of brainstorming sessions or internal reports showing that standard, off-the-shelf solutions were evaluated and deemed insufficient, thus necessitating a novel R&D approach.

• Detailed Test Plans: Formal documents outlining the methodology, variables, and success criteria for each experimental batch of the polymer (Activity III) and each iteration of the control software (Activity IV).
• Laboratory Notebooks (Digital or Physical): The most critical contemporaneous evidence. These notebooks should contain dated entries for each experiment, recording the parameters used, observations made, raw data collected, and initial analysis.
• Failure Analysis Reports: For the many failed polymer formulations in Activity III, detailed reports explaining why they failed (e.g., “Batch #27 exhibited poor layer adhesion due to premature curing”). This documentation is powerful evidence of an iterative process and the presence of technical risk.
• Software Development Logs & Version Control History: For Activity IV, records from systems like Git showing the iterative development of the control software, including code comments explaining changes, bug fixes, and the evolution of the control algorithm.

• Employee Timesheets: Digital or paper timesheets where R&D personnel allocate their hours to specific project codes (e.g., “PROJ-POLYDEV” for Activity III, “PROJ-PROCESSINT” for Activity IV) to distinguish qualifying R&D time from other duties.
• Invoices for Consumables: A file of all invoices for raw chemicals, lab supplies, and the specialized thermal sensors. Each invoice should be annotated with the project code to which the materials were allocated.
• Cost Allocation Summary: A master spreadsheet that serves as the bridge between the technical activities and the financial claim. It should list every claimed expense (e.g., salary cost for Scientist A for a specific month, cost of a specific chemical) and link it directly to a qualifying R&D activity (III or IV) and a specific piece of supporting technical documentation (e.g., a lab notebook entry).