How to Compare Two Revit and Civil 3D Models: Automatically Detect What Changed Between Versions

Comparing models isn't overlaying two views and hunting for differences. It's answering four questions for every element:

Does it exist in both versions? If only in the new one, it's added. If only in the old one, it's deleted.

Is it in the same place? If its location changed, it's moved — and you need to know by how much and in which direction.

Does it carry the same data? If a parameter changed — section, material, level, diameter, elevation — it's modified, and you need the parameter, its old value and its new value.

Does the change matter? An element that moved 0.004 inches from rounding isn't a real change. A tolerance filter separates noise from what affects the project.

There are tools, and they're worth knowing before building anything. Each solves part of the problem.

In Revit:

• Copy/Monitor and Coordination Review. Revit can monitor certain elements of a linked model — levels, grids, columns, walls, floors — and flag when they change. Useful, but only for elements set up for monitoring, and it doesn't produce a full model report.
• Version comparison in Autodesk Docs. If the project lives in Autodesk's cloud, the viewer can compare two published versions and mark added, deleted and modified items. Good for a visual review; it depends on working on that platform.
• Navisworks. Has a model comparison tool and is the coordination standard. It requires exporting and working outside Revit.

In Civil 3D:

• DWG Compare. Comes from AutoCAD and highlights graphical differences between two DWGs. It compares geometry, not Civil 3D object data: it won't tell you an alignment changed between stations 12+00 and 14+50, or that a pipe changed diameter.
• Volume surface. For surfaces there's an excellent native answer: a difference surface between the old and new version shows where and by how much the ground changed.

This is what happens behind the button. It's worth understanding because it explains why the result is reliable.

1. Fingerprint the old version. It walks the model and stores, for each element: its unique ID, category and type, the parameters your company defined as relevant, and a geometry signature (location, dimensions, length or volume).

2. Fingerprint the new version. With the same rules, so the comparison is fair.

3. Match elements. First by unique ID, the most reliable key. When another team rebuilt part of the model and IDs changed, it matches by type and location and flags it as matched by position for someone to confirm.

4. Classify each element. Added, deleted, moved or modified. For modified ones, it records which parameter changed, the old value and the new one.

5. Filter the noise. It applies tolerances — for example, ignoring movements under 1 mm — and drops parameters that change on their own, like edit dates.

6. Deliver the result. A color-coded 3D view inside the program (green added, red deleted, amber modified), an Excel report filterable by discipline and level, and BCF issues to send to the responsible team.

In infrastructure, the important changes aren't "one object more or less": they're changes inside objects. So a Civil 3D comparison has to understand each type.

Alignments. Detects the segments where the geometry changed and reports them by station: "between 12+00 and 14+50, curve C-7 radius changed from 500 ft to 400 ft".

Profiles. Grades, vertical curves and finished-grade elevations that changed, also by station.

Surfaces. The elevation difference between versions, with the cut and fill volume that moved. It tells you whether the ground change affects your earthwork.

Pipe networks. Pipes added or removed, changes in diameter, material, slope and invert; structures that moved.

Corridors. Regions and assemblies that changed — where the biggest quantity changes hide.

1. Receiving third-party deliverables. When a consultant or subcontractor delivers a version, the change report is the first review: in minutes you know whether what was agreed changed, whether something that shouldn't have changed did, and what needs re-checking. Review stops depending on someone's memory.

2. Controlling change orders. Scope changes show up as added or modified elements between versions. With the report, every change order has its evidence: what changed, when, and in which version. Without it, many changes get absorbed instead of billed.

3. Updating drawings and takeoffs. Knowing exactly what changed lets you review only what's affected, instead of re-checking the whole project on every version.

Step 1 · Define what a change means to you. Which categories and parameters matter per discipline, and which tolerances to apply. This page is what turns the plugin into your tool rather than a generic one.

Step 2 · Keep IDs stable. Ask teams to work on the same model instead of rebuilding it, and not to copy-paste elements between files. That preserves IDs and makes the comparison exact.

Step 3 · Test it on two real versions. Take two deliveries from a closed project where you already know what changed. If the report finds what you found — and more — it's ready.

Step 4 · Make it part of intake. Every version that comes in goes through the comparison before being accepted. The report is filed with the deliverable.