Module 5: Documentation basics

After this module you will be able to explain what records made at the time mean and why reviewers weigh them so heavily, recognise the records your team already creates and the small additions that make them usable, build the three links a reviewer follows through a claim, and run a documentation routine that survives a busy year.

What this module covers

What records made at the time mean, and why they outweigh later write-ups.
The records most teams already produce, and what to add to each.
The three links: records to projects, projects to people, people to costs.
A routine a busy team can keep, and how long each country expects records to be kept.

Why the time matters

Every definition in module 2 is applied at the start of the work: was there a scientific or technological uncertainty before anyone knew the answer? The only evidence that can show that directly is a record made at the time. A ticket from March saying the gripper cannot yet hold soft items at speed, a test log from April showing three designs failing, a note from May on why the fourth was tried: together these show what was unknown and when. A narrative written the following January is the company's account of those events. It is useful, but it is testimony, and reviewers weigh evidence by when it was created.

The lesson is not more paperwork, but making sure the work the team already records carries a date, an author and a link to the project. The guide on what reviewers look for in records made at the time goes through the reviewer's side of this.

Records you already make

Most technical teams already generate the evidence a claim needs; they just do not label it.

Record	What it proves	Where it usually lives	What to add
Tickets and issues	What was worked on, by whom, when, and what was blocked	Issue tracker	The project identifier, and a label for work on the uncertainty itself
Commits and pull requests	The sequence of attempts and what changed between them	Version control	The project identifier and a sentence on why
Lab notebooks and test logs	The hypothesis, the conditions, the results and the conclusion	Notebooks, spreadsheets, test systems	Date, author and project identifier on every entry; failures recorded as carefully as successes
Design documents and drawings	The alternatives considered and why one was chosen	Document store, CAD system	Version history kept, rejected options left in
Meeting notes and progress reports	Decisions, changes of direction, approaches abandoned	Shared documents, email	One line per project per meeting, filed under the identifier
Contracts and supplier emails	What outside help was commissioned, before the work, and what it did	Procurement, email	Filed under the project, with a description of the work
Time records	Who spent how much time on which project	Timesheets or allocation records	Split by project, not by department; completed as the work happens
Purchase records	Materials and services bought for the project	Purchasing, ledger	The project identifier as a code on the order and the invoice

The three links

A reviewer follows three links through a claim, and a gap in any one of them is where claims fail.

Records to projects. The connecting document is a project register: one line per project with an identifier, a name, the start date, a one paragraph statement of the uncertainty, the technical lead and the status. Every ticket, log entry, drawing and purchase order carries the identifier; without it the records exist but cannot be gathered for one project.

Projects to people. For each project, who worked on it, in what role, and what expertise they brought. Several tax authorities ask who judged that the uncertainty existed and what relevant experience they had, so name the competent professional for each project and make sure the names match the narrative.

People to costs. Time records that split each person's time by project, reconciled to payroll, are the link between the people and the staff costs in module 3. For materials and contractors the link is the project code on the purchase. If the time records and the narrative disagree, the reviewer will notice, so finance checks them against each other before filing.

A routine a busy team can keep

A routine fails when it asks engineers to write for the tax authority. This one asks for what they would write anyway, at five points, each with an owner.

At project start (technical lead): open the project in the register and write the uncertainty statement: what the goal is, what the field already knows, what has been tried or searched, and why the outcome cannot be predicted. Name who made that judgement. This is the most valuable record in the claim, because it is dated before the work.
As work happens (everyone on the project): put the project identifier on tickets, commits, test entries and purchase requests. Record failures.
Monthly (technical lead): a short note per active project: what was tried, what happened, what is next, who was involved.
Quarterly (finance): reconcile time records to the project register and payroll, and purchase codes to the ledger. Chase missing timesheets now, not in claim season.
At project end or year end (technical lead): a close out note: the outcome, including failure, the date the uncertainty was resolved or the work stopped, and what routine work followed that is outside the claim.

Teams that keep this routine find that the narrative in module 4 writes itself from the register, and that a reviewer's question is answered by a filter on the project identifier rather than a reconstruction.

Illustrative example

Illustrative example. Harbour Robotics Ltd, a hypothetical company, opens project HR-03, the soft item gripper, in its register in the first week of the work. The engineering lead writes the uncertainty statement: no published design or available part picks irregular soft items at line speed without damage, three suppliers have confirmed they have nothing, and the team cannot predict which of four approaches will work. Every ticket and commit then carries HR-03, the test log records 40 trials across the four designs with dates and results, and the monthly note records why two designs were abandoned. Time records show two engineers at half their time on HR-03, the 60,000 of staff costs in module 3, and the purchase orders for prototype components carry the HR-03 code, including the 2,000 of parts that went into a robot later sold. At year end finance filters everything by HR-03 and reconciles the time to payroll. When a reviewer later asks who decided the problem was uncertain and why, the answer is the dated statement from week one and the engineering lead's experience, not a recollection.

Across the seven countries

Country	What the tax authority expects you to keep	How long
United States	Keep records that link each business component to the four-part test and to the wages, supplies and contract research costs you claim.	The general period for assessment is three years after the return is filed
United Kingdom	Keep project records that show the advance sought, the uncertainties and how the work resolved them	Six years from the end of the accounting period
Ireland	Keep records made at the time that show the scientific or technological uncertainty, the work carried out to resolve it and the expenditure incurred	6 years from the end of the accounting period, or from the date the return is delivered if later
Canada	Keep records made as the work happens, such as hypotheses, test results and time records, that show the systematic investigation	Six years from the end of the last tax year to which they relate
Australia	Keep records that show the hypothesis, the experiments, the results and the conclusions for each registered activity, and that link expenditure to those activities	5 years from the date the return was lodged or the record was prepared, whichever is later
New Zealand	Keep records that show each core activity, the uncertainty it addresses and the systematic approach taken, and link expenditure to it	Business records must be retained for 7 years
Singapore	Keep documents that show each project's objective, its novelty or technical risk, the work done and the qualifying expenditure	5 years from the relevant Year of Assessment

Where to go next

What reviewers look for in records made at the time: the reviewer's side.
Writing a technical narrative that survives review.
Documentation and compliance: all guides on records.
Technical Teams Program: for the engineers and scientists who keep these records.
R&D Tax Fundamentals: the program overview and modules 1 to 4.