R&D Project Register
One list of the projects and business components behind your claim. The register holds each business component in a form that is ready for Form 6765 Section G, and everything else in the system attaches to it.
The backbone of the system
Every other tool in self-managed documentation needs something to attach to. A survey answer relates to a project. A file belongs to a project. A cost is allocated to a project. The project register is where those projects are defined, once, so that everything else lines up. A claim built on a clear register is easy to follow. A claim built on loosely named projects, with different names in different tools, is hard to follow and hard to defend.
What it does
The register holds each business component in a form that is ready for Form 6765 Section G. Everything else in the system, from evidence to costs, attaches to it. For each component it records what the project is, what it aimed to achieve and who is involved, and it keeps the links to the evidence and costs that belong to it.
How it works
- 1
Add a component
Describe the project and its aim, in plain language, and name who is responsible.
- 2
Attach records
Evidence and costs link to it, so the project's file builds up over time.
- 3
Keep it current
Descriptions are updated as direction changes, with the history kept.
- 4
Export
The detail is ready for the form, and for the claim pack.
What is recorded for each project
Fields are examples. The register is confirmed by Swanson Reed.
| Field | Why it matters |
|---|---|
| Name | Lets everyone refer to the same thing |
| Aim | States the new or improved product, process or software sought |
| Uncertainty | Explains what was not known at the start |
| People | Links staff and time to the project |
| Period | Shows when work was done |
| Linked records | Evidence, costs and survey answers attached to it |
What you get
- One source for Section G detail.
- Evidence and costs linked to each project.
- A consistent name and description used by everyone.
- A history of how each project's description changed.
Choosing the right level of detail
The hardest decision is how big a project should be. Too broad, and a single entry covers a mass of unrelated work, which is hard to describe and support. Too narrow, and the register fills with dozens of tiny items that nobody can maintain. A good rule is to define a project as something a team member could describe in a paragraph: one product, one process improvement, one technique. If you cannot describe it in a paragraph, it is probably too broad or too vague. Your reviewer can help decide.
A worked example (illustrative)
This scenario is invented. A company starts the year with a register of five projects. In April, a team begins a new approach to a data pipeline that does not fit any of them, so the coordinator adds a sixth with a short description. In July, two of the original projects are merged because the work converged, and the register records the merge with a reason. When the reviewer opens the register at year end, she sees six components, each with a description, a team and links. The history shows how the list changed, which explains why some evidence is filed under projects that no longer exist as separate items.
Limits
The register is only as good as its descriptions. If people write vague or promotional text, the register will be vague. It does not decide whether a project qualifies, and it cannot make a weak description strong. A licensed CPA or enrolled agent reviews the claim, and forms are filed through an authorized IRS e-file provider or tax software. Integrations, review tiers and partner pricing are proposals until confirmed by Swanson Reed.
Integrations, review tiers and partner pricing are proposals until confirmed by Swanson Reed.
A good project description includes
- What is being developed or improved, in a sentence a stranger could follow.
- What was not known at the start: the technical uncertainty.
- Why the answer was not obvious to someone skilled in the field.
- Who is working on it and in what roles.
- When the work started and how it is expected to proceed.
Splitting and merging projects
Projects change. Two efforts may turn out to be one, or one may split into separate lines of work. The register supports both, and the important thing is to record the change and the reason. A reviewer can then understand why evidence is filed under a name that no longer appears, and an examiner can see that the structure followed the work rather than being invented afterwards. Avoid renaming projects quietly. A clear history is a form of evidence.
Linking to the rest of your systems
Many teams already have names for their work in their project trackers. Using the same names in the register makes linking simple. Where names differ, record the mapping once, so that records from the tracker land in the right place. This small piece of housekeeping prevents a surprising amount of confusion later, when evidence from different tools needs to be put together.
Reviewing the register during the year
A register is not a one-time exercise. Look at it quarterly, with the technical leads. Is each project still accurately described? Has anything been added or finished? Are there projects with no evidence attached? A short review meeting, with the register on screen, usually takes less than an hour and prevents a lot of year-end confusion. Record what was decided, even if nothing changed, so that the history shows the register was kept under review.
Register questions
Who should add projects?
Usually a coordinator, with input from technical leads. Roles are agreed in writing.
Can a project be renamed?
Yes, with the change recorded, so the history stays clear.
How many projects is too many?
When nobody can keep up with them. Start with those most likely to matter and add as needed.
Is it the same as a project tracker?
No. It is a list of research projects for the claim. It can link to the records in your tracker.
Keep exploring
R&D Survey Scheduler
Decide how often your people are asked about their R&D work, so evidence is collected regularly.
Learn moreR&D Evidence Vault
A safe place for the proof behind each R&D project: time-stamped notes, files and approvals.
Learn moreCost and Time Sync
Bring costs in from the ERP or accounting system and match them to projects using time data.
Learn moreClaim Pack Export
When the year is done, hand the reviewer a pack they can work from: draft forms and a supporting binder.
Learn morePlease note: Estimates and drafts are prepared by software for review by a licensed CPA or enrolled agent. This is not tax advice.
Find out what AI would cost you
Book a free call. We will map three opportunities and give you a rough idea of cost and payback.