Document version control best practices

Document version control best practice comes down to four habits. Name files by one convention, number versions so the number says how big the change was, print the version and date on the document itself, and freeze a copy of every version that was sent, approved or signed. Everything else, from folders to software, is a way of making those four habits easier to keep.

Start with a naming convention

A naming convention is a short agreed rule for what goes into a file name and in what order. Harvard Medical School’s data management guidance describes it as a framework for naming files in a way that describes what they contain and how they relate to other files, and makes a point that decides the order: computers sort file names character by character, so put the most important information first.

The US National Archives’ records blog adds the practical rules. Keep names unique and consistently structured. Use international date notation, YYYY-MM-DD or YYYYMMDD, so files sort in date order. Use leading zeros, 001 rather than 1, so item 10 does not sort before item 2. Use hyphens or underscores instead of spaces, avoid symbols, and keep names to about 25 to 35 characters.

Put together, a handbook file might be handbook_v3-1_20260812.pdf. Document name first because that is what people search for, then the version, then the date. Note the v3-1 rather than v3.1: the National Archives guidance avoids punctuation in names apart from the full stop before the file extension, so the version uses a hyphen in the file name even though the document itself says 3.1.

The table below this article lists twelve conventions in one place. Agree them once, write them at the top of the shared folder, and use them for every document type.

Number versions by what changed

A version number should tell a reader whether they need to reread. The University of Sussex’s records management guidance uses a major and minor scheme: amendments to a version are 1.1 and 1.2, and new major versions are 2.0 and 3.0, which it says offers a distinction between major and minor revisions. It also suggests a status in the file name such as draft, final or superseded. A common refinement is to number drafts 0.1, 0.2 and so on, so that 1.0 always means the first approved version.

The scheme works because of what each digit promises. A move from 3.0 to 3.1 says something small changed: a phone number, a typo, a clarified sentence. A move from 3.1 to 4.0 says the substance changed and people who relied on the old version need to read the new one. If you cannot decide which number to use, ask whether a reader who skipped the change could make a wrong decision. If yes, it is a major version.

Draft numbers below one matter more than they look. A document called version 1 while it is still being argued about gets forwarded, printed and relied on. A document called 0.4 does not.

Put the version on the document itself

Files get renamed. PDFs get attached to emails with new names, uploaded to portals, printed and pinned to walls. The only version label that survives all of that is the one printed on the page.

The employee handbook example on this site, for an invented four clinic health provider, puts Version 3.1, August 2026 on its cover and says inside who owns it and when it changes: People and Culture rewrites it every August and tells staff what changed. The information security policy example goes further: version 3.1, an effective date, a named owner and approver and a review date in a document control block at the front, then Version 3.1 again in the footer of all fifteen pages beside the page number.

That footer is the detail worth copying. Somebody holding page nine alone still knows which version it came from. The post on employee handbook sections argues for the cover as the place readers actually look for the version. The policy example shows why a long document benefits from the footer as a second place as well.

When to save a version

Not every save is a version. A version is a state of the document someone might need to return to or prove. Save one at decision points:

• Before sending anything outside the working group, including to a manager for review.
• When a version is approved, and give it the next whole number.
• Before a major rewrite, so the old structure is recoverable if the rewrite fails.
• When a version is sent to a client or counterparty, even as a draft, because they may reply to that exact text.
• When a document is signed, which freezes it permanently.

Between those points, working saves are just saves. Keeping every autosave as a named version produces a list nobody can use.

Final, sent and signed copies

The copy that was sent, approved or signed is evidence. Freeze it as a PDF, which the Sussex guidance recommends for final versions precisely to prevent later modification, name it with the status final or signed, and never edit it. If something needs to change, the change goes into the working document as a new version and the new version is sent again.

The same applies to the old versions. Mark them superseded rather than deleting them. When a customer, employee or auditor asks what a policy or agreement said on a particular date, the superseded copy is the answer. For signed PDFs, a document hash is one way to show a file has not changed since signing; the question page on document hashes explains how.

A statement of work example shows another version habit worth copying in contracts: it carries its own reference number, SOW-2026-041, and names the master agreement and date it sits under, so every later variation can cite exactly which document it changes.

Who can restore, and how

Restoring should never destroy work. The safest pattern is the one where restoring an old version creates a new version with the old content, rather than overwriting the newer ones, so a restore can itself be undone.

Decide who is allowed to approve a restore of an approved document. For a working draft, anyone on the team. For a published policy or a contract, the owner named on the document, because restoring an older approved version is effectively publishing a change.

Common mistakes

• final_v2_FINAL_really.docx. A status word without a version number stops working the second time something is final.
• Version only in the file name. It disappears the moment the file is renamed or printed.
• Emailing attachments to collaborate. Every attachment is a fork.
• Editing a signed PDF. It is no longer the signed document, whatever it is called.
• Deleting old versions. You lose the ability to show what applied on a date.
• Minor numbers for major changes. Readers skim a 3.2 that should have been a 4.0.

Build it

Version handling differs between the builders here, so it is worth knowing which is which. In presentations there is no autosave: a version exists when Save is pressed, and once when an AI assistant turn is applied. The version history drawer lists the 50 most recent versions; Preview opens one read only, and Restore clones the old version into a new one with the summary restored from version N, so nothing newer is lost. The guide to undoing changes and restoring an earlier version walks that flow, and undo holds 50 steps in the session.

The document builder has no version list to restore from, as the page on undo and save in documents explains, so for documents the convention in this post is the version control. Print the version and date on the cover or in the footer, export the PDF at each decision point and name it by the convention, and keep the frozen copies together.