A file naming 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 in a negotiation. 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 order that the name suggested did not exist.

A file name gives details that others rely on. It states who created something, what it is, and when it dates from. When any of these details is wrong, a filing problem quickly turns into a liability problem. That is 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 board, anyone who emails contract drafts back and forth knows the folder where no one can find anything 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 annoying and expensive, most expensive precisely when time is short. It is also only the most visible form of a larger problem, everything in the operation of a contract that nobody owns: “Contract management decides your margin”.

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 is wrong. Saving a forwarded attachment as a new file destroys the file system’s modified date. What remains is the date in the name, and everyone keeps it without checking. So the newest version carries the oldest date.
2. “Final” is rarely the last version. 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 name the wrong person. 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 states 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.

The real problem behind it all is that there is no single binding source. Five people, five inboxes, 15 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, the ISO 8601 standard. It prescribes the format YYYY-MM-DD, so 2026-06-20. The date 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. Files with an ISO date at the front also line up in chronological order on their own.

The second idea comes from quality management. ISO 9001:2015 requires, in clause 7.5.2, that documents be suitably marked. They must also be reviewed and approved. Clause 7.5.3 governs the “control of documented information”. Where needed, this includes control of changes, such as version control. 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. The revised edition, ISO 9001:2026, has since been published. The clause numbers may have shifted in it, while the requirements themselves are older than any edition of the standard.

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 a stray “final” does not belong in the name, that is what the version is for; only the agreed final version has “FINAL” in place of the initials.

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. Saving a forwarded attachment 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.

The file’s identity belongs in the name; its content does not. 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 for finding the file, not for logging changes.

And once assigned, a name stays as it is. Renaming a file that has already gone out breaks every later link to it: 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 but 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 only to ensure 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 are enough, and afterwards both sides name their files the same way. And before signing comes one last reconciliation, where both sides briefly confirm by email 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.

The rules of evidence show how strict this is. The presumption of completeness and correctness applies to the signed contract. It is presumed that the text reflects what was agreed and that nothing else was agreed. Whoever relies on something else has to rebut the presumption. For a notarially recorded contract, the German Federal Court of Justice confirmed the presumption. A substantively divergent draft that the notary had circulated beforehand does not rebut it.¹ The same presumption applies to the privately signed document.² Rebuttal remains possible but has to succeed. A tidy draft folder is an indication for that, not proof. Sign the wrong file and you have, for the time being, the contract you signed. The position is different if you prove that both sides jointly intended the right version. What becomes of oral side agreements in that situation is covered in “No oral side agreements exist. But they do!”; when a version sent by email is legally received, and how that is proven, in “Proof of receipt of an email”.

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 the file name and date of the final copy by email?
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 otherwise lost searching the folder while the business waits. A good file name shows the true state of the file. Better to leave nothing else to chance, least of all with 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 recommends order in file names has seen enough chaos to know why.

Frequently asked questions

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 does not adopt the scheme?

On your own side the scheme helps at once. It is best to agree on it at the start of the negotiation. If the other side does not adopt it, the last reconciliation by email before signing remains as the safeguard.

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

No. Renaming a file that has already been sent breaks every later link to it. A better name is not a rename but the next version.

Notes

1. BGH, judgment of 10 June 2016 – V ZR 295/14, on notarially recorded documents and Section 415(1) ZPO. ↩

2. BGH, judgment of 3 March 2021 – XII ZR 92/19, para. 13, on the written contract document. ↩

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

---