- By Michelle Giuricich | Lead Technical Consultant, Catalyst Solutions
Section 11D of the Income Tax Act allows companies to claim a 150% deduction on qualifying research and development expenditure. Among the key qualifying criteria under S11D, two are fundamental to determining whether an activity constitutes R&D at all: it must involve scientific or technological uncertainty, and it must be approached systematically. This article deals with the first of those two requirements.
The uncertainty test is where most businesses get the qualifying question wrong, in one of two directions. Some dismiss work that would clearly qualify because they assume R&D means white coats and laboratories. Others describe routine engineering as R&D because the problem they solved was difficult and the project took longer than expected. Neither reading is right. Uncertainty in the Section 11D sense is a specific concept with a specific test, and applying it accurately is the difference between a claim that survives DSTI review and SARS audit and one that does not.
Uncertainty exists when a competent professional working in the relevant field, with access to the existing body of knowledge, cannot predict whether a particular approach will succeed or how a defined technical outcome can be achieved. The test sits at the level of knowledge, not at the level of project execution. A project can be difficult, expensive, and behind schedule without involving uncertainty in the S11D sense, because difficulty and uncertainty are not the same thing.
The legislation refers to scientific or technological uncertainty as a single compound concept, but the two sit differently in practice. Scientific uncertainty is foundational. The question is whether something is possible at all, whether a hypothesis about how a system behaves holds, whether a chemical or biological mechanism works the way the underlying theory suggests it should. Technological uncertainty assumes the underlying science is known and asks a different question. The principle is known, but whether and how that principle can be applied to achieve a defined outcome within real-world constraints is not. Both qualify under Section 11D. This distinction is not drawn explicitly in the Act, but it is a useful interpretive tool in practice. Confusing them weakens the technical narrative because the evidence each one requires looks different.
In our experience, a useful way to explain the distinction is this: scientific uncertainty lives in the question of whether something is true or possible. Technological uncertainty lives in the question of whether something theoretically possible can actually be made to work under real conditions. In manufacturing and engineering, most of what we see sits in the technological uncertainty space. Life sciences and advanced materials work more commonly involves scientific uncertainty, sometimes both.
Four things get mistaken for uncertainty regularly, and each one fails the test for a different reason.
Routine problem-solving is the most common. Engineering teams across South Africa solve difficult problems every week. A manufacturing line goes down and the team works for three days to bring it back up. A software product has a critical bug that takes a week of focused debugging to trace. A process is optimised to reduce waste or improve throughput. All of this is real, difficult, valuable work, but none of it qualifies as R&D under Section 11D, because at no point did a competent practitioner not know what to do or whether a defined approach would work. The methods were established. The outcome was predictable, even if it took effort to achieve.
Commercial uncertainty is the second. Companies frequently invest in projects where the technology is established but the business outcome is not. Will customers buy this? Will the price point work? Will the regulatory environment allow it? Will the market accept the new format? These are genuine business risks but they are not what Section 11D tests. Section 11D tests technological and scientific uncertainty, not market uncertainty.
Scaling a known process is the third. Taking something that works at laboratory or pilot scale and producing it commercially can qualify, but only where the scaling itself introduces technological uncertainty that established engineering principles could not resolve. If the scale-up is hard but the route is known, it is not R&D. If the scale-up reveals a problem that existing knowledge does not solve, the work to resolve that problem may qualify.
Adopting existing technologies in a new setting is the fourth. Implementing a system that is new to your business but established in the field is not R&D, regardless of how much internal effort the implementation required. A first deployment of a known platform, technique, or method in your specific environment is integration work, not research and development.
The most common version of this confusion comes from the software sector. A client approached us with what they described as a qualifying R&D project: a cloud-based IoT-as-a-service platform being built for the telecommunications industry. It was a substantial piece of work, genuinely complex, and the team had invested considerable time and resource into it. From the outside, it had the feel of an innovative technology project.
When we got into the detail with their technical team, a different picture emerged. The solution was being built on a well-established stack: AWS IoT Core, DynamoDB, Lambda, API Gateway, and similar services. Each of those tools was mature, well-documented, and widely used in exactly this kind of architecture. The development work involved integrating and configuring these components to meet the specific requirements of the telecommunications context, which required skill and careful design, but the methods were known and the outcomes were predictable to a competent developer working in that space.
The team’s activities involved strong, considered software engineering, but that was the distinction that mattered. The uncertainty they experienced was commercial and operational in nature, not scientific or technological. Difficulty of execution is not the same as scientific or technological uncertainty, and in this case the two had been confused.
Here are four examples from sectors where Section 11D claims are common. Each one shows what genuine uncertainty looks like when it appears in real technical work.
A software company building a real-time fraud detection system for a financial services client. The existing models in the field handle either high transaction volumes with low complexity or low volumes with high complexity, but not both at the level the client required. The team did not know whether a hybrid architecture could maintain sub-100-millisecond response times at the transaction volumes specified, and the existing literature offered competing answers. The uncertainty was technological. The principle of fraud detection was established, but achieving the performance envelope within the client’s infrastructure constraints required experimental work that established methods could not predict.
A food and beverage manufacturer investigating whether a novel enzyme derived from a locally sourced fungal strain could be used to extend the shelf life of a minimally processed dairy product. The enzyme class was known in the literature, but its behaviour in a low-pH, high-fat matrix had not been studied, and the team did not know whether it would remain active across the target shelf life or whether it would interact with the existing protein structure in ways that degraded texture or flavour. The uncertainty was scientific. The question was not how to apply a known solution but whether the biological mechanism would function as hypothesised in this matrix at all. Early trials produced inconsistent activity levels across batches, and the team could not predict from the existing knowledge base whether the variability was a function of the enzyme, the substrate, or the interaction between the two.
A mining operation developing a new tailings treatment process to recover residual platinum group metals from material previously considered uneconomical to reprocess. The metallurgical principles were known, but the ore body’s specific mineralogy meant the established recovery flowsheet did not apply directly. The team did not know whether the modifications required to handle the mineralogy would achieve recovery rates above the commercial threshold, and the early test work produced inconsistent results across different sample batches. The uncertainty was technological. The science of recovery was known, but the method of applying it to this material was not.
A pharmaceutical company developing a generic equivalent of an off-patent oral solid dosage formulation. The active ingredient was well characterised and the originator product’s specifications were publicly available, but the excipient blend used in the originator was proprietary and could not be replicated directly. The uncertainty was scientific. The team needed to identify a candidate excipient combination that would deliver a dissolution profile equivalent to the originator across the full physiological pH range required for bioequivalence, but the interaction between the active ingredient and candidate excipient matrices at varying pH conditions was not predictable from the existing literature. The behaviour of the active was understood in isolation, but whether and how a reformulated matrix could be made to perform equivalently under real gastrointestinal conditions was not.
Genuine uncertainty is half the qualifying test. The other half is that the work must be approached systematically. Without that structure, there is no way to distinguish genuine research and development from trial and error.
In practice, systematic means the technical work follows a structure that a competent practitioner would recognise. A hypothesis about what might work and why. A method for testing it. Observations recorded as the work progresses. Conclusions drawn from the results, whether the hypothesis held or did not. The work does not need to be conducted in a laboratory or follow formal scientific methodology, but it does need to be approached deliberately, with enough structure to show that the uncertainty was being investigated rather than stumbled through.
Both DSTI and SARS look for evidence of systematic work in different ways. The DSTI adjudication committee assesses whether the technical approach was structured enough to constitute research and development under the legislation. SARS audits whether the expenditure claimed maps to that structured activity. Companies that approach genuinely uncertain work improvisationally weaken the claim, because the absence of structure makes the uncertainty itself harder to demonstrate. The systematic requirement is not a paperwork exercise. It is the evidence that the uncertainty was real.
Section 11D’s uncertainty test is more accessible than most businesses assume. Engineering and technical teams across South Africa work through genuine scientific and technological uncertainty every week, and a meaningful proportion of that work likely qualifies for the incentive.
However, the qualifying question is also more demanding than it first appears. Identifying genuine uncertainty, distinguishing it from routine technical difficulty, and documenting it in a way that survives DSTI review and SARS audit requires technical literacy alongside tax expertise. The ability to get that combination right is the difference between a claim that holds and one that does not.
If you are considering a Section 11D claim, we help companies work out whether their R&D meets the uncertainty test and build claims that survive DSTI review and SARS audit. Get in contact HERE.
ABOUT THE AUTHOR
Michelle Giuricich is the Lead Technical Consultant at Catalyst Solutions. She works across industries, overseeing the technical assessment on every R&D project the firm takes on. Her background as a chemical engineer at Sasol shapes how she reads complex technical work and what she looks for when assessing whether a project meets the uncertainty test.
© 2026 Catalyst Solutions – Alle Rechte vorbehalten | Allgemeine Geschäftsbedingungen
