File names: a scheme that holds

At the end of a contract negotiation, someone signs. Whether it is the right file, often no one checks, and that is the most expensive slip a negotiation knows. It starts harmlessly, with a file name.

This Wednesday, 17 June, a file landed in my inbox: 2026-06-10_supply-agreement_PP.docx. At first glance the name looks exemplary: an ISO-format date, the matter, my initials. Tidy.

Except it is not true. The date was a week old, and between 10 and 17 June several rounds of negotiation and revision had happened. My initials sat at the end of a file the other side had sent back to me. A version number, which would have shown the real state, was missing entirely. The name claimed an order that did not exist.

A file name is not a label, it is a small deed. It asserts who created something, what it is, and when it dates from. When that assertion is false, an organizational problem quickly turns into a liability problem, because in the end exactly one version may be signed, the final, agreed one, and everyone involved has to recognize it beyond doubt.

This is not a lawyer’s problem. Procurement, sales, project management, the executive floor, anyone who emails contract drafts back and forth knows the folder that no one can navigate after three weeks. And every minute spent searching, comparing, and asking is a minute the deal waiting to close does not have. Version chaos is not just annoying, it is expensive, and most expensive precisely when time is short.

Where it falls apart

A real project folder holds dozens of such files after a few months. A small excerpt already shows where it breaks down:

supply-agreement working version 4 (PP).docx
supply-agreement final.docx
supply-agreement final 2.docx
supply-agreement Version 6 FINAL.docx
supply-agreement Clean and Tracked (PP).docx
supply-agreement Indemnity Sections tracked (PP).docx
supply-agreement as of 13 Nov (PP).docx

Four patterns do the damage:

1. The date lies. Copying, forwarding, or renaming a file destroys the file system’s modified date. What remains is the date in the name, and everyone drags it along unchecked. So the newest version carries the oldest date.
2. “Final” is a lie. Once the word is in the name, there is no word left for whatever comes next. So “final 2” follows, then “Version 6 FINAL”, and finally “really final”. The name no longer says anything about the state.
3. The initials are orphaned. My initials at the end should mean “by me”. When the other side sends the file back with my initials still on it, the name claims the opposite of what happened. That is exactly what reached me this week.
4. The name has become a changelog. “Clean and Tracked”, “Indemnity Sections”, “tracked”, “as of 13 Nov”: all of that describes what was done. None of it belongs in the file name. What was changed belongs inside the file, more on that in a moment.

Behind it all sits the real problem: there is no single source of truth. Five people, five inboxes, fifteen copies, and no one can say for certain which one is current.

What the standards say

For the most maddening point, the date, there has been a solution for decades: ISO 8601. It prescribes the format YYYY-MM-DD, so 2026-06-20. It is unambiguous: 2026-06-20 allows only one reading, whereas a date like 06-07-2026 stays open, 6 July across much of Europe, June 7 in the US. And it sorts itself: files with an ISO date at the front line up in chronological order on their own.

The second idea comes from quality management. ISO 9001 requires, in clause 7.5, the “control of documented information”: every document uniquely identified, with a recognizable version status and controlled release. Translated into daily practice, that is exactly what the file list above fails at: a unique name, a visible version, and one clearly marked final copy.

A scheme that holds

Both standards point to the same pattern:

YYYY-MM-DD_matter_vNN_initials.docx

2026-06-08_supply-agreement_v01_PP.docx

Each block has one job:

The initials follow the person: when I edit, the file ends in PP; when the other side takes over, theirs go there, not PP. And “final” does not belong in the name, that is what the version is for.

Why a version number at all, when the date already orders things? Because the two do different jobs: the date says when it was saved, the version says which round it is. If two versions are created on one day, only the version tells them apart; if a number is missing from the run, you see at once that a round is missing. That number is exactly what my Wednesday file lacked.

“I can just sort by the date column”, some will think. You can, as long as you can trust that column, and you cannot. Copying or forwarding resets it, and as soon as several versions are created on one day, or an older file is edited later, the order no longer holds. Only a version number in the name sorts reliably, independent of any timestamp.

One rule makes the difference: the name carries the identity, not the content. Who, which matter, when, which version, nothing more. What changed substantively belongs in the document: as tracked changes and as a short summary at the top. The file name is the address, not the log.

And once assigned, a name stays as it is. Renaming a file that has already gone out cuts every later reference: emails point to it, the other side has filed it under that name, and so, often, has your own archive. A better name is then not a rename, it is a new version.

One negotiation, round by round

The same negotiation, once the usual way and once by the scheme (CP stands for the counterparty):

On the left, after round three no one knows which file applies. On the right, everyone reads the state off the name, and the column orders itself. Only the last line on the right gets signed.

Only one version gets signed

All this effort serves a single purpose: that the signed copy is exactly the one that was negotiated, and not an outdated or divergent copy. It works best not as an internal house rule but as an agreement: settle the naming scheme with the other side at the start of the negotiation, and you spare yourself almost everything that follows. Two minutes at the start, and both sides speak the same language. And before signing comes one last reconciliation, where both sides briefly confirm in writing which file name plus date is the final copy. That costs ten seconds and spares you the most expensive mix-up of the negotiating year.

Before signing, three checks:

1. One source. Is the final file in the agreed place, not attached somewhere in an email thread?
2. One name. Have both sides briefly confirmed, in writing, the file name and date of the final copy?
3. One version. Does the file carry the highest number in the run, with no gap before it?

The discipline is unspectacular, and that is precisely its value. It costs a few seconds per file and gives back the time that otherwise drains away in the folder while the business waits. A good file name tells the truth about itself. The rest is better left to nothing, least of all the document that, in the end, carries a signature.

By the way, the PP in the examples, including the messy folder above, stands for Peter Poleacov. Anyone who preaches order in file names has seen enough chaos to know why.

Häufige Fragen

Isn’t the date enough on its own?

No. The date says when a file was saved, the version says which round it is. Two versions from the same day, or a date corrupted by copying, can only be told apart by the version number.

What if the other side won’t play along?

On your own side the scheme helps at once. Best is to agree it at the start of the negotiation; if the other side does not follow, the last written reconciliation before signing catches the rest.

Do I have to rename files that have already gone out?

No. Renaming a file that has already been sent cuts every later reference. A better name is not a rename, it is the next version.

Reference: Poleacov, P. (2026). File names: a scheme that holds. INN.LAW. https://inn.law/en/perspectives/file-naming-convention/

---