Software & AI · Procurement & compliance · Written and maintained by Haink’s AI adoption team · Updated August 2026 · 14 min read
Due diligence document review: the deal and the treadmill
What this page argues
- “Due diligence” names two unrelated processes. One happens a few times a year and tolerates a lawyer reading everything. The other happens hundreds of times a year on the same document pack and does not.
- Only the second one is an automation problem. Automating deal review mostly buys a faster read of something that was already proportionate to spend.
- Screening is entity resolution, not document reading. The hard parts are name normalisation, ownership chains and the fact that lists change under you.
- The error costs are asymmetric, so the correct design clears the easy majority automatically and routes everything ambiguous to a person — accepting false positives on purpose.
- Export control is a third thing again. It asks who the end user is and what the item is for, not only who the counterparty is, and the price of being wrong is a licence rather than a debt.
Search for AI in due diligence and every result assumes a transaction: a data room, a target company, a legal team reading contracts against a deadline. That is one real process. It is not the one that most people asking the question actually have.
The other one has no data room and no deadline. It is a procurement or compliance team checking counterparties — the same handful of documents, over and over, several times a week, forever. Both are called due diligence. They have almost nothing else in common, and conflating them is why so many of these projects are scoped against the wrong economics.
Two processes, one word
| Deal due diligence | Continuous counterparty screening | |
|---|---|---|
| How often | A few times a year | Hundreds to thousands of times a year |
| Document set | Unique to the target, unpredictable, large | Largely the same pack every time |
| Who does it | Lawyers and advisers, billed by the hour | Procurement and compliance staff, salaried |
| Depth | Deep. Reading for meaning and risk | Shallow but exhaustive. Checking presence, validity, identity |
| Time pressure | A deadline, once | Continuous, and often on the critical path of a shipment |
| Tolerates manual work? | Yes — cost is proportionate to deal value | No — cost scales with counterparty count |
| Automation verdict | Assists a specialist. Modest return. | Replaces a queue. This is where the money is. |
The row that decides everything is the last but one. A deal team spending eighty hours on a document set attached to a large transaction is not obviously wasting money. A procurement team spending forty minutes per counterparty, four hundred times a year, is spending a third of a person on work that is almost entirely mechanical — and that number grows with the supplier base while the budget does not.
What is actually being checked
Strip the vocabulary away and a counterparty pack is checked on four axes. They are not equally automatable and they are not equally risky.
| Check | What it asks | Nature |
|---|---|---|
| Completeness | Is every required document present, in date, and signed? | Mechanical. Fully automatable, and where most of the elapsed time is lost. |
| Cross-document consistency | Do the name, address, registration number and ownership agree across the pack? | Mechanical with a language edge — the same entity written three ways. |
| Conformity | Does each document meet the form the policy or regulator requires? | Rules, where the rule is written down. Model only for reading. |
| Entity screening | Do these parties, owners and end users appear on any restricted list? | A different problem entirely — see below. |
Three of the four are document work: read, extract, compare, flag. The fourth is not document work at all, and treating it as though it were is the most common design error in this area.
There is a second split running underneath, and it is the one that decides the architecture. The reference standard here is double. For the documents it is the requirements of the procurement or the deal — which pack is mandatory, in what form, valid for how long. For the parties it is the current lists. The first changes from deal to deal and is set by you; the second changes on its own, without anyone telling you, and is set by someone else. Those are different engineering problems: one needs configuration per counterparty type, the other needs ingestion, versioning and change detection against a moving external source.
Screening is entity resolution, not reading
Extracting a company name from a certificate is the easy part and almost never the failure. The failures are elsewhere.
- Name normalisation. The same entity appears as a transliteration, an abbreviation, a trading name and a legal name with a different corporate suffix. Matching on strings alone produces both misses and noise; matching on registration identifiers works where they exist and often they do not.
- Ownership chains. The counterparty is clean and its majority owner is not. Depending on the regime, control thresholds pull the subsidiary into scope — so the check is not against the party in front of you but against a graph you have to reconstruct.
- The lists move. This is the property that breaks manual process altogether. A counterparty cleared in March is not cleared in September, and nobody re-reads four hundred files by hand. Continuous re-screening against list deltas is the single capability that separates a real system from a faster manual one.
- Ambiguity is the normal case, not the exception. A common surname, a shared address, a partial match on a name fragment. The system's job is to surface these, not to resolve them.
None of that is a language-model problem. It is normalisation, graph traversal, list ingestion and change detection — deterministic engineering, with a model helping only at the edges where documents have to be read to find the parties in the first place.
Export control screening: the third class
This is a different class of check from everything above, so it is worth being precise about why.
Ordinary counterparty screening asks who is this party. Export control asks three further questions that no amount of party data answers: who is the actual end user, what will the item be used for, and is this destination permitted for this specific item. The last one matters most and is the one people miss: the answer changes with the item's classification, not only with the buyer. A transaction that is unremarkable for one product is prohibited for another with the same customer, the same country and the same paperwork.
The consequences also differ in kind. A missed credit risk costs money. A missed export control issue costs a licence, and potentially attracts criminal exposure — which is why this class of check is not a candidate for straight-through automation at the decision point, however good the extraction gets. What automates is the assembly: pulling the parties and the end user out of the pack, normalising them, matching against the OFAC SDN list, the BIS Entity List, Denied Persons and Unverified lists, checking the item's classification against the destination, and putting a complete file in front of the person who signs.
The regulatory substance — what the EAR covers, how end-user certificates work, what the red flags are — is set out separately in export controls and dual-use IT hardware. This page is about the shape of the work rather than the content of the rules.
The threshold at which continuous screening pays back
Computed rather than asserted. Assumptions: fully loaded cost of $50 per hour, forty minutes to complete a counterparty check manually, six minutes of residual human time on an automated one, and a build at $150,000.
| Counterparty checks per year | Annual hours now | Annual saving | Payback |
|---|---|---|---|
| 100 | 67 | $2,800 | Does not close |
| 400 | 267 | $11,300 | 13 years — no |
| 2,000 | 1,333 | $56,700 | 2.6 years |
| 10,000 | 6,667 | $283,000 | 6.4 months |
Read honestly, that table says something most vendors in this space would rather not put in writing: on labour savings alone, counterparty screening does not pay back below a few thousand checks a year. If your volume is in the hundreds, a custom build is the wrong purchase, and either a commercial screening service or an improved manual process is the right one. We would rather say that than sell into it.
What changes the arithmetic is not volume but consequence. Where a screening step sits on the critical path of a shipment, the relevant cost is not the analyst's forty minutes — it is the delay to the shipment. And where an error carries a licence rather than an invoice, the expected cost of a miss can dominate every other term in the equation. Both belong in the calculation, and neither is a labour saving.
Error asymmetry, and what follows from it
Every screening system has two ways to be wrong and they cost wildly different amounts.
The ratio between those two is not two to one or ten to one; it can be five or six orders of magnitude. Any threshold tuned to balance the two error types is therefore tuned wrongly. The correct posture is deliberately over-sensitive: flag generously, accept a false-positive rate that would be unacceptable in almost any other application, and staff the review queue accordingly.
Two design consequences follow, and they are the opposite of what a demo optimised for accuracy will show you:
- Do not report a single accuracy number. Report the false-negative rate and the queue volume separately. They are the two things anyone responsible for this actually needs.
- Do not let the model set the threshold. Confidence calibration drifts with retraining. The threshold is a policy decision with a named owner, written down before the system exists.
Lists and documents are two different problems
The generic version of this section — “use rules where you can, models where you must” — is true everywhere and therefore useful nowhere. In screening the split is sharper than that, and it is sharp for a structural reason rather than a stylistic one.
Matching an entity against a list is deterministic by construction. The inputs are fully enumerable: the entity as normalised, the list, and the version of that list as of a given date. Given those three, the answer is fixed and always will be. There is nothing to infer, and a model inserted here is strictly worse — slower, less complete, and unable to explain itself when someone asks why a party cleared in March did not clear in September.
Interpreting a document is not. Whether this certificate is the one the policy requires, whether the entity on page four is the entity on page one, whether a scanned annex is legible enough to rely on — none of that has an enumerable input set. It is judgement, and judgement is where a model belongs.
| Lists | Documents | |
|---|---|---|
| Nature | Deterministic by construction | Interpretation |
| Automates | Completely | Partially |
| What it demands | List ingestion, version pinning, delta detection — the version as of the decision date must be recoverable | A human at the boundary, and evidence of what they were shown |
| Fails when | The list version was not recorded, so a past decision cannot be re-derived | The boundary was never defined, so the model decided something nobody meant it to |
Two consequences that do not follow from the generic version of the advice. First, versioning the list is not housekeeping, it is the audit trail — a screening decision without the list version attached is unreconstructable no matter how good the rest of the logging is. Second, the human does not sit “in the loop” in some general sense; they sit at exactly one place, the boundary where document interpretation stops being enumerable. Everywhere else they are cost without benefit.
And where that boundary is drawn is not a matter of taste. It follows from the error asymmetry above: missing a listed party costs a licence, re-checking a clean one costs minutes. Thresholds get set from that ratio, not from a general accuracy target — which is why a screening system tuned to maximise overall accuracy is tuned wrongly, and why the two numbers worth reporting are the false-negative rate and the queue volume rather than a single score.
Models still earn their place, in three narrow spots: reading unstructured or scanned documents to find the parties, judging that two differently written names denote one entity, and ranking which files a reviewer should open first. That division is reached from the capture side in document data capture methods, and from the autonomy side in agents in repeatable processes.
Why these projects fail
No counterparty register. If the list of who you deal with lives in three spreadsheets and an ERP with duplicate records, screening has no subject. Fix that first; it is not an AI project and it is the prerequisite for this one.
Screening treated as a one-time event. A system that checks at onboarding and never again gives false comfort, because the lists move. Re-screening on list changes is the requirement, not a feature.
A pilot on the easy counterparties. Large, well-documented suppliers screen cleanly. The cost lives in the small, oddly documented, foreign-registered ones — and if they were not in the pilot, the pilot measured nothing. The general pattern is in why AI pilots fail.
A single accuracy target. See the asymmetry above. A project with one accuracy number in its acceptance criteria has not understood what it is building.
Frequently asked questions
What is the difference between deal due diligence and counterparty screening?
Frequency, and everything that follows from it. Deal due diligence happens a handful of times a year, goes deep into a unique document set and is done by lawyers who are paid to read everything — manual review is expensive but proportionate. Continuous counterparty screening runs hundreds or thousands of times a year over a largely identical document pack, is done by procurement or compliance, and does not survive being manual. They share a name and almost nothing else, which is why automating them are two different projects.
How does sanctions screening automation actually work?
It is entity resolution against lists, not document reading. The system extracts the parties, their owners and the end user from the document pack, normalises names across transliterations and corporate forms, and matches them against the relevant lists — the OFAC SDN list, the BIS Entity List, Denied Persons and Unverified lists, and any regional equivalents. The hard parts are name normalisation, ownership chains that reach a listed party indirectly, and the fact that the lists change, so a counterparty cleared last quarter is not cleared today.
What makes export control screening different from ordinary KYC?
Three things it also has to establish: who the end user really is, what the item will be used for, and whether the destination is permitted for that item. KYC asks whether a person is who they claim to be. Export control asks whether this specific item may lawfully reach this specific user for this specific purpose — and the answer can change with the item, not only with the party. The cost of being wrong is a licence and a criminal exposure rather than a bad debt.
Can counterparty screening be fully automated?
The clearing can be; the flagging cannot. A system can and should clear the large majority of checks automatically, because most counterparties are unambiguous. What it should not do is decide the ambiguous ones. The error costs are asymmetric — missing a listed party is a regulatory event, while re-checking a clean one costs a few minutes — so the sensible design routes anything uncertain to a person and accepts a high false-positive rate as the price of that asymmetry.
Which parts of due diligence review should be rules rather than models?
List matching, completeness against a required document set, date and validity checks, and cross-document agreement on names, addresses and registration numbers — all deterministic, and better so, because the result must be reproducible and explainable to a regulator months later. Models earn their place on reading unstructured documents, on resolving that two differently written names refer to one entity, and on ranking which files a human should look at first.
How long does counterparty due diligence take?
Manually, most of the elapsed time is not review, it is waiting — for a missing certificate, an updated registry extract, an answer from the counterparty. That is why automating the completeness check moves the number far more than automating the assessment does: the assessment was never the bottleneck. Where a screening step sits on the critical path of a shipment, elapsed time is the whole cost.
This page describes how a class of system is built and where its economics sit. It is not legal or compliance advice, and nothing here substitutes for your own counsel on export control or sanctions obligations.
Related Resources
- Supplier Due Diligence Automation — what we build for the continuous side, and what we refuse to build
- Export Controls and Dual-Use IT Hardware — BIS, OFAC, EAR and end-user certificates in substance
- Agentic Document Processing and Auditability
- Document Data Capture Methods: Which to Choose
- AI for KYC and Identity Verification
- Intelligent Document Processing services
The treadmill is the automatable half
Completeness, cross-document agreement, entity normalisation and re-screening on list changes — with a person kept exactly where the error asymmetry says they belong.
On the numbers. The payback table is arithmetic from the stated assumptions, not a benchmark: annual hours × loaded rate, against a $150,000 build. Substitute your own figures. Screening list names are as published by the issuing authorities — the OFAC SDN list and the BIS lists of parties of concern.
Reviewed: August 2026.