Most MEP contractors evaluating contract review tools are asking the wrong first question. They want to know what the software can do. The better question is what the software will be able to read, and for most firms the honest answer is less than half the archive.
Here is what the inventory usually looks like once someone goes and checks. The executed subcontracts from the last five years are a mix of native PDFs from the general contractor's portal, scanned copies of signed hard pages, and photographs of signature blocks taken on a phone in a job trailer.
Exhibits are attached to some and missing from others. Change orders live partly in the project management system, partly in a shared drive, and partly in a superintendent's inbox. The same document type is called three different things depending on which project manager set up the folder.
None of that is unusual. It is the normal condition of a firm that has been busy building things rather than filing them. But it means that a tool which reads contracts, flags notice windows, and compares scope language against your standard exclusions will run on a fraction of what you own, and the fraction it misses is where the risk sits.
Scanned is not the same as readable
A scanned PDF is a picture. The software sees a page, not a clause. Optical character recognition can recover most of it, but most is doing a lot of work in that sentence. A signed subcontract that went through a fax machine in 2019, got photocopied, and was scanned at low resolution will come back with dropped words in exactly the places that matter: dollar figures, dates, section references, the number of days in a notice period.
The tool will not tell you it is guessing. It will return a result that looks complete, and someone downstream will treat a half-read indemnity clause as a fully read one. The failure is silent, which is the worst kind, because nobody goes looking for it until a claim is already late.
Native PDFs with embedded text are the standard. Everything below that needs either a re-scan at proper resolution or a manual check of the extracted text against the page. That is tedious, and it is also the difference between a contract review tool and a contract review theater.
The exhibits are where the money is
The base subcontract is usually the cleanest document in the file, and it is also the least interesting. The scope exhibit, the schedule exhibit, the insurance requirements, the list of excluded items, and the flow-down terms from the prime contract are where the actual obligations live. Those are also the pages most likely to be missing, attached to the wrong project, or present as a reference to a document that was never saved.
A review tool that reads the base agreement and reports that the notice period is ten days has told you something.
If Exhibit C modifies that to five days and Exhibit C is not in the folder, the tool has told you something wrong, and it has done so with confidence.
Before any software touches the archive, somebody has to confirm that each executed subcontract is complete. That is a checklist, a person, and a few weeks. It does not demo well. It is the whole foundation.
Three names for the same thing
The naming problem sounds trivial until it breaks the workflow. One PM saves subcontracts as "Sub Agreement," another as "Subcontract Executed," a third uses the GC's document number. Change orders are "CO," "PCO," "COR," and "Change Order" across the same five projects, and sometimes those are different documents and sometimes they are the same document at different stages.
Software can be taught to handle variation, but every variation you leave in place is a rule somebody has to write and maintain. More to the point, inconsistent naming is a symptom of inconsistent process. If nobody agreed on what to call the file, nobody agreed on who was responsible for making sure it got filed. Fixing the names is the easy part. The valuable part is the conversation it forces about ownership.
Pick one convention. Apply it to everything going forward. Then decide how far back to apply it to the archive, which for most firms is active projects plus anything still inside a warranty or claim window.
Why the cleanup outranks the tool
Every contractor who has been through this learns the same thing. The vendor evaluation took three weeks. The archive cleanup took three months. And the cleanup was what produced the results, because the tool was only ever going to be as good as what it could read.
There is a second reason the cleanup matters more. Software is rentable. Your competitor can sign the same contract review platform next quarter and have the same capability on the same timeline. A clean, complete, consistently named subcontract library is not rentable. It is an asset the firm built, it catches every notice window from now on, and the firm across town cannot buy it off a price sheet.
What to do first
Pull the executed subcontracts for every active project and check each one for completeness against the exhibit list. Flag the scans that need a re-scan. Agree on a naming convention and write it down somewhere people will see it. Name one person who owns the standard and has the authority to send a file back.
Then evaluate tools. By that point you will know exactly what you have, the vendor demo will run on your own documents rather than a sample set, and the result will tell you something true.
The bottleneck was never the software. It was the filing cabinet nobody wanted to open.