The revision request versus the revision
A change request says what the revision is supposed to do: update step 6.3, add a new safety note. The revised SOP is what actually changed, and the two are not always the same. QA sign-off should be on the actual difference between the two versions, not on the description of it.
This is rarely about bad intent. The author starts from a working copy that already has a half-finished edit from last year. A colleague tidies the wording of a nearby step while they are in the file. A template update changes the responsibilities table. Each of these gets into the effective document unless someone compares the versions.
An example review
Suppose a change request asks for one thing: step 6.3 of an equipment cleaning SOP should change the rinse volume from 2 litres to 3 litres. The author also adds a safety note about eye protection, which was agreed in a separate meeting.
The comparison of the current effective version against the draft returns four changes. The rinse volume in 6.3. The new safety note. A changed hold time in step 7.1, from 24 hours to 48 hours. And a deleted sentence in section 9 about recording the lot number of the cleaning agent.
The first two match the request. The other two need a conversation. Maybe the hold time change was validated and simply left off the request. Maybe the deleted sentence was removed by accident when a paragraph was rearranged. Either way, QA now knows about them before the SOP goes effective instead of after the next audit. Without the comparison, a reviewer reading a 20-page draft would very likely have caught the safety note, which is new and visible, and missed the deletion, which leaves nothing behind to see.
The review in practice
- Upload the current effective SOP as the older version and the proposed revision as the newer one.
- Read the change list. It should contain the items in the change request and nothing else.
- Take every unlisted change back to the author, and either add it to the change request or remove it from the draft.
- Attach the redlined PDF to the approval record as evidence of what was reviewed.
- Use the side-by-side view for training, so staff see the old and new step together.
Common mistakes
Comparing against the previous draft rather than the current effective version. If the draft went through three rounds, comparing round three against round two only shows the last round of edits. The comparison that matters for sign-off is effective version against proposed version.
Comparing two exports from different tools. If the effective SOP was printed to PDF from one system and the draft was exported from another, fonts and spacing may differ. The engine classifies formatting changes separately from substantive text changes, so the real edits stay visible, but it helps to export both versions the same way when you can.
Reviewing a signed scan. A wet-signed SOP that was scanned without OCR has no text layer and is refused. Use the controlled electronic copy, or run OCR first. This guide on scanned PDFs explains how OCR copies behave.
Why determinism matters here
A comparison that depends on a language model can produce different output on different days. In a regulated QA process that is a problem: the record of what was reviewed must be reproducible. The engine here is rules-based, and the same two documents always produce the same change list. If an inspector asks to see the review, you can rerun the comparison and get the same result as the one attached to the record.
It also means the comparison can be described plainly in your own procedure for document control. Inputs are the two controlled PDFs, the output is the change list and redline, and there is no setting or prompt that could make one reviewer's result differ from another's. That is far easier to write into an SOP than a tool whose output depends on how it was asked.
Beyond SOPs
The same review applies to work instructions, validation protocols, batch record templates and specifications. Work instructions are often two-column or heavy on tables, and both are handled: two-column pages are read in reading order, and tables that did not change are held out of the diff.
Teams that run this many times a week usually outgrow the free tier. Enterprise deployments run inside the company's own infrastructure with pinned versions, which supports IQ/OQ documentation. The engine itself was first built for FDA label change detection, and the pharma industry page covers how QA and regulatory teams use it together.
Try it on your own documents. Upload two versions on the homepage. Documents up to 30 pages need no account, and nothing is stored.
Industry page: PDF comparison for pharma and life sciences