Document Version Control Kit
Make the approved version easy to find and old versions hard to confuse.
For: Teams sharing changing decks, models, contracts and reports
- Give each document a stable ID and a revision number so its identity survives filename changes.
- Distinguish Draft, Under review, Approved and Released instead of calling every copy final.
- Check approval before replacing the externally shared document with a newer revision.
- Keep the register, released copy and superseded archive aligned so readers receive the intended version.
01 / Practical guide
Give the document a stable identity
Assign stable document identities before numbering revisions.
Document version control is a way to distinguish the document itself from each revision. A stable document ID stays the same while the revision changes. This helps reviewers discuss DOC-02 revision 04 without guessing which “new model” someone attached to an email.
- Assign document IDs
- Number revisions consistently
- Record release approval
- Replace the shared copy deliberately
- Archive superseded revisions
Give the document a stable identity
Bring the essential details together before work begins.
Read the practical details
Start with a small register of the documents that people actively share. Record the title, owner, revision, review state, approval and effective date. Do not attempt to catalogue every temporary note if it adds no value. The purpose is to identify the version people should rely on.
Choose one owner who coordinates changes. Other people can contribute, but one person should decide when the candidate revision is ready for review. Where approval requires another role, record that role separately. An owner’s upload is not evidence of approval.
Keep the current approved version in a predictable location. Store drafts and superseded revisions in clearly separate areas. Make the active version obvious to someone arriving for the first time, without expecting them to interpret a chain of increasingly emphatic filenames.
02 / Practical guide
Use names that explain the file
Use filenames that communicate the document and revision without ambiguity.
Use a consistent naming pattern such as Company_Document_YYYY-MM_Revision. For a reporting period, include the period covered rather than only the upload date. A document about Q3 can be prepared in October; those dates answer different questions.
Use names that explain the file
Follow the work in a clear sequence.
Read the practical details
Avoid names such as final_final_new2. They describe the author’s intention without identifying approval, period or revision. “Harbour_FinancialModel_2026-10_r04” is more useful, but the register should still tell readers whether r04 is approved or under review.
Choose a revision scheme the team can maintain. Sequential revisions work for many small teams. More complex systems may distinguish major and minor revisions, but that distinction must have a clear meaning. Do not introduce a scheme that nobody updates consistently.
For signed documents, preserve the executed record. Do not overwrite it with an unsigned working copy. Any amendment or replacement should be handled through the authorised process and recorded distinctly. A naming convention helps identification; it does not determine legal validity.
Copy and customise this template
Ready-to-use templateDocument ID: [stable ID] Title: [document title] Candidate revision: [revision] Owner: [role] Change summary: [specific changes] Reviewer: [role] Approval decision: [approved / changes required] Release date: [date] Superseded revision: [revision] Recipient notification required: [yes/no and reason]
03 / Practical guide
Review a change before releasing it
Record the reviewer’s approval before releasing a changed file.
A controlled update has four steps: prepare the change, review the relevant content, approve the revision and release it to the intended audience. Keep the earlier approved version active while a replacement is under review unless an authorised decision says otherwise.
Review a change before releasing it
Use a realistic example to show what changes.
Read the practical details
In the fictional register, the financial model revision 04 is Under review. It should not silently replace revision 03 merely because the filename looks newer. The customer summary revision 02 is Released, so the owner should confirm recipients can find it and that the earlier version is labelled superseded.
Record a short change summary. “Updated forecast assumptions and corrected the customer segment totals” is more useful than “various changes.” Reviewers can then focus on affected conclusions while still checking any dependencies.
When an error is discovered after release, assess who received the version and what decision it may affect. Correct the file, identify the superseded revision and notify relevant recipients through the agreed process. Replacing a hosted file does not update copies that recipients already downloaded.
| Document ID | Title | Revision | Owner | Status | Approved by | Effective date | Supersedes |
|---|---|---|---|---|---|---|---|
| DOC-01 | Investor deck | 03 | Fundraising lead | Approved | CEO | 2026-10-13 | Revision 02 |
| DOC-02 | Financial model | 04 | Finance lead | Under review | Pending | Pending | Revision 03 |
| DOC-03 | Customer summary | 02 | Commercial lead | Released | Commercial lead | 2026-10-12 | Revision 01 |
Choose the next action
| Situation | Action | Outcome |
|---|---|---|
| Model revision 04 under review | Keep the approved release until review finishes | An unapproved model is not distributed |
| Deck revision 03 approved | Release it and archive revision 02 | Readers can identify the current deck |
| Old attachment still circulating | Notify recipients which revision replaces it | Independent copies are addressed explicitly |
04 / Practical guide
Keep the register and the shared copy aligned
Update the register and shared copy together while retaining superseded records.
Use the worksheet to connect document ID, current revision, approval and location reference. The location field can use an internal reference rather than exposing a private address in a widely shared register. Limit access to draft notes and approval comments where needed.
Keep the register and the shared copy aligned
Verify the exact conditions that matter before closing the work.
Read the practical details
Before a release, check that the filename, document cover or header, register and actual shared file all agree. A register listing revision 04 while the folder contains revision 03 creates avoidable confusion. Test the recipient view if the publishing process changes links or permissions.
Archive superseded files according to the organisation’s retention process. Do not delete records simply to make a folder look tidy when preservation is required. Mark them as superseded and separate them from active material.
The process is complete when a recipient can identify the current approved version, an owner can explain what changed, and the team can trace the earlier release. Start with the five documents most likely to affect a decision; expand the register only where control is useful.
Your completion check
Operational completion verification items
These are the only interactive checkboxes. Selections stay in this page session.
Use the worksheet
Interactive Worksheet Record
Fill one record per task. Work stays in this page session; export before closing.
Do not enter passwords, raw account details or confidential document contents.
05 / Practical guide
Common version-control questions
Start with the current deck and model and identify their release owners.
Does a newer date mean a file is approved?
No. A date can indicate preparation or period coverage. Approval should be recorded separately.
Should I rename every file in an existing archive?
Not necessarily. Prioritise active documents and preserve historical references. A migration plan may be needed where names are embedded in records or integrations.
Can I keep drafts in the same shared folder?
You can, but it increases confusion unless scope and labels are clear. A separate preparation area is often easier to manage.
What if two people edit the file at once?
Use the collaboration or check-out process available in your approved system. The register does not resolve merge conflicts automatically. Agree who integrates the changes and releases the result.
What should I do first?
Assign IDs to your current deck, model and key report. Record their approved revisions, move obvious superseded copies out of the active view, and name the next review owner.
Common version-control questions
Show who owns each part of the work.
Related guides & articles
Investor Document Management: A Practical Lifecycle Guide for Fundraising Teams
Framework for gathering, organizing, and versioning documents across investment cycles.
Startup Fundraising Data Room Index: Folder Structure and Disclosure Guide
Maintaining up-to-date financial models, cap tables, and pitch decks without version confusion.
How to Set Up a VDR: Launch Checklist
Step-by-step preparation for organizing folders, naming files, and establishing review processes.