Legal Document Version Control: Beyond Track Changes and File Names

Every lawyer has seen it. The folder full of files named Agreement_v3_FINAL_reviewed_JD.docx, Agreement_v3_FINAL_reviewed_JD_CLEAN.docx, and Agreement_v3_FINAL_reviewed_JD_CLEAN_v2.docx. The email thread where someone asks "which version did we send them?" and three people give different answers.

Lawyers call this version control. It isn't.

What most law firms have is a naming convention and a prayer. The naming convention tells you roughly when a file was created and by whom. The prayer is that everyone followed the convention, nobody edited the wrong file, and the version you're looking at is actually the one you think it is.

This post is about what actual version control means in the context of contract negotiation, why the current approach breaks down, and how a simple comparison workflow fills the gap without requiring new software, new systems, or anyone to change how they work.

What lawyers call "version control" today

In most law firms, "version control" means one or more of the following:

File naming conventions. The firm has a convention: add a version number, add your initials, add a date. Agreement_v1.docx becomes Agreement_v2_ML.docx becomes Agreement_v3_ML_reviewed.docx. Everyone understands the convention. Nobody follows it consistently. After three rounds of negotiation involving four people, the folder has twelve files and nobody can tell you with certainty which one was sent to the client.

Folder structures. Some firms organize by round: Round 1/, Round 2/, Final/. This is better than a flat folder of files, but it still depends on humans putting the right file in the right folder. And "Final" is never final. There is always a Final/ and a Final - Updated/ and eventually a Final - ACTUALLY FINAL/.

Email threads as version history. The email chain becomes the de facto record of which version was sent when. "I sent v3 on Tuesday, they sent back v4 on Thursday." The problem is that email is a communication tool, not a document management tool. Attachments get detached, forwarded with the wrong version, or saved locally and edited without anyone else knowing.

Document management systems. Larger firms use systems like iManage or NetDocuments. These are genuinely better: they provide check-in/check-out workflows, version numbers, audit trails, and search. But they are expensive, they require discipline to use correctly, and they still rely on humans to check in the right version at the right time. A DMS solves the storage and retrieval problem. It does not solve the comparison problem.

None of these approaches answer the question that actually matters: what changed between version 3 and version 5? They store versions. They label versions. But they do not compare versions. And without comparison, you have a filing system, not version control.

Why file names fail

File naming conventions seem reasonable in principle. In practice, they break in predictable ways that create real risk.

The parallel edit problem. Two people on the same team both open Agreement_v3.docx. One makes substantive edits and saves as Agreement_v4.docx. The other makes different substantive edits and also saves as Agreement_v4.docx. Depending on timing and file system, one overwrites the other, or both exist in different locations, or one ends up as Agreement_v4_ML.docx and the other as Agreement_v4_JD.docx. Either way, there is no single v4 that represents the agreed state of the document.

The "FINAL" problem. A file is named "FINAL." Then someone makes a correction. The corrected version is either saved over the original (destroying the record of what "FINAL" used to contain) or saved as "FINAL_v2" (which means "FINAL" wasn't). After a few iterations, the word "FINAL" in a filename tells you nothing about whether the file is, in fact, final.

The sent vs. saved mismatch. You email Agreement_v3_clean.docx to the other side. Then you notice a typo, fix it locally, and save. Your local Agreement_v3_clean.docx is now different from the version you sent. When the other side sends back their edits based on the version you emailed, you compare against your local copy and get confused by a change you made yourself.

The metadata problem. A file name tells you the version number, maybe the date, maybe who touched it. It tells you nothing about the content. Agreement_v3.docx and Agreement_v4.docx might differ by a single comma or by thirty paragraphs. You cannot tell from the file name. You cannot diff file names. The only way to know what changed is to open both files and compare them.

These are not edge cases. They are the normal state of affairs in contract negotiation. Every lawyer has experienced at least one of them. Most have experienced all of them.

Why Track Changes isn't version control

If file names don't work, what about Track Changes? It shows edits in context. It attributes changes to specific authors. It lets you accept and reject changes one by one. Isn't that version control?

No. Track Changes is a collaboration feature. It records edits made in real time while the feature is enabled. That is useful, but it is not version control. Here is the distinction.

Track Changes does not capture snapshots. Version control means being able to say "show me exactly what the document looked like at 3pm on Tuesday." Track Changes cannot do this. It records a stream of edits, not a series of states. Once you accept or reject a change, the previous state is gone. There is no way to reconstruct the document as it existed before a change was accepted.

Track Changes does not support arbitrary comparison. You cannot compare version 2 against version 5 using Track Changes. Track Changes shows you the edits that accumulated between the current state and whenever someone last accepted all changes. It is linear and forward-only. If you want to compare non-adjacent versions, Track Changes cannot help.

Track Changes is only reliable when it is on. If someone turns off Track Changes, makes edits, and turns it back on, those edits are invisible. The document looks like it has complete tracking. It doesn't. This is the fundamental trust problem with Track Changes, and it happens more often than most lawyers realize, usually by accident rather than intent. We covered this in detail in our post on whether you can trust Track Changes.

Track Changes gets messy over multiple rounds. After three or four rounds of negotiation with Track Changes accumulating, the markup becomes unreadable. Nested edits, changes to changes, accepted-then-re-edited text. At some point, someone accepts all changes "to clean things up." That acceptance destroys the editing history. The document is now clean, but you've lost the record of what changed and when.

Track Changes is useful as a real-time editing tool. It shows you what the other side intended to change in this round. But it is not a system for managing versions across a multi-round negotiation. It was never designed to be.

What actual version control looks like

Software engineers solved the version control problem decades ago. Their tools (Git, Subversion, Mercurial) are built on three core capabilities:

1. Snapshots. The ability to save the complete state of a document at any point in time, creating an immutable record of what the document looked like at that moment.
2. Comparison. The ability to compare any two snapshots and see exactly what changed between them. Not just "something changed" but precisely which lines were added, removed, or modified.
3. History. A chronological record of every snapshot, so you can trace the evolution of the document from beginning to end and understand when each change was introduced.

Lawyers don't need Git. But they need the same three capabilities applied to contracts. In practical terms, this means:

Saving clean copies at milestones. Before every send, accept all changes and save a clean copy. This is your snapshot. It represents the exact state of the document at that point in the negotiation. Not a redline. Not a file with accumulated Track Changes. A clean, final version of what you are sending.

Comparing on receipt. When you receive a new version from the other side, compare it against your last clean copy. This comparison tells you everything that changed between what you sent and what you received. It does not depend on Track Changes being enabled. It does not depend on file names matching. It compares the actual content.

Keeping every version. Don't delete old clean copies. They are your history. If you need to know what the document looked like at any point in the negotiation, you have the file. If you need to compare any two points in the history, you have both files.

This is not a technology problem. It is a discipline problem. The tools already exist. The missing piece is the workflow.

The comparison step: how it fills the gap

Document comparison is the critical capability that turns a collection of saved files into actual version control. Without comparison, you have a filing cabinet. With comparison, you have a history of every change that was made across the entire negotiation.

Here is why comparison matters more than any other piece of the puzzle:

Comparison is independent of process. It does not matter how the other side edited the document. It does not matter whether Track Changes was on or off. It does not matter whether they used your template or converted to theirs. Comparison reads the content of two files and reports every difference. Process failures upstream do not affect it.

Comparison works across any two versions. Want to compare round 1 against round 4? Compare the round 1 clean copy against the round 4 clean copy. Want to compare what you sent against what you received? Compare those two files. Want to verify the final execution copy? Compare it against the last agreed draft. Any two files, any two points in time.

Comparison catches what humans miss. Reading two versions side-by-side and trying to spot differences is slow and unreliable. A 40-page contract with a single changed number in a table on page 27 will defeat visual review almost every time. Comparison tools find every difference, including the ones that are easy to overlook: changed numbers, deleted carve-outs, added qualifications, shifted cross-references.

Even without a formal document management system, even without perfect file naming, even without Track Changes, if you save a clean copy before every send and compare against what comes back, you have effective version control for the content that actually matters.

A simple version control workflow for small firms

This workflow requires no new software beyond a document comparison tool. It adds about two minutes per negotiation round. It works for solo practitioners and small firms that don't have (or don't want) a document management system.

Step 1: Save a clean copy before every send

Before you email a draft to the other side, accept all Track Changes and save a clean copy. Name it with the date and round number: ClientName_Agreement_2026-03-12_R3_clean.docx. This file represents exactly what you sent. Do not edit it after saving. If you need to make a last-minute change, make it and save a new clean copy. The clean copy is your snapshot. It is immutable.

Step 2: Compare on receipt

When the other side sends back their version, compare it against your last clean copy. Use Word Compare for simple documents. Use Clausul when you need formatting noise filtered and changes classified. The comparison shows you every difference between what you sent and what you received, regardless of whether Track Changes was used.

Step 3: Save their version as your new baseline

Save the version you received with a clear name: ClientName_Agreement_2026-03-12_R3_from-counterparty.docx. This is their snapshot. When you make your edits and send back a new version, you'll save another clean copy (step 1), and the cycle repeats.

Step 4: Repeat for every round

Each round of the negotiation produces two files: the clean copy you sent and the version you received. After four rounds, you have eight files and the ability to compare any two of them. You can trace exactly how any clause evolved across the negotiation. You can verify what was agreed at each stage. You can catch version control mistakes from either side.

At the end of the negotiation, run one final comparison: compare the execution copy against the last agreed draft. This is the most important comparison in the entire lifecycle. It takes two minutes and it catches the errors that otherwise become binding.

The bottom line

The version control problem in legal practice is not really a technology problem. It is a workflow gap. Lawyers have been storing versions for decades using file names, folders, email attachments, and DMS systems. What has been missing is the comparison step: the ability to quickly and reliably see what changed between any two versions of a document.

You do not need to overhaul your filing system. You do not need to buy a document management system. You need two things: the discipline to save a clean copy before every send, and a tool to compare what you sent against what you received.

The clean copies give you snapshots. The comparisons give you diffs. Together, they give you what file names and Track Changes never could: a reliable record of what actually changed, when, and between which versions.

Start with your next negotiation. Save a clean copy before you send. Compare when you receive. It is the simplest improvement you can make to your contract workflow, and it pays for itself the first time it catches something.

Frequently asked questions

What is the best way to manage contract versions in a small law firm?

Save a clean copy of every draft before you send it, using a consistent naming convention that includes the date and round number (for example, "ClientName_Agreement_2026-03-12_R3_clean.docx"). When you receive a new version from the other side, compare it against your last clean copy using any document comparison tool. Save their version as your new baseline and repeat. This gives you a complete content history without requiring a document management system. The naming convention keeps your folder organized, and the comparison step ensures you know exactly what changed in each round. For firms that handle high volume, a document management system like NetDocuments or iManage adds check-in/check-out discipline and audit trails, but the comparison step remains essential regardless of how you store the files.

Should I use a document management system for version control?

A document management system (DMS) like iManage or NetDocuments is valuable for organizing and storing document versions, but it is not a substitute for document comparison. A DMS solves the storage and retrieval problem: it keeps versions organized, prevents accidental overwrites, and provides an audit trail of who checked in what and when. But it does not solve the comparison problem. You still need a way to see what changed between any two versions. If your firm has the budget, a DMS plus a comparison tool is the ideal setup. If you have to choose one, start with the comparison step. An organized folder with clean copies and a comparison workflow gives you the content verification that matters most.

How do I compare two versions of a contract in Word?

In Word, go to the Review tab, click Compare, then select Compare Documents. Choose your original document and the revised document, then click OK. Word generates a new document showing the differences as tracked changes. This works for simple comparisons but has significant limitations for legal contracts: it flags every formatting difference alongside content changes, it does not classify changes by importance, and it can produce noisy results for documents with complex tables or structural edits. For routine comparisons of short documents, Word Compare is sufficient. For longer contracts or documents with heavy formatting differences, a dedicated comparison tool like Clausul will separate the signal from the noise.

What file naming convention should I use for contract drafts?

Use a convention that includes the counterparty name, document type, date, round number, and status. For example: "AcmeCorp_MSA_2026-03-12_R3_clean.docx" or "AcmeCorp_MSA_2026-03-12_R3_redline.docx." Never use "FINAL" in a filename because it will inevitably be edited again. The date format should be YYYY-MM-DD so that files sort chronologically. The round number (R1, R2, R3) tracks the negotiation sequence. The status suffix (clean or redline) distinguishes between the clean baseline and the tracked-changes version. Whatever convention you choose, the most important thing is consistency. Pick one format, document it, and make sure everyone on the team uses it.

How many versions of a contract should I keep?

Keep every version you sent and every version you received, at minimum. For each round of negotiation, you should have two files: the clean copy you sent and the version you received back. This gives you the ability to compare any two points in the negotiation history. Deleting intermediate versions to "clean up" your folder removes your ability to verify what changed at each stage, which can matter if a dispute arises later about what was agreed and when. Storage is cheap. Keep everything. If you are using a document management system, it handles this automatically. If you are using folders, create a subfolder for each round or use the naming convention to keep versions distinguishable.

---