AI Due Diligence: Where Manual Deal Review Breaks Down
A deal doesn't stall during negotiations — it stalls at a desk piled with documents: charters, statements, contracts, court rulings, financials — hundreds of pages in scans and spreadsheets with no structure whatsoever.
Each analyst reads their own block, and by the middle of the package attention drops: the legal entity from the statement is no longer cross-checked against the signatory in the contract.
Manual document review scales only by adding people. A second lawyer doubles the labor costs, but doesn't halve the time needed to prepare the opinion — time grows for consolidating versions, resolving discrepancies, and aligning conclusions among participants.
Missed risks almost never sit in a single file.
They live at the intersections: a chain of ownership that, through a third legal entity, leads to a counterparty on the unreliable-parties list; a lien that surfaces in one contract and goes unmentioned in another; arbitration where the defendant isn't the company under review but its management structure. By eye, such connections are assembled selectively — which means randomly.
AI Due Diligence closes precisely this gap: documents are parsed in full, entities and the relationships between them are consolidated into a graph, and the opinion is assembled from verifiable facts rather than from the analyst's memory.
Below is how this works in counterparty verification automation and what actually changes in the deal timeline.
What Changes After Implementing Automated Review
The first effect is visible at the intake: the review pipeline accepts the entire document package, not a regulation-defined sample.
Scans, spreadsheets, and contract annexes flow through the same stream as text files — extraction is built on Apache Tika with recognition of copies lacking a text layer.
Coverage completeness grows from a portion of the package to near-total, and a missed document ceases to be a matter of luck.
The speed of the opinion is determined not by reading pace but by the time spent consolidating data.
Fields are normalized into a single schema — amounts, dates, parties, terms, termination conditions — and the analyst receives a draft with ready-made tables instead of a stack of files.
Preparation time compresses from days to hours, and every conclusion is backed by a reference to the page and paragraph of the source: the reviewer looks at the exact point where a value came from rather than re-reading the entire document.
The class of manual-transcription errors also disappears — typos in amounts, lost annexes, mismatched dates. Cross-checks in the pipeline compare a single value across the contract, annex, and statement, and flag a discrepancy before it reaches the opinion.
Repeat passes change in nature as well: review is versioned, and when the package is updated, only the changed documents are reprocessed — the team closes the delta instead of reconciling from scratch.
Data quality becomes measurable: the share of fields extracted and cross-checked without manual edits shows where configuration is still needed.
Review Scenarios: Full, Sampling, and Hybrid
During pre-deal verification, the mode is chosen not by deal size but by the volume of the document corpus and the cost of a missed clause.
The same entity and reference extraction works in three modes — the difference lies in how many documents undergo full review and at what stage a human joins the work.
| Mode | When It Fits | Limitations |
|---|---|---|
| Full review | The corpus fits within the deal window, or missing a single clause is unacceptable: representations, change-of-control conditions, break fees | Time grows linearly with volume, and the mass contains a share of boilerplate documents with nothing to review |
| Sampling review | A risk map across a corpus of hundreds of contracts is needed: the density of deviations matters, not every page | An atypical clause in a non-selected document stays out of the report; sampling requires justification — stratification by type, date, counterparty |
| Hybrid mode | The corpus is mixed: the main volume, annexes, correspondence, scans | Requires calibration of the confidence threshold and routing rules, otherwise the expert either drowns in the flow or sees only the obvious |
The Expert's Role and Mode Switching
The model tags and extracts, but the materiality of a clause is confirmed by a lawyer or analyst — that is what the hybrid mode is built on.
The first pass runs across the entire corpus without exceptions; the second runs only on documents where a trigger fired or confidence fell below the threshold, and every deviation arrives with a reference to the page and clause.
Modes are compatible with one another: tagging, references, and revision history are shared; only the depth of the pass changes. That's why a corpus can start with sampling and, as deal closing approaches, expand to full review without rebuilding the result from scratch.
How Implementation Works: From Data Audit to Handover
Implementation runs in short cycles: each step produces an artifact that can be verified — a corpus map, an extraction schema, a quality report. Progress is visible not through presentations but through the share of clauses the system closes on its own, without manual edits.
- Document corpus audit. We analyze what will actually arrive at the intake: formats, scans without a text layer, duplicates, languages, standard templates. The output is a corpus map and an estimate of the share of documents suitable for automated review.
- Entity extraction schema. We agree on the list of entities and relationships needed for conclusions: parties, shares, dates, obligations, termination conditions. The schema is locked before configuration — rework at later stages costs more.
- Ground-truth tagging. On a control sample of documents, we manually tag the correct answers — this is the benchmark for measurements. On top of that, we configure reconciliation rules and the thresholds at which the system must route a clause to a lawyer.
- Acceptance on the control sample. We calculate extraction recall and precision, and the share of clauses closed without manual edits. Acceptance runs on a pre-agreed document set, not on a showcase demo.
- Pilot on a live stream. We launch on a stream of deals with parallel manual review: discrepancies are analyzed, rules refined. The goal is stable metrics on documents the system has never seen before.
- Solution handover and team training. We deliver documentation, procedures, access credentials, and instructions for updating rules, and we train analysts and lawyers. After handover, the team changes thresholds and adds entities on its own.
Models, Extraction Rules, and Due Diligence Report Templates
A Due Diligence automation project makes sense if, after delivery, the setup remains manageable without us.
That's why models, rules, and templates live not in code but in configuration and separate files: an analyst or lawyer edits the wording themselves, without rebuilding the solution.
Every artifact is versioned — in a disputed conclusion, it's clear which rule fired and on which document.
What exactly stays with the client:
- Extraction rules — a set of rules and hints for each field: what counts as a registration date, how to parse an address, which wordings count as an indicator of affiliation. Changed in configuration, applied without developer involvement.
- Counterparty registry — a normalized register with identifiers, former names, and relationships between companies and individuals. The basis for matching entities from different sources.
- Opinion template — an editable report template: sections, order of conclusions, a mandatory source reference under each statement, a field for a manual comment.
- Models and confidence thresholds — configured extraction and verification models with thresholds at which a conclusion goes to manual validation instead of into the report.
- Solution documentation — the processing scheme from document package upload to the finished opinion, a field dictionary, a list of sources and their priority rules.
- Support procedures — instructions for handling failures: what to do at low confidence, how to add a field, how to correctly roll back a rules change.
We separately formalize the handover of artifacts: a repository with change history, access credentials and roles, and a session with the client's team on editing rules and templates.
Case Study: Automated Review of a Portfolio of 300+ Companies
Before: Sampling Instead of Full Review
The portfolio — 300+ companies, from 30 to 200 documents each: incorporation documents, statements, contracts, meeting minutes.
Manual review took about five weeks and relied on sampling: analysts managed to open roughly 2% of files, and the rest was closed based on the counterparty's word.
Connections between companies — shared addresses, directors, equity stakes — surfaced after the deal had already closed, when it was too late to restructure.
After: Full Review and a Relationship Graph
We assembled a pipeline: extraction of requisites and entities from scans and spreadsheets, normalization of names and addresses, reconciliation against external registries and Dow Jones Risk & Compliance databases.
On top — a graph where an edge means a confirmed requisite match rather than string similarity, so affiliation checks run on a formal criterion. Every conclusion arrives with a reference to the page and fragment of the source document.
Metrics after launch: preparation of an executive summary for the entire portfolio — two days instead of five weeks, full review — 100% of files instead of 2%, and the share of identified connections between counterparties tripled.
False positives on similar names dropped thanks to normalization — disputed cases go into a manual review queue prioritized by risk, and a repeat run after registry updates produces a comparable result.
How Does Automated Review Differ from Manual Sampling?
Manual sampling relies on what the expert managed to open. They read documents until the time budget is exhausted and stop at whatever picture has emerged.
Corpus coverage rarely reaches even a tenth, and the composition of the sample is set by initial hypotheses rather than by the structure of the data. The gap is invisible: an unread contract with a change-of-control clause leaves no trace in the report.
Automated review runs across the entire corpus — including attachments, scans, and correspondence. The system extracts entities, relationships, dates, termination conditions, and encumbrances, preserving a source reference for every fact.
Corpus coverage becomes measurable: the share of processed documents and the share of fields where confirmation was found are visible in the report rather than estimated by eye.
Reproducibility of the result is the second difference. A repeat run on the same document set produces the same conclusion: the model version and review rules are locked, and intermediate decisions are recorded in a log.
Manual sampling has no such property — when the person changes, the sample, the interpretation, and the outcome change, and explaining the discrepancy after the fact is nearly impossible.
Automated review, however, does not eliminate expert involvement. A human remains in the loop at three points: defining materiality criteria for a specific deal, resolving contradictions between sources, and issuing judgment on conclusions flagged as ambiguous. The system removes the routine and makes gaps visible — interpretation still rests with the expert.
Limitations of Automation and Typical Implementation Mistakes
It's more sensible to name the boundaries up front: automation reliably handles the typical stream — contracts, statements, incorporation documents, financials in standard formats.
It breaks down on third- and fourth-generation copies where the text "drifts," on handwritten annexes, on homemade spreadsheets, and on documents in rare languages where training data is scarce.
An error here costs more than manual review: a false extraction goes into the report and changes the conclusion.
We don't pass off uncertainty as a result. Every field has a confidence threshold; if it isn't met, the value isn't substituted, and the document is flagged as requiring review — the expert receives the page and fragment the system couldn't parse.
The limitations of automation remain visible rather than dissolving into an average accuracy figure.
How do you handle poor-quality scans?
Before recognition comes preparation: alignment, noise suppression, contrast correction, and splitting of spreads. Then a check against control fields: if key requisites aren't readable, the document goes to manual verification rather than into the general flow. We show the share of such documents before the start, not after.
What happens with non-standard documents and exceptions in rules?
A rule is described together with its exceptions: which condition applies, what we do on a deviation, who confirms it. The rule set is versioned, with a reference document set attached — after an edit, we run it in full and compare against the previous version. Rollback takes minutes, not a rework of the entire process.
Typical implementation mistakes are trying to automate the entire stream in the first release, rules without documented exceptions, and evaluation by average accuracy instead of critical fields. We start with a narrow segment, measure the share of documents closed without a human, and only then expand coverage. Below are the technical concerns we most often work through with client teams.Let's Discuss Your Task and Come Back with an Estimate and Plan
So that the estimate rests on the real scope of work rather than an averaged range, we start with inputs about the corpus: document types (scans, text layers, spreadsheets, email), languages, approximate volume in thousands of pages, and what counts as a correct result — full extraction of deal terms or a sample of risk clauses with source references. The more precise the inputs, the fewer assumptions in the plan and the more realistic the timeline.
On your side, it's enough to provide:
- 15–30 anonymized documents, including atypical and poorly legible instances;
- where the corpus physically resides: file storage, electronic archive, scans from external sources;
- examples of fields and conditions that need to be extracted, with a couple of ground-truth answers;
- how the result is verified today and who acts as the acceptor;
- requirements for the environment: on-premises server, private cloud, or hybrid;
- constraints on access and handling of personal data;
- the desired implementation horizon and what you consider the first useful segment.
In response, we send a breakdown of work by stage, a processing scheme, infrastructure requirements, a timeline estimate, and the acceptance procedure. The tagging format and quality metric are agreed before the start — otherwise the debate about accuracy becomes endless. Describe your task in free form: we'll come back with an estimate and a work plan.
