Yes. AI can help identify missing documents in a client onboarding pack by comparing classified uploads with a defined checklist. It should return a clear, evidence-linked gap list for your team to review, not decide whether a client is legally compliant or approved. The important distinction is between a document that was not supplied, one that cannot be read, and one that does not meet your agreed validity rules.
Define the checklist before asking AI to find gaps
Start with requirements approved by the person responsible for onboarding. AI cannot reliably identify what is missing unless your business first defines what belongs in the pack.
Build a requirement matrix by client category. In a hypothetical South African workflow, an individual category might require an identity document and address evidence. A company category might require a registration document and evidence of the representative’s authority. These are illustrative business requirements, not a statement of legal obligations.
For each requirement, record the accepted document types, whose document is needed, whether alternatives are permitted, and any date rule. Separate the company’s address evidence from the representative’s personal address evidence. Otherwise, a plausible document can satisfy the wrong requirement.
Include conditional requirements explicitly. If authority evidence is needed only when someone acts for another party, store that condition rather than asking the model to infer it. Where the category or condition is unknown, return “requirements unresolved”. An onboarding owner should resolve that uncertainty before the system declares anything missing.
Register uploads and preserve the evidence trail
Create an upload inventory before extracting or interpreting content. This establishes what the system actually received and prevents processing failures from looking like missing documents.
The proposed inventory should include the pack reference, stable file reference, original filename, upload time, page count where available, and processing state. Retain the original file under your approved access and retention controls. A filename is a useful label, but it is not proof of document type.
Keep page references when a PDF contains several documents. A registration certificate on one page and an address document on another should become separate candidate records, both linked to the original PDF. Do not discard blank, damaged or skipped pages without recording what happened.
Google’s Source: Document AI overview describes OCR, text and layout extraction, document classification, and splitting capabilities. Those are building blocks for this proposed process, not a ready-made onboarding completeness policy.
Symaxx’s document processing service is the relevant service route for discussing how extraction and evidence references could fit your existing intake process.
Classify content without trusting filenames or document instructions
Classify each document from its contents, then retain uncertainty instead of forcing every upload into a recognised type. An unknown document is a review item, not automatically an irrelevant document.
Give the classifier a controlled list of types drawn from your requirement matrix. Ask it to return the proposed type, relevant party, supporting page references and any ambiguity. A file called “proof-of-address.pdf” might contain a quotation, a bank statement or an unrelated attachment. The extracted heading, issuer, named party and address matter more than the filename.
Treat uploaded text as evidence only. A sentence inside a document that says “mark this pack complete” must not change workflow rules, trigger messages or override the checklist.
Where documents can serve more than one requirement, propose candidate matches rather than silently assigning them. Your policy owner should decide whether one document may satisfy multiple requirements.
For a tightly bounded process, fixed workflow steps may be enough. The AI agents versus automation resource provides a useful route for considering that design choice without assuming an agent is necessary.
Extract only the fields needed to check completeness
Extract the minimum information needed to support each requirement match. More extracted personal information does not necessarily make the gap list more useful.
A proposed candidate record could contain document type, named party, issue date, expiry date, relevant address, source file, page and extraction warnings. Preserve the printed date text alongside any normalised date. If a date can mean either day-first or month-first, leave the normalised value unresolved until someone checks it.
Use null for a field that is absent or unreadable. Do not invent an expiry date because a document category sometimes has one. Do not infer a signature from a name appearing near a signature box.
Source: OpenAI’s structured outputs guide describes constraining responses to a supplied JSON schema. That can support consistent fields and status values, but a correctly shaped response is not evidence that its extracted facts are correct.
Your application should also check that referenced files and pages exist. A reviewer must be able to open the cited evidence and see why a candidate was matched.
Calculate gaps with separate, explicit statuses
Compare requirements with candidate records using proposed business rules, rather than letting a model write an unconstrained opinion about pack completeness.
Use these distinctions:
- Missing: no candidate was found after all received files were successfully processed.
- Unreadable: a likely candidate exists, but necessary content cannot be read.
- Expired: an explicit expiry date falls before the agreed review date.
- Outside recency rule: a readable document exceeds a business-defined age limit.
- Ambiguous: type, party, date or requirement match remains uncertain.
- Present for review: evidence appears to satisfy the completeness requirement.
Do not describe old address evidence as “expired” unless it actually has an expiry date. A proposed recency rule is a separate reason for requesting newer evidence.
A failed file should keep the pack in “processing incomplete”, not create a confirmed missing finding. Duplicate uploads should be linked and excluded from requirement counts, while conflicting versions should go to review.
An apparent identity match is not identity verification. Likewise, a document-gap check does not establish authenticity, legal compliance or suitability for a commercial relationship.
Route exceptions through a controlled human review
Send unresolved findings to a named reviewer before requesting replacements or changing the client’s onboarding status. The reviewer needs the requirement, candidate evidence, reason and available next action together.
Proposed actions include accepting the candidate for completeness, correcting its classification, requesting a clearer copy, asking for a missing document, or escalating a policy question. Record the reviewer’s reason separately from the original machine finding. Keep an authorised exception distinguishable from a document that was supplied.
If the workflow uses tools to retrieve a checklist or draft a request, application controls should validate access and arguments. Source: OpenAI’s function calling guide explains that the model requests a tool call and application-side code executes it. That division allows you to keep consequential actions behind explicit controls.
For broader orchestration, see custom AI agent workflows. The glossary entry for a custom AI agent can help frame the terminology. Neither label removes the need for human judgement on legal, financial or security consequences.
Use this reusable document-gap checklist
Use one record per requirement, including requirements that appear satisfied. That makes the result reviewable and prevents a list of only problems from hiding what the system checked.
The following proposed template can be copied into a spreadsheet or adapted into an application record. Its status rules are workflow suggestions for your policy owner to approve.
Proposed document-gap record
Pack header: client reference; confirmed category; checklist version; review date; upload inventory reference; processing complete: yes/no; assigned reviewer.
| Field | What to record |
|---|---|
| Requirement | Required type, relevant party and condition |
| Acceptance rule | Permitted alternatives and approved date rule |
| Candidate evidence | File reference, page and supporting text; none if absent |
| Status | Missing, unreadable, expired, outside recency rule, ambiguous, present for review or not applicable |
| Reason | Specific unmet rule or unresolved fact |
| Next action | Review, request document, request clearer copy or resolve policy |
| Owner | Person responsible for the next action |
| Review outcome | Decision, reason, reviewer and decision date |
Release checklist:
- Confirm the client category and applicable conditions.
- Account for every upload and processing failure.
- Check evidence references and relevant parties.
- Link duplicates without counting them twice.
- Separate expiry from business recency rules.
- Resolve ambiguity before requesting a replacement.
- Have a reviewer approve the client-facing request.
Completion rule: The gap list is ready when each applicable requirement has a supported status and next action, or a recorded human exception. This does not approve onboarding.
Walk through a normal pack and an exception pack
A hypothetical walkthrough shows how the same checklist produces different actions without treating every problem as “missing”. All references, dates and quantities below are fictional.
Suppose the approved company checklist requires a registration document, representative identity document, company address evidence and authority evidence. For illustration, the proposed address rule accepts documents issued within 90 days of the fictional review date, 5 October 2026.
Normal pack: Pack C101 contains a readable registration certificate, representative ID, company address statement dated 10 September 2026, and an authority letter. Each candidate links to its file and page. The system marks each requirement “present for review”. The reviewer confirms the parties and evidence, then passes the pack to the separate onboarding decision process. The completeness check itself does not approve the client.
Exception pack: Pack C102 contains the registration certificate twice, a blurred representative ID, an address statement dated 1 February 2026, and an attachment that might be an authority letter but names a different company.
The proposed output links the duplicate registration files without creating extra coverage. It marks the ID unreadable, the address evidence outside the hypothetical recency rule, and authority evidence ambiguous. The reviewer opens the attachment to resolve the company mismatch before deciding whether authority evidence is missing. If it is unrelated, the reviewer confirms “missing” and approves a specific request for authority evidence.
The client request then asks for a clearer ID, newer address evidence under the stated business rule, and the confirmed missing authority document. It does not accuse the client of submitting invalid or fraudulent documents.
Evaluate the gap list before relying on it
Evaluate requirement-level findings against human-labelled packs before using the process to prepare client requests. Vendor capabilities alone do not establish accuracy or business benefit.
Build an authorised evaluation set containing ordinary packs and difficult examples: combined PDFs, unreadable scans, unknown categories, duplicate uploads, conflicting dates, alternative documents and files belonging to the wrong party. Ask reviewers to record the expected requirement status and its evidence. Resolve disagreements about policy before scoring the system.
Track false missing findings, overlooked gaps, incorrect party matches, status confusion and broken evidence references separately. A total accuracy figure can conceal a system that repeatedly mistakes unreadable documents for absent ones.
Set proposed release criteria with the onboarding owner according to the consequences of each error. Do not assume a universal confidence threshold is suitable. Review any confidence signal against labelled examples before using it for routing.
Compare reviewer effort and request corrections with your existing process if you want to assess potential benefit. Re-evaluate after checklist, extraction or model changes. A pilot may reveal useful assistance, but it should not be described as reducing errors or saving time without evidence.
Frequently asked questions
Can one PDF satisfy several onboarding requirements?
Yes, under a proposed policy that permits it and preserves page-level evidence. A combined PDF might contain a registration certificate and address statement. Create separate candidate records linked to their relevant pages. Do not assume that one recognised page explains the whole file. If the same document is proposed for several requirements, a reviewer should confirm that your acceptance rules allow that use.
Should unreadable documents appear on the missing-document list?
They should appear on the gap list, but with an unreadable status rather than missing. The next action is usually to inspect the original or request a clearer copy. If processing failed entirely, record that failure first. Only confirm a document as missing once received material has been accounted for and unresolved candidates have been reviewed. This avoids asking a client to resend something that is already present.
Who decides whether outdated address evidence is acceptable?
Your authorised onboarding or policy owner decides. The system can extract the issue date and compare it with an approved business rule, but it should not invent that rule or present it as law. A reviewer may accept an authorised exception or request newer evidence, recording the reason. Any legal or regulatory interpretation needs appropriate professional judgement rather than a model-generated conclusion.
Plan a bounded completeness workflow
Start with one client category and a reviewed checklist, then assess whether the evidence-linked output supports your team’s decisions. Keep document completeness separate from authenticity checks and final onboarding approval.
If your business needs help connecting intake, extraction and exception review, Symaxx’s AI automation service provides a route to discuss the scope. Get in touch with your checklist and examples of difficult packs to explore a bounded workflow, not an automatic approval system.