How to Set Up R&D Documentation That Will Not Embarrass You Later

Nobody wakes up wanting to improve their research documentation. It is the organizational equivalent of flossing: obviously sensible, easy to skip, and the consequences arrive much later.

The consequences, in this case, are a weaker credit claim, a harder examination, and a lower price if you ever sell the credit. All three are avoidable at a cost of maybe two hours a month.

Here is a system that works for teams that have actual jobs.

Start with the only test that matters

A research credit claim turns on one question: was there genuine technical uncertainty, and did your team resolve it through systematic investigation?

Everything in your documentation should be aimed at answering that question for a reader who was not present. Not at proving you worked hard, not at showing the project was important, not at demonstrating technical sophistication. Just: what was unknown, what did you try, what happened.

If you keep that in view, the rest of this is mechanical.

Step one: define projects before the work, not after

This is the single highest-leverage change, and it is also the one people resist, because defining a project feels like overhead before anything has happened.

At the start of a development effort, write down three things. What are we trying to achieve technically? What do we not know? Why is the answer not obvious from what we already have?

Three or four sentences is enough. It can live in your existing project tracker, your quality system, or a shared document. What matters is that it exists before the work and is dated.

This one habit converts a reconstructed claim into a contemporaneous one, and a reviewer can tell the difference immediately.

Step two: capture time in a way people will actually sustain

The ideal is granular time tracking against development projects. The reality is that most engineering teams will not maintain that for long, and a system people abandon is worse than a simpler one they keep.

What works in practice is a monthly allocation at team level, made by the person who actually knows. A team lead who says "Maria spent roughly 60 percent of March on the membrane fouling investigation and the rest on production support" is producing a defensible allocation, provided it is made contemporaneously, by someone informed, and applied consistently.

What does not work is the same person making that estimate fourteen months later from memory, which is what happens by default.

The standard is not perfection. It is a reasonable, consistent method applied honestly at the time.

Step three: separate development from support, deliberately

Most technical teams do both, and the boundary is where claims get soft.

Production support, maintenance, routine testing and customer troubleshooting are not research, even when performed by researchers. Development work that resolves real uncertainty is, even when it happens on a production line.

Make this distinction explicit in how work is categorized. If your tracker has no way to distinguish them, add one. It costs nothing and it is the difference between a claim you can defend line by line and one you have to defend in aggregate.

Step four: write the closing note while it is fresh

When a development project ends, someone writes a short summary. Half a page.

What was the technical objective. What was uncertain at the start. What approaches were tried. Which ones failed, and what that taught you. How the uncertainty was eventually resolved, or why it was abandoned.

The failures are the most valuable part and the part people instinctively omit. Failed approaches are the clearest possible evidence that the outcome was genuinely uncertain. A project narrative that moves straight from objective to success reads like marketing; one that includes two dead ends reads like research, because it is.

Write it within a week or two of close. After a month, the detail is already gone.

Step five: make the costs tie to something real

Qualified expenditure has to connect to your actual accounting records. Payroll detail, ledger entries, vendor invoices.

The failure mode is a beautifully constructed summary schedule that nobody can trace back to the general ledger. When an examiner asks how a figure was derived and the answer is "it came from the model," the conversation goes badly from there.

Build the tie-out as you go, not at claim time.

Step six: give it an owner

A claim touches engineering, finance, operations and often quality. Shared ownership means no ownership.

Name someone. Give them standing to ask engineering leaders uncomfortable questions and authority to exclude costs that do not belong. Thirty minutes a month from an owner beats a frantic quarter from a committee.

What this is worth

Three things, in order of how much people care about them.

It makes the claim defensible, which matters when someone reviews it.

It makes the claim complete, because teams that track development activity consistently find qualifying work they were previously leaving out. In our experience this is the larger of the two financial effects.

And if you ever monetize the credit, it affects the price. A buyer is taking on risk, and substantiation quality is exactly what that risk is made of. Clean documentation is not just compliance, it is value.

The usual caveat

This describes general good practice. The specific requirements that apply to your claim depend on your decree, your facts and current administrative practice under Act 60-2019 §3030.01, and should be confirmed rather than assumed. Nothing here is advice about your situation.

If you only do one thing

Start defining development projects at the beginning with a written statement of the technical uncertainty.

Everything else in this article is easier once that habit exists, and almost nothing works properly without it.