Templates
Document Naming Convention Template
A naming convention should encode only what has to be readable outside the system itself: a document identifier, a short subject and a revision. Everything else belongs in metadata, because elements buried in a filename cannot be filtered, validated or corrected in bulk.
Document Naming Convention Template
Naming conventions are the first thing organisations reach for and the least durable control they have. They are worth having anyway, provided they are scoped to what a filename can actually do.
What a filename is for
One thing: identifying a document where its metadata is not available. An email attachment, a printed copy, a file on someone's desktop, an export handed to an auditor.
Inside a system that holds document type, status, owner, effective date and retention class as fields, the filename carries almost no load. Which means the convention should be short, because every element it encodes is an element that cannot be filtered, validated or corrected in bulk.
The recommended pattern
[identifier]-[short-subject]-[revision].[ext]
Three elements, in that order. Examples:
QP-014-document-control-rev-C.pdf
MSA-2026-0412-northwind-supplies-rev-B.pdf
2026-03-18-board-minutes.pdf
The third example replaces the identifier with an ISO 8601 date, which is correct for the small class of documents whose identity genuinely is their date: minutes, statements, periodic reports.
Rules that make it work
Lower case throughout. Case-sensitivity differs between operating systems, and mixed case produces duplicates that look identical in a listing.
Hyphens between words, no spaces. Spaces are encoded in URLs, break in some scripts, and get handled inconsistently by tooling.
ISO 8601 dates only — 2026-03-18. Any other format sorts wrongly, and 03/18/26 and
18/03/26 are indistinguishable to a reader who does not know which convention was used.
No punctuation beyond hyphens and one full stop. Ampersands, brackets, commas and slashes all cause problems somewhere in the chain.
Keep it under about eighty characters. Long names combined with deep paths hit path length limits during migrations, and the failure appears as an unexplained subset of documents that would not copy.
What does not belong in a filename
Author name, because it changes and becomes wrong. Status, because status changes and the filename will not. Department, because reorganisations happen. Client or project name where an identifier already covers it. And anything a metadata field records, because the field can be searched, filtered and corrected while the filename cannot.
The general test: if the value can change while the document stays the same document, it is metadata.
Why conventions decay, and the fix
A convention published as a rule is followed carefully for a few weeks, then unevenly, then not at all. Nothing enforces it, nobody audits it, and the exceptions are invisible until somebody tries to sort a folder.
The only durable fix is generation. Derive the filename from metadata at the point the document is created, so the convention is a consequence of the fields rather than an instruction to a person. Where that is not possible — documents arriving from outside, for instance — rename on intake as part of capture, rather than asking the sender to comply.
Handling documents that arrive named badly
Most incoming documents will not match your convention and there is no point requiring senders to adopt it.
Rename at intake and record the original filename as a metadata field. That second part matters more than it sounds: the sender will refer to the document by the name they gave it, and a searchable record of the original name is how you find it when they do.
Retrofitting an existing archive
Do not rename in bulk. Existing links, references and citations point at current names, and a mass rename breaks all of them at once for a cosmetic gain.
Instead, apply the convention to new documents, generate it where you can, and let the old names stand. Metadata makes the old documents findable regardless of what they are called, which is the point of putting the load on fields rather than filenames.
The exception is a migration, where documents are moving anyway and links are being remapped as part of the work. Renaming during extraction costs nothing extra and the redirect mapping you already need covers the old references.
Publishing the rule
State the pattern, give two correct examples and two incorrect ones with the reason each is wrong, and name the person to ask about edge cases. Conventions published as abstract rules get interpreted; conventions published with examples get copied, which is what you want.
Keep it to one page. A naming standard that runs to several pages is describing decisions that should have been fields, and its length is itself evidence that too much has been asked of the filename.
In summary
The sequence, in short
Step 1: Decide what the filename is for
Identification outside the system — in an email attachment, on a print, in a downloads folder. Anything needed only inside the system belongs in a field instead.
Step 2: Choose three elements at most
Document identifier, short subject, revision. Each element added beyond that lengthens paths and increases the number of ways a name can be wrong.
Step 3: Fix the separator and the date format
Hyphens between elements, underscores within them, and ISO 8601 dates so names sort chronologically. Mixed conventions defeat sorting entirely.
Step 4: Generate the name rather than typing it
Derive it from metadata at creation. A convention that depends on people typing correctly degrades from the day it is published.
Step 5: Publish the rule with examples
Two correct examples and two incorrect ones with the reason. Rules stated abstractly are interpreted inconsistently.
FAQ
Questions this raises
Should the date go in the filename?
Only where the document is identified by its date — minutes, reports, statements. Use ISO 8601 so names sort chronologically. Never use it as a version substitute, because two documents dated the same day give no ordering.
Should we include the author's name?
No. Authorship is metadata, it changes when documents are handed over, and it is the element that most often becomes inaccurate. Filenames should describe the document, not who was working on it.
What about version numbers in filenames?
Include a revision identifier where documents leave the system, because a recipient cannot see your version history. Inside a system with real version control, the filename revision is redundant and will eventually contradict the record.
About the author
Written and reviewed by the DocumentMS product and compliance team.
Last reviewed: 2 September 2026