Naming and Versioning Shared Files

Report_final_v2_FINAL_JS_edits_USE_THIS_ONE.docx is a joke because it is universal, and it is universal because file naming is a genuinely hard coordination problem that every organisation solves badly by default. A naming convention is not tidiness for its own sake: it determines whether you can find a document in two years, whether two people can tell which version is current, and whether an automated process can do anything useful with a folder.

What a good name has to do

Four jobs, in order of importance:

1. Identify the document unambiguously, so two files are never confused.
2. Sort usefully in an alphabetical file listing, which is how every file manager displays a folder.
3. Be readable out of context — in an email attachment, a download folder, a search result.
4. Be typeable and safe across operating systems, systems and time.

A name that satisfies these is usually shorter and duller than what people write instinctively.

The convention

A pattern that works for most business documents:

YYYY-MM-DD_Project-or-Client_DocumentType_vNN.ext
2026-08-06_Acme_Proposal_v03.pdf
2026-04-01_Expenses-Policy_v3-2.pdf

The reasoning behind each part:

Date first, ISO format. YYYY-MM-DD is the only date format that sorts chronologically as text, is unambiguous internationally (unlike 06-08-2026, which is two different days depending on the reader), and is an actual standard (ISO 8601). This one decision does more work than everything else combined.

Which date? Whichever is the one you will look for — usually the document's own date rather than the day you saved it. For correspondence, the date sent. For a report, the report date. Be consistent within a folder.

A stable identifier next. Client name, project code, matter number. Use the same string everywhere: Acme or ACM-2026-04, never both.

Document type, from a short controlled list: Invoice, Proposal, Contract, Report, Minutes. A list of ten types that everyone uses beats infinite descriptive freedom.

Version last, zero-padded: v03, not v3. Padding matters because v10 sorts before v2 otherwise — the same reason page numbers and Bates numbers are padded (Bates numbering explained).

Separators: underscores between fields, hyphens within them. It makes the fields machine-parseable and keeps the name readable.

What to avoid

• Spaces. They survive most modern systems and still break command lines, URLs, and older tooling. Hyphens cost nothing.
• Special characters: / \ : * ? " < > | are illegal on some platforms; #, %, & cause problems in URLs; accented characters and emoji cause encoding problems in sync and archive tools.
• Very long names. Windows still has path length limits that bite in deeply nested sync folders, and the failures are obscure.
• "final". Nothing is final. final, FINAL, final2, truly-final is the failure this whole convention exists to prevent.
• Initials of the last editor. That is what version history is for, and it produces one file per person.
• Redundant path information. A file inside /Clients/Acme/2026/ does not need Acme_2026 in its name — though a copy of it in someone's downloads folder does, which is an argument for a little redundancy in anything that gets emailed.
• Sensitive information in the filename. Smith_Redundancy_Consultation.pdf in a subject line discloses the content to everyone the email is forwarded to. See sending documents securely by email.

Versioning: numbers versus history

Two models, and they are not alternatives so much as different jobs.

System version history — the cloud storage or document management system keeps every save, and there is only ever one file. Google Drive, SharePoint, Dropbox and git all do this. It is better in almost every respect: no duplicates, no ambiguity about which is current, full history, and restore on demand.

Filename versions — v01, v02 in the name. Necessary when documents leave the system: sent to a client, submitted to a portal, archived, or shared with people who have no access to your history.

The workable combination: system history for working documents, filename versions for issued ones. The draft lives as one file with history; each version that is actually sent gets a numbered, dated copy in a sent/ or issued/ folder, never modified afterwards. That folder is your record of what other people have.

Where a document is formally controlled — policies, procedures, specifications — the version number should also be inside the document, on every page, along with an effective date. Filenames get lost when a document is printed or forwarded. See employee handbooks and policy documents and document versioning best practices.

Major and minor versions

For documents that go through formal cycles, a two-part number carries information:

• v0.x — draft, not approved.
• v1.0 — first approved version.
• v1.1 — minor change: typos, clarifications, no change to meaning.
• v2.0 — material change requiring re-approval and, for policies, re-acknowledgement.

The distinction between minor and major is the useful part: it tells a reader whether they need to re-read. Establish who decides which a change is, or every change becomes a minor one.

Folders, briefly

Naming interacts with structure, and the same principles apply:

• Shallow beats deep. Three levels is usually enough; five means people stop filing and start dumping.
• Partition by the thing that expires — usually year — at the level where you will eventually delete. It makes retention enforceable rather than theoretical: document retention policies.
• One place per document. Copies in two folders diverge. Link instead.
• Consistent folder names, same convention as files.

More: how to organise digital documents and building a personal document archive.

Making a convention stick

Conventions fail through inconsistency, not through being wrong. What helps:

• Write it down, one page, with three examples. Undocumented conventions survive exactly as long as the person who invented them.
• Keep it short. A convention with seven fields and a lookup table will not be followed.
• Automate what you can. A template, a naming script, a save-as macro, or a scanner profile that names files at capture. Anything that makes the correct name the default one.
• Rename on receipt, not eventually. Files that arrive as scan0042.pdf and stay that way are unfindable within a month.
• Do not retrospectively rename everything. Start from today; fix old files only when you touch them. A migration project for historical files is rarely worth it and often abandoned halfway, leaving two conventions.
• Enforce it where it matters most — shared and client-facing files — and be relaxed about personal working folders.

Why it pays off

The costs of poor naming are diffuse, which is why nobody fixes it: a few minutes lost here, a wrong version sent there, an hour spent working out which of four files the client actually received. Aggregated across a team over a year it is substantial, and it is entirely avoidable by a convention that takes an afternoon to agree.

The acute cases are worse: sending a client the wrong version of a contract, an auditor unable to establish which policy was in force, a legal hold that cannot be satisfied because nobody can identify the relevant documents. All three are naming failures wearing other clothes.

Summary

Name files YYYY-MM-DD_Identifier_Type_vNN.ext: ISO dates sort correctly and are unambiguous, zero-padded versions sort correctly, and underscores between fields keep names parseable. Use the system's version history for working documents and filename versions only for what leaves the building, kept in a sent/ folder nobody edits. Put the version inside controlled documents as well as in the name, avoid spaces, special characters and the word "final", and write the convention down on one page so it outlives whoever proposed it.