Why governments pay for it
Nearly every developed economy pays businesses to do research and development, and the reason is not generosity. When a company solves a technical problem nobody had solved, most of the value leaks out: into the suppliers and customers who adopt the result, the competitors who learn from it, the engineers who carry it to their next employer. The business captures a slice; the economy captures the rest. Economists have measured that gap for decades, and the numbers are large. One widely cited study finds it hard to get the return to society below four dollars for every dollar a firm spends on R&D, with a central estimate above ten.
That is what a government is buying: productivity growth, which is the only durable way to raise wages without raising prices; firms that can compete and export rather than import; products that scale beyond the domestic market; and knowledge that stays in the country when the product does not. The work a software business sees as a commercial opportunity is, to the government, infrastructure. The two just value it on different terms, and the claim is where those terms meet.
Two kinds of business leave the money on the table
The first never claims, because nobody there thinks of what they do as "R&D": they build products, not papers. The second claims and has a hard time of it, because the claim reads like a release announcement and the program cannot find the research inside it. Both have the same cause. The business and the program are describing the same work in two different languages.
A business is organised around opportunity: revenue won, revenue kept, a market reached first, a visitor turned into a customer. Its vocabulary is features, releases, conversion and time to market, and that is exactly the right vocabulary for running a company. The incentive programs, by contrast, descend from a research tradition. The definition most countries share asks whether the work set out to resolve something that was not known, whether a competent professional could have predicted the result, whether it was done in a way that could be repeated and checked, and whether the field knows something now that it did not before. Opportunity does not appear in it anywhere.
Why the research goes unseen
Modern software practice makes this worse, not better. Agile delivery runs on small increments and fast feedback, and it treats "will it work?" as a question you answer by shipping and watching. Nothing in that loop asks anyone to write down, before starting, what specifically was not known and why nobody could know it. The team learns a great deal, but the learning is folded into the product and never named. By the time anyone thinks about a claim, usually months later, the hardest part of the year has been absorbed into "the platform" and the people who did it remember the answer as obvious.
Read the same release the way the program reads it, though, and most of its stages translate. The scoping that defined what had to be built contains the problem. The hard part in the middle is the unknown. The testing that most teams describe as hardening is, when it is done properly, the experiment: a repeatable, measured way of finding out whether the thing holds, at scale, under conditions nobody could simulate in advance, on data that is unique to your customers. What is left at launch is the knowledge.
Technical uncertainty, not human uncertainty
One boundary matters more in software than anywhere else. The programs pay for technical uncertainty, not for uncertainty about people. Whether users will click, which layout converts, what drives behaviour on the screen: that is market research and social science, and it is excluded on both sides of the Pacific, however rigorously the A/B test was run. Deciding where a button belongs is design, not research, and the US guidance says so in terms. Interfaces still hide genuine technical unknowns, though: whether a layout can re-render within a latency budget on low-end devices, whether a recommendation can be computed on the device without the data leaving it, whether an interface can adapt to a user in real time under a hard cost constraint. Those are engineering questions with unknowable answers, and they are claimable. The behaviour of the person in front of the screen never is.
How a software business takes advantage of it
Ask the questions at the start, not at claim time. When a piece of work looks hard, before the first sprint, have someone write short answers in plain language: what specifically is not known here, why could an experienced person in this field not simply work it out, how will we find out, and what will we know afterwards that we do not know now. Keep those answers somewhere other than the backlog. The unknown is only visible while it is still unknown; six months on, memory rewrites it as obvious, and with it goes the claim.
Treat your testing as the experiment it is. Most teams already run the rigorous part; they just file it under quality. Decide what you are measuring before you measure it, record the result whether it is good or bad, and keep the runs. Scale testing against real customer data under conditions you could not have simulated is exactly the repeatable, provable process the programs are looking for, and it is usually sitting in your pipeline unnamed.
Claim the slice, not the product. The eligible work is almost never the whole release. It is the part where known approaches ran out, together with the problem that defined it, the experiment that tested it and the knowledge that came out. A claim built on a precisely stated slice, with the surrounding engineering described as engineering, is both larger in substance and easier to defend than a claim that wraps the whole product.
Use two kinds of help, and keep them distinct. An R&D advisor knows the program: what the activities must look like, how they are described, what the records need to show and how the application runs. The technical questions, though, are technical, and the program expects them answered by someone with standing in the field, who can say what was known worldwide at the time and why the outcome could not have been predicted. Businesses that get both, and let each do its own job, find that the opportunity they were chasing commercially and the knowledge the government is paying for were the same work all along. It was only ever a matter of saying so in both languages.