Managing Manuscript Versions Across Co-Authors

ICMJE’s recommendations make the corresponding author “the one individual who takes primary responsibility for communication with the journal” (see CASRAI’s guide on corresponding author responsibilities under ICMJE for that role in full). What ICMJE does not specify is a mechanic almost every corresponding author ends up owning by default anyway: keeping track of which draft is the current one when several co-authors are editing, commenting on, and sending back a manuscript at the same time. This guide covers that specific, practical problem — version control, change communication, and conflict avoidance across a multi-author draft — not the ICMJE communication duties covered elsewhere.

Why this becomes a corresponding-author problem specifically

Nothing in ICMJE’s recommendations or in CRediT assigns “keeper of the master draft” as a formal role. It falls to the corresponding author in practice for a simple reason: that person is already the single point of contact with the journal, already has to produce one final, agreed-upon manuscript at submission and at every revision round, and is the one who will be held to account by the editor if the wrong version goes out. Whoever owns the outbound communication ends up owning version control, whether or not anyone assigned it explicitly.

The stakes are not abstract. A manuscript submitted with an outdated results table, a co-author’s rejected edit accidentally reintroduced, or a superseded conflict-of-interest disclosure is a correction risk at best and a data-integrity question at worst — and per ICMJE’s authorship criteria, every listed author is expected to have given final approval to the actual version that gets submitted, not to some draft that existed at some point during revisions. Sloppy version tracking makes that approval requirement hard to satisfy honestly.

Core practices for version control across co-authors

1. Establish one authoritative copy before writing starts

The single most common source of version conflict is co-authors independently editing separate copies of the same file — often started from an email attachment, each recipient making their own changes in isolation, with no shared file to reconcile against. Two structural fixes solve most of this:

A shared, cloud-hosted working document (e.g., a shared Google Doc, a shared Word file in OneDrive/SharePoint, or an Overleaf project for LaTeX manuscripts) that all co-authors edit directly, rather than emailing copies back and forth. Real-time or near-real-time syncing means there is structurally only one current version at any moment.
A version-controlled repository (e.g., a private Git repository, common for LaTeX manuscripts or anything with code/data alongside the text) where changes are committed with messages, and conflicts are surfaced and resolved explicitly rather than silently overwritten.

Either approach beats an email-attachment workflow. What matters is that there is exactly one place co-authors are told is authoritative, stated explicitly at kickoff — not left to be inferred.

2. Use a consistent, unambiguous file-naming and numbering convention

Where a shared live document isn’t practical (some journals’ submission systems still expect a single uploaded file, and some co-authors work better from exported drafts), a disciplined naming convention prevents the classic “which one is current” problem:

Include a version number and date in the filename itself, e.g. Manuscript_v4_2026-07-10.docx, incremented every time the authoritative copy changes hands — not left to whoever last edited it to invent their own scheme.
Avoid ambiguous suffixes like _final, _final2, or _final_REALLY — a version number that only ever increases is self-documenting in a way “final” is not, especially once a “final” draft comes back from a co-author with more changes.
State, in the covering message that circulates each version, exactly what changed since the last one and who should act on it next — see the change-communication section below.

This distinction matters at the terminology level too: CASRAI’s dictionary defines document version as a discrete, identifiable state of a document at a point in time, which is a different concept from a Journal Article Version (JAV) — NISO’s controlled vocabulary for the publication-stage versions of a published article (Author’s Original, Accepted Manuscript, Version of Record, and so on). The internal drafts a corresponding author is managing across co-authors are all, in JAV terms, pre-submission states of the Author’s Original; JAV labels only start to apply once a version formally exits the authoring stage.

3. Use track-changes and commenting tools deliberately, not as an afterthought

Word’s Track Changes, Google Docs’ suggestion mode, and equivalent features in LaTeX-adjacent tools (Overleaf’s track-changes mode, or diff tools against prior Git commits) exist specifically so that a change is visible and attributable rather than silently merged into the prose. Practices worth setting explicitly at the start of a collaboration, not discovered mid-revision:

Require substantive edits to go in as tracked suggestions/comments rather than direct edits to running text, at least until the corresponding author (or a designated lead writer) has reviewed and accepted them into the authoritative copy.
Periodically consolidate accepted changes and clear the tracked-changes history, so the working document doesn’t accumulate an unreadable stack of old suggestions — while keeping a dated, saved copy of each consolidated version for the record.
Treat unresolved comments as a submission blocker: a version with open, unaddressed comment threads is not the version that should go out, even under deadline pressure.

4. Communicate every substantive round explicitly

Version control is a file-management problem; change communication is the human half of the same problem, and both fail independently of each other. A well-organized file with no explanatory message accompanying it still produces confusion about what changed and why. Practices that hold up across a typical multi-round revision:

Summarize what changed in the message that accompanies each new version — not just “see attached,” but specifically which sections were touched and why (e.g., responding to a specific co-author’s comment, incorporating new results, addressing a reviewer point during revision).
Set an explicit deadline and a clear action for each round — “please review and reply with comments by [date], silence will be read as approval” versus “please review and confirm your approval by [date]” are different asks, and co-authors need to know which one applies.
Confirm final approval explicitly, in writing, from every author before submission or resubmission — not inferred from the absence of objections. This is also the practical mechanism by which the corresponding author satisfies ICMJE’s expectation that every author has approved the actual version being submitted, discussed above.
Route reviewer/editor correspondence back through the same shared record during peer review, so that revision decisions and the reasoning behind them are visible to every co-author, not just relayed piecemeal by whoever happens to check email first.

5. Avoid and resolve conflicting simultaneous edits

Even with a shared authoritative copy, two co-authors can end up editing the same passage at the same time. A few concrete mitigations:

Section ownership. For manuscripts with clearly divisible sections (methods, a specific results subsection, a discussion point tied to one author’s expertise), assigning an informal “owner” per section reduces the odds of two people rewriting the same paragraph independently — without preventing anyone from commenting outside their section.
Short, bounded editing windows rather than an open-ended “edit whenever” period, especially close to a deadline, so the corresponding author isn’t merging changes from three co-authors who all worked from the same stale starting point.
A designated merge point. When conflicting edits do happen (real-time co-editing tools will sometimes surface this directly as a conflict; asynchronous tools may just produce two divergent copies), one person — typically the corresponding author or a designated lead writer — should be the one who reconciles them into a single version, rather than leaving co-authors to informally negotiate whose edit “wins.”
A brief, dated changelog for longer or more contentious manuscripts, kept alongside the working document, recording what changed at each major version and who requested it. This is far more useful after the fact — particularly if an authorship or content dispute arises later — than trying to reconstruct the history from a chain of old emails.

Manuscript-exchange tools that reduce version risk at the submission boundary

Version-control risk doesn’t end when a manuscript is finished internally — the handoff to a journal’s submission system, and any subsequent transfer between journals (e.g. a cascading-peer-review referral), is another point where the wrong file can travel. NISO’s Manuscript Exchange Common Approach (MECA) standardizes how a manuscript package (files, metadata, and peer-review history) is transferred between systems, which reduces the risk of a stale or mismatched version being carried forward when a paper moves between platforms. It doesn’t address co-author-side version management directly, but it’s the relevant standards context for what happens to a manuscript’s version identity once it leaves the authoring stage.

A note on co-corresponding authors

Where a journal permits more than one corresponding author (see CASRAI’s guide on co-corresponding authors), version-control discipline matters even more: without a single person who is unambiguously the last word on which file is current, two corresponding authors can each believe they hold the authoritative copy. The fixes are the same ones above, but the “one authoritative copy, stated explicitly” rule becomes load-bearing rather than just good practice — co-corresponding authors should agree, in advance, on who actually merges and circulates each version, even if both are copied on all correspondence.

Frequently asked questions

Is managing manuscript versions an ICMJE-defined corresponding-author duty?

Not explicitly. ICMJE’s recommendations define the corresponding author’s duties in terms of communication with the journal — administrative completeness, editorial responsiveness, and post-publication availability (see corresponding author responsibilities). Version control across co-authors isn’t named as a separate ICMJE duty, but it falls to the corresponding author in practice because they’re already the person responsible for producing the single version that goes to the journal at each stage.

What’s the difference between a “document version” and a “Journal Article Version (JAV)”?

A document version is any discrete, identifiable state of a manuscript file at a point in time — including every internal draft during co-author revisions. A Journal Article Version (JAV) is NISO’s specific, controlled set of labels (Author’s Original, Submitted Manuscript, Accepted Manuscript, Proof, Version of Record, Corrected Version of Record) that apply once a manuscript enters the formal publication pipeline. Every JAV is a document version; not every document version is a JAV.

Should co-authors edit directly in a shared file, or send tracked-changes copies back to the corresponding author?

Both are workable if agreed explicitly at the outset; the failure mode is mixing approaches without saying so. A shared live document (cloud doc or Git repository) structurally prevents version fragmentation. A tracked-changes-and-email workflow can also work, provided the corresponding author is disciplined about consolidating changes into a single numbered version after each round rather than letting multiple marked-up copies accumulate in parallel.

What should happen if two co-authors submit conflicting edits to the same passage?

One designated person — typically the corresponding author — should reconcile the conflict into a single version rather than leaving co-authors to negotiate it informally by email. Where the disagreement is substantive (a factual or interpretive dispute, not just wording), it’s worth resolving as an explicit discussion among the affected authors before the merged version is circulated, so that the final text reflects an actual agreement rather than whichever edit happened to be applied last.

Does poor version control create an authorship-dispute risk?

It can. If a co-author later says they never approved the version that was actually submitted, or that their edits were dropped without discussion, that’s a harder claim to resolve without a clear version history and explicit approval records. See CASRAI’s dictionary entry on authorship dispute for how these disagreements typically arise and get resolved; a documented version and approval trail is one of the more effective preventive measures available to a corresponding author.

Related CASRAI resources

Sources: ICMJE, “Defining the Role of Authors and Contributors”, verified against CASRAI’s own prior verification dated 2026-07-09; NISO’s Journal Article Versions (JAV) and MECA standards documentation, as referenced in CASRAI’s dictionary entries linked above.