How document versioning works when two firms edit the same VC documents
On a VC round the SHA moves through 10-15 versions across two firms, and version control lives in filenames. Here's how document versioning works when both firms edit one canonical document: an Internal track each firm controls, an Official track they share, and a permanent locked copy saved for every version.
On a UK venture round, the documents are standardised and the version control is not.
UK Private Capital publishes model versions of the Shareholders’ Agreement, Subscription Agreement and Articles. Every firm starts from roughly the same pack. Then two firms spend eight to twelve weeks turning one canonical SHA into ten or fifteen versions, and the only thing tracking which version is current is the filename and the inbox it landed in.
SHA_v6_FINAL.docx. SHA_v6_FINAL_v2.docx. SHA_v6_FINAL_v2_FOUNDERSIDE_actually_final.docx. Every corporate lawyer has lived this. The document itself is fine. The system for knowing which copy is the live one, who changed what, and how to get back to last Tuesday’s draft is a person’s memory of an email thread.
Version control is the part of a deal that breaks first when the pace picks up. We built it into the core of the platform rather than adding it on later. Here is how it works.
The hard part is knowing which copy is current
Two firms can both edit a Word document perfectly well. What they cannot do over email is agree on which document is the document.
In a normal round, every exchange creates another fork. The investor’s lawyer sends v3. The founder’s lawyer opens it, edits, and now there are two v3s that differ. A typo fix lands thirty minutes later under the same filename, so two files share a name and hold different text. By week seven, an Outlook search for the SHA returns five files called FINAL and at least one of them is actually an earlier draft. Nobody is doing anything wrong. Email has no concept of a single document with a history, so people improvise one out of filenames, and it falls apart the moment a deal gets busy.
The fix is to treat the document as one thing with a history, rather than a pile of files. One SHA on the deal, with a timeline. Every change moves that document forward and leaves a locked version behind, so nobody has to ask which draft is current. There is one, and it is the one on the record.
Two tracks: Internal and Official
The first thing partners ask is the obvious one. If both firms work on one document, does the other side see my half-formed drafts and my margin notes?
No. Every document on the deal sits in two parallel tracks.
The Internal track is your firm’s. It is where your associate drafts, the partner marks up, and the trainee leaves comments. The other firm cannot see it and has no way in.
The Official track is the shared canonical version, the one both firms read. It is what “the current draft” actually points at across the table.
Only one firm holds the pen at a time. While you hold it, you work on your side and the other firm sees the last version you handed over, not the markup in progress. When you are ready, you hand the document to the other side. That handoff is what creates the next Official version: a locked, dated copy the other firm receives, with the pen, to make their pass. Nothing crosses to them until you choose to hand over, and your internal drafts stay yours throughout.
This is the part that makes a shared document safe to work on. It is the way two firms already negotiate, one side marking up and passing it back, except each pass is a clean version on the record instead of an attachment in an inbox. The firm controls exactly what crosses the boundary, and when.
Every version is locked the moment it is saved
When a version is saved to the Official track, the platform keeps a frozen, separate copy of the document exactly as it stood at that moment. With it sits a record of who saved it, when, which side they were on, which round of negotiation it belonged to, and an optional line on why. That is the version on the record, the one you can always come back to.
A saved version never changes again. The live document keeps moving, but each earlier version stays exactly as it was, locked and dated. The history of an SHA becomes a clean list of real versions you can open, compare and restore, instead of something you reconstruct from filenames and inbox dates. If anyone later asks what was agreed and when, the answer is on the record, not in someone’s memory of an email thread.
This is the difference between “I think v5 was the one before we moved off a 1x participating preference” and opening v5 to read exactly what it said. That version is still there, word for word, with the name of the person who saved it and the reason they gave.
Redlines move the version, in context
When the other side proposes a change, it lands as a tracked redline on the current Official version, with the comment anchored to the clause it touches.
Accepting it moves the version forward and saves the next locked version. Both firms see exactly what changed between the old version and the new one. The reasoning the other side gave on the drag-along threshold or the leaver provisions sits next to the language they changed, rather than in a separate inbox. Reject a redline and that decision is on the record too. The negotiation history and the version history end up as one and the same record.
Restore is one click, and it cannot clobber the other side
Because every saved version is a real frozen copy, going back is straightforward. Pick an earlier version and restore it. Any partner can do it from the version timeline, without raising a ticket or waiting on an IT team.
The one nuance that matters on a two-firm deal: a restore can never silently overwrite work the other side currently controls. If your firm holds the document, the restore rewrites the live copy in place and the timeline records that a restore happened, by whom. If the other side holds it, the same action lands as a fresh Internal draft for your firm instead. You always get the old version back. You never reach across the table and undo something the counterparty was relying on.
Signing freezes the version it was sent at
Signature is where loose version control does real damage, because a signed document that turns out to be the wrong draft is not a filename problem any more.
So a signing request is tied to one specific version. The version that goes out to signatories is locked at the moment the request is issued. If someone edits the live draft afterwards, that creates a new version on the record and leaves the version out for signature untouched. You can show that the executed document and the version that was agreed are one and the same, which is the point that matters if anyone ever questions what was signed.
What this simplifies, by role
The mechanics exist to make three people’s jobs smaller.
The associate doing the actual drafting stops managing files. No _v2_FOUNDERSIDE_actually_final naming convention to maintain, no Sunday night spent reconciling four side-letter copies against the SHA. They open the deal, see the current version, edit on the Internal track, and hand it over when the partner says go.
The partner reads a redline and its rationale together, controls exactly what crosses to the other firm, and can roll back a wrong handoff or a bad accept in one click. The diligence or the LP question lands. How did the founder vesting cliff settle, why did the liquidation preference move. The answer is a query on the version timeline, not a fortnight reconstructing five inboxes.
The founder logs in and sees the current Official version and what changed since they last looked, instead of asking their lawyer which attachment is live. They stop being the bottleneck on approving a side letter, because they saw it when it landed.
For all three, the version chase stops being something a person has to carry around in their head.
Why a DMS cannot do this on its own
You cannot retrofit this onto email, and you cannot quite get it from a document management system either. A DMS is built for one firm’s documents and one firm’s lifecycle. It is good at that, and it stays the firm’s source of truth: working drafts sync both ways between the firm’s DMS and the deal record, and an Official version mirrors back into the DMS as a read-only copy once it becomes Official.
What a DMS does not give you is the part that spans two firms: the access boundary between them, the Internal and Official tracks, a locked version saved every time something passes between the firms, and a restore that respects who holds the document. That work has to live between the two firms rather than inside either one.
We built DealSync around that from the start. One record with a full history, a history that cannot be altered after the fact, and a line between your private drafts and the shared version that someone crosses on purpose and that we test on every release. That is what lets two firms edit the same VC documents without losing track of which one is real.
How to try it
If you are running VC rounds and the current draft still lives in a filename, email mark@dealsync.uk and we will set up your next round on a shared deal record.
Either side opens it, the other side joins on the same record, and the joining firm’s first deal is free with unlimited users. Founders are always free. Both firms hold the SHA, every version is on the timeline, and the version chase stops.