Skip to main content

T-32 — Comparing different versions of the report

Tutorial ID

T-32

Section

Reporting & Billing

Title

Comparing Different Versions of the Report

Subtitle

Track what changed between report versions so every edit is intended, supported, and traceable.

Before You Begin

  • You have at least two versions of the same report to compare.

  • You know which team members contributed edits to the report and when.

What You Will Accomplish

By the end of this tutorial, you will know exactly what changed between any two versions of a report, whether each change was intended and supported, and which version is the correct one to finalize or share.

Why Does This Tutorial Matter

A report's history can matter long after the fact. Comparing versions makes an update visible instead of a black box — you can see what was added, removed, or revised, confirm that every change was deliberate, and explain how the report reached its current form.

Skip that comparison, and a small but important change can slip through unnoticed, an edit can quietly remove content you'd already verified, conflicting edits from different collaborators can overwrite each other, the report loses a defensible record of its own history, and the wrong version — missing reviewed changes or carrying rejected ones — can end up the one that's shared.

What to Do if Something Goes Wrong

The list below covers the most common problems when comparing report versions. Each entry follows the same pattern: what you'll notice, why it likely happened, a real example, and how to fix it.

Problem: You can see the latest version of the report, but not what it replaced or whether anything important was lost.

Likely cause: No version comparison was run between drafts, so a change — however small — went unreviewed.

Example: A paragraph is quietly shortened between two drafts, and no one notices a supporting statement was dropped until a reviewer asks about it later.

Fix:

  1. Open the version comparison for the two drafts in question.

  2. Review additions, removals, and edits in turn.

  3. Confirm that each change is intended and understood.

Problem: A version comparison shows an addition that isn't supported, or a removal of something that had already been verified.

Likely cause: An edit added an unsupported statement, or deleted a statement that had already been confirmed against its source, without anyone catching it at the time.

Example: A verified statement about a documented treatment is deleted during an edit meant to shorten the section, and the deletion goes unnoticed until the next comparison.

Fix:

  1. For each addition, confirm that it's supported and validated.

  2. For each removal, confirm that the removed content was genuinely no longer needed, and not a verified statement deleted by mistake.

  3. Restore or correct as needed.

Problem: Two edits to the same section contradict each other, or one collaborator's change appears to have overwritten another's.

Likely cause: Several people edited the report around the same time, and their changes clashed without being reconciled.

Example: One reviewer rewrites a conclusion for clarity while another edits the same paragraph for accuracy, and only one version survives without anyone noticing the conflict.

Fix:

  1. Identify which collaborator made which change.

  2. Reconcile conflicting edits with the people involved.

  3. Agree on a single, correct version to carry forward.

Problem: You can't show how or why the report changed when asked.

Likely cause: Version history wasn't maintained, or prior versions were overwritten instead of kept, so there's no record of the report's development.

Example: Opposing counsel asks when a specific conclusion was added to the report, and there's no version history to answer the question.

Fix:

  1. Use version history to maintain a record of changes over time.

  2. Note the reason for significant changes.

  3. Keep prior versions rather than overwriting them, so the development of the report can be shown if needed.

Problem: An outdated or superseded draft is sent to a recipient instead of the current, correct version.

Likely cause: The version being shared wasn't confirmed against a comparison before it went out, so a comparison error led to the wrong draft being sent.

Example: A draft that still contains a rejected edit is shared with an attorney, while the corrected version sits in the platform unsent.

Fix:

  1. Confirm, by comparison, which version is the current and correct one.

  2. Check that it contains all reviewed changes and none that were rejected.

  3. Share only the confirmed version, labeled clearly.

Tip

Make a version comparison part of finalizing, not an afterthought. A quick look at what changed since the last version is the simplest way to catch an accidental deletion before it leaves the platform.

Summary

Every version of the report is now compared before it's finalized, with every addition validated, every removal checked, every collaborator's edits reconciled, a clear history maintained, and only the confirmed version shared — so the report's evolution stays transparent and defensible.

Did this answer your question?