How do you know which version of your terms a customer signed?

This question is almost never asked casually. It gets asked when something has gone wrong, usually two or three years after the document was signed, and usually by somebody who needs an answer within a day.

At that point the available evidence is: a signed PDF, an email it was attached to, and a folder on a shared drive containing several similar documents. What is missing is any way to connect them, because the signed PDF was named Terms - Signed.pdf and the folder contains four files that could each have produced it.

Why file names and folders fail

Three things happen to a document between being written and being needed as evidence, and each of them destroys a different piece of context.

It gets renamed. Usually more than once. Supply Terms v3.docx becomes Terms for Acme.docx becomes Acme signed.pdf. Each rename is reasonable in the moment and each one removes information.

It moves. Folder structures get reorganised, drives get migrated, a company changes storage providers. The path a document sat at when it was sent is not the path it sits at when it is needed.

It gets separated from the covering email. The email said "please find our standard terms attached, current as at March". The email is in somebody's account, possibly somebody who has left, and nobody thinks to look for it because the signed document seems self-sufficient.

The common failure of all three is the same: the identifying information was stored outside the document. Anything stored outside the document has a shorter life than the document.

Put the version inside the document

The reliable answer is to make the document identify itself, so that a printed copy found in a filing cabinet in 2031 is still identifiable.

In the footer of every page:

• a version identifier
• the date that version became current
• the document name as you refer to it internally

For example: Supply Terms v4.1: current from 12 March 2026. It is unglamorous, it takes ten seconds to add, and it converts every future version of this question from a research exercise into a glance.

Two details matter more than they look.

Every page, not the first page. Documents get scanned, photographed, and partially printed. A version identifier that only exists on page one is absent from most of the copies that will actually be produced in evidence.

A version identifier, not just a date. Dates get confused with the signing date, the effective date, and the date somebody re-saved the file. A version number is unambiguous because it means nothing else.

Keep a register of what was current when

The footer tells you which version a customer holds. It does not tell you what that version said, unless you have kept it.

So keep every superseded version, permanently, in a location clearly marked as superseded, named by version identifier. This is a small amount of storage and it is the difference between "they signed v4.1" and "they signed v4.1, and here is v4.1".

Alongside it, keep a one-line-per-version record: version identifier, date it became current, date it was superseded, and one sentence on what changed. That record answers the follow-up question, which is always "what was different about that version".

What to do about the documents already signed

You cannot retrofit a footer into documents that are already executed. What you can do is reconstruct the mapping while it is still reconstructable.

Take your list of versions in circulation. For each customer with a signed document, open the signed copy and compare it against the versions you have. In most cases the match is obvious within a minute, because versions differ in visible ways: a clause that is present or absent, a payment period, a heading.

Record the result: customer, version they hold, date signed. That table is worth building once, and it takes far less time now than it will after another two years of accumulation.

Where a signed document does not match any version you have, you have found a document somebody assembled themselves. Those are worth knowing about, and there are usually one or two.

What this does not answer

Knowing which version a customer signed is a filing outcome. What that version requires of you, and whether it says what you thought it said, is a different question and belongs to your own external adviser.

The reason the filing work comes first is that it makes the second question answerable at a sensible cost. "Here is the executed document, here is the version it corresponds to, here is what changed in the two versions since, and here is the specific clause we are arguing about" is a question with a bounded answer. "Here is a folder" is not.