Flowstate - R&D investment documentation

There’s a decent chance your engineering organisation qualified for six figures in R&D tax credits last year and claimed precisely zero. Not because the work didn’t qualify — it almost certainly did — but because nobody wrote down the right things in the right way while it was happening. Now it’s fourteen months later, the engineers who did the work have moved on or forgotten the details, and reconstructing the narrative is somewhere between painful and impossible.

R&D tax credits are genuinely free money. In the UK, qualifying SMEs can claim up to 27p for every pound spent on eligible R&D. Larger companies can claim under RDEC at around 15%. In the US, the federal R&D credit is roughly 6-8% of qualifying expenditure, with additional state credits on top. We’re talking real numbers — a 50-person engineering team with a qualifying spend of 2 million could be leaving 200-500K on the table annually.

And yet most engineering leaders treat R&D documentation as someone else’s problem.

The job

R&D tax relief exists to incentivise companies that advance science or technology by resolving genuine uncertainties. The critical word there is uncertainty. Your tax authority doesn’t care that you built a brilliant new feature. They care that you faced a technical problem where the answer wasn’t obvious, tried things that might not have worked, and advanced your capability in the process.

The job of R&D investment documentation is to capture that narrative as the work happens, not twelve months later when a consultant is trying to piece it together from Jira ticket descriptions and Slack messages.

This isn’t about creating bureaucracy. It’s about building a lightweight habit that captures five minutes of context per project, per month, and turns it into a material financial benefit.

Why it matters

The cost of getting this wrong is straightforward: you leave money on the table. But there’s a subtler cost too.

R&D documentation forces you to articulate what’s actually hard about your work. When you write down “we didn’t know if a real-time event processing pipeline could handle 50,000 events per second with sub-100ms latency at our current infrastructure cost,” you’ve done something valuable beyond the tax claim. You’ve named the technical challenge explicitly. That clarity helps with hiring (“we need someone who’s solved high-throughput event processing”), with prioritisation (“this is genuinely novel work, not just plumbing”), and with communicating engineering’s value to the business.

When you don’t document R&D, three things happen:

You miss the claim entirely. The most common outcome. Finance doesn’t know what qualifies, engineering doesn’t know finance needs documentation, and neither side raises it until it’s too late.
You scramble after the fact. A consultant arrives, interviews your engineers, and tries to reconstruct the narrative. This is expensive (consultants take 15-30% of the claim value), time-consuming (your engineers spend hours in interviews instead of building), and produces weaker claims because memories fade and details get lost.
You underclaim. Even when organisations do claim, they typically miss qualifying work because nobody identified it at the time. That internal tooling project that solved a novel deployment orchestration problem? Probably qualifies. But if nobody flagged it, it won’t appear in the claim.

What good looks like

Mature practice:

Every project has a brief R&D narrative captured at kickoff and updated monthly
Engineering managers can identify qualifying work because they understand the criteria
Documentation lives alongside the project, not in a separate system nobody checks
Claims are prepared annually with minimal additional effort — the documentation already exists
The organisation claims confidently, with detailed records that would survive an enquiry

Struggling practice:

R&D claims are prepared retrospectively by external consultants
Engineers can’t remember what they worked on or why it was uncertain
Claims are conservative because nobody’s confident in the documentation
The whole process feels like a tax compliance burden rather than a strategic activity
Some years they claim, some years they don’t bother

The gap between these two states is about 30 minutes per project per month. That’s it.

The approach

Step 1: Understand what qualifies

This is simpler than most people think. In the UK under HMRC’s guidelines (and equivalently under the IRS four-part test in the US), qualifying R&D work must:

Seek an advance in science or technology (not just new to your company — though in practice, most novel engineering work clears this bar)
Face technical uncertainty — the solution wasn’t readily deducible by a competent professional
Involve systematic investigation — you tried things, tested hypotheses, iterated

What this means in practice for a software engineering team:

Qualifies: Building a new real-time fraud detection system when you weren’t sure if your ML model could achieve the required false-positive rate. Designing a multi-tenant architecture that needed to handle regulatory data isolation requirements you hadn’t solved before. Creating a novel CI/CD pipeline that automated compliance checks nobody had automated at your scale.
Doesn’t qualify: Integrating a well-documented third-party API. Standard CRUD application development. Bug fixes (unless the bug revealed a deeper technical uncertainty). Work where the solution was known upfront and it was just a matter of implementation time.

The grey areas are vast, and that’s fine. A good R&D tax advisor will help you draw the line. Your job is to make sure the raw material — the documentation — exists.

Step 2: Capture the narrative at project kickoff

When a project starts, someone (usually the tech lead or engineering manager) should answer four questions in a few sentences:

What are we trying to achieve? (“Build a real-time risk scoring engine for lending decisions”)
What’s technically uncertain? (“We don’t know if we can score applications in under 200ms while incorporating 40+ data sources, some of which have variable latency”)
Why isn’t this straightforward? (“Existing solutions in the market handle 10-15 data sources. At 40+, the aggregation and scoring pipeline needs a fundamentally different architecture”)
What approaches are we considering? (“We’re evaluating event-driven vs. batch-then-cache architectures, and investigating whether pre-computation can reduce real-time latency”)

That’s it. Four questions, a paragraph each. Takes ten minutes. This is the foundation of your R&D claim for that project.

Step 3: Monthly updates

Once a month, the tech lead or EM adds a few lines to the project’s R&D narrative:

What did we try this month?
What worked, what didn’t?
What’s still uncertain?
Did we change approach, and why?

This should take five minutes. It doesn’t need to be polished — rough notes are fine. What matters is that the information is captured while it’s fresh.

Here’s the kicker: this is also just good engineering practice. You’re documenting technical decisions, trade-offs, and lessons learned. It serves double duty.

Step 4: Annual compilation

At financial year-end, you (or your R&D tax advisor) compile the project narratives into a claim. Because the documentation already exists, this is a collation exercise, not a research project. You’ll need to match the qualifying projects to qualifying expenditure (primarily salaries of the engineers who worked on them), but if your CapEx/OpEx tracking is clean, that data is already available.

Step 5: Build the habit

The hardest part isn’t the documentation itself — it’s remembering to do it. Build it into your existing rituals:

Add “R&D narrative” as a field in your project kickoff template
Include a monthly R&D documentation prompt in your engineering manager check-in
Review qualifying projects quarterly with finance

Within two quarters, this becomes muscle memory.

The conversations

With your CFO

Trust-building: “I’ve identified eight projects from this year that likely qualify for R&D tax relief. We’ve been documenting the technical uncertainties as we go, so we’ve got strong narratives ready for the claim. Shall I set up a call with our tax advisor to review?”

Trust-eroding: “Oh, we did loads of innovative stuff this year. Can you get a consultant to come and interview the team?”

With your engineering managers

Trust-building: “When you kick off a new project, I need you to capture four things: what we’re building, what’s technically uncertain, why it’s not straightforward, and what approaches we’re considering. Takes ten minutes. It’s worth real money to the company, and it’s good documentation practice anyway.”

Trust-eroding: “Finance needs you to fill in this R&D questionnaire for every project from the last twelve months.”

With your engineers

Trust-building: “That work you did on the event pipeline was genuinely novel — the approach to handling back-pressure at that scale isn’t well-documented anywhere. I’ve captured it in our R&D log because it qualifies for tax relief. Keep doing interesting shit.”

Trust-eroding: “Can you write up everything you did on the event pipeline project? I need it for some tax thing.”

With your R&D tax advisor

Trust-building: “Here are the project narratives for this year. Each one has the uncertainty, the approaches tried, and the resolution documented month by month. We’ve also got the expenditure mapped to qualifying projects through our work management data.”

Trust-eroding: “Here’s a list of project names. Can your team interview our engineers to figure out what qualifies?”

Common failure modes

Treating it as a finance problem. Finance can’t write R&D narratives. They don’t know what was technically uncertain about your event processing pipeline. This has to come from engineering, with finance handling the expenditure side. If you punt this to your finance team, the claims will be weak or non-existent.

Over-engineering the documentation. Some organisations create elaborate R&D tracking systems with custom forms and approval workflows. This is overkill. Four questions at kickoff, a few lines monthly. A shared doc or a field in your project management tool. Don’t let process kill the habit.

Confusing “hard” with “uncertain.” Building a complex CRUD application with 200 API endpoints is hard. It’s a lot of work. But it’s not uncertain — you know how to build CRUD apps, you just need time. R&D qualification requires genuine uncertainty about whether an approach would work. Teach your engineering managers the difference.

Claiming too aggressively. Some R&D consultants push organisations to claim everything borderline. This maximises the claim value (and the consultant’s fee) but increases enquiry risk. If HMRC or the IRS challenges your claim and finds it inflated, they’ll scrutinise every future claim. Be honest. Claim what genuinely qualifies, document it well, and sleep soundly.

Forgetting subcontractor and cloud costs. R&D qualifying expenditure isn’t just salaries. Subcontractors working on qualifying projects, cloud infrastructure costs for development and testing environments, and even some software licensing costs can qualify. Most organisations claim only salaries and miss 20-30% of eligible expenditure.

Getting started

If you’ve never claimed R&D tax relief, or if your claims have been consultant-driven retrospective exercises, here’s how to start:

This week: Talk to your CFO. Ask whether you’re claiming R&D tax relief. If not, ask why not. If yes, ask how the documentation is produced. In many organisations, this conversation alone will surface the problem.

This month: Identify your current projects that involve genuine technical uncertainty. Not everything will qualify — that’s fine. For the ones that do, write the four-question kickoff narrative. Even doing this retroactively for active projects captures value, because the engineers are still in context.

This quarter: Establish the monthly update habit. Add it to your engineering manager cadence. Review qualifying projects with finance. If you don’t have an R&D tax advisor, get one — a specialist advisor will typically pay for themselves many times over on the first claim.

This year: Compile your first well-documented claim. Compare it to previous claims (if any). I’d bet good money the documented claim is materially larger, better supported, and cheaper to prepare.

Downloads

The R&D Project Tracker template provides a structured format for the four-question kickoff narrative, monthly update logs, and annual compilation summaries. Use it per-project, hand it to your R&D tax advisor at year-end, and watch the claim practically write itself.

The CapEx/OpEx Discipline — CapEx tracking and R&D documentation use the same project structure and expenditure data. Get one right and the other follows naturally.
Investment Framing — R&D documentation proves what was technically innovative. Investment framing explains why it was strategically valuable. Together they make engineering’s contribution to the business undeniable.
Building Long-term Credibility — Consistent R&D documentation is one of those compound practices that builds trust with finance and demonstrates engineering’s contribution over time.