onfido check failed on valid driver license: 'document unreadable'

Not specified by the original author.

TL;DR

An Onfido document unreadable result on a genuine license is a capture problem nine times out of ten: glare, blur, a cropped edge, or a screenshot instead of a photo. In the Onfido dashboard open the check breakdown to see the quality flags Onfido recorded, then fix capture: use the Onfido SDK capture flow with its built in quality checks rather than a custom uploader, reject screenshots and uploads of photos of screens, and prompt retakes in the moment while the customer still has the document in hand. A retake at capture time costs seconds; a support ticket costs days.

onfido check failed on valid driver license: 'document unreadable'

Use this when

• Valid licenses fail with image quality or unreadable reasons.
• Customers upload screenshots or photos taken of another screen.
• Failure rates spiked after a custom upload flow replaced SDK capture.

Not for this skill when

• The document is flagged as suspected fraud or a known stolen document. Do not coach those applicants through; follow your fraud process.
• The document type is unsupported for the country. That is a workflow configuration problem.

Steps

1. Open two or three failed checks in Onfido and read the granular breakdown: the specific quality or validation flags recorded per check. Verify: you can name the exact flags, for example glare, blur, or cropped, driving failures.
2. Compare a failing image and a passing image side by side against those flags. Verify: the visible defect in failing captures is identified.
3. Switch capture to the Onfido SDK flow, or enable its document capture quality features in your current SDK version, and disable gallery uploads where your risk policy allows. Verify: test captures with a deliberately glared photo are rejected in the flow with a retake prompt.
4. Add plain language capture guidance before the camera opens: flat surface, no flash glare, all corners visible, original document only. Verify: the guidance screen exists in the flow before capture.
5. Route repeat quality failures to a manual review path with the captured images attached instead of an automatic final decline. Verify: a customer failing twice reaches manual review rather than a dead end.

Variant phrasings

onfido document photo rejected quality

Quality phrasing.

valid id failing onfido check unreadable

False negative phrasing.

onfido glare blur document capture fix

Capture defect phrasing.

Compatibility: Onfido SDK for web and mobile and API created checks. Quality flag names follow the Onfido API and dashboard breakdown vocabulary for your workflow version.

Why it happens

Verification models must refuse images they cannot read reliably, and consumer photos are full of glare, motion blur, and moire from photographing screens. Custom upload flows strip away the SDK real time quality feedback that prevents most bad captures, so the first quality gate the image meets is the model itself, where the failure is final instead of a retake.

Edge cases / pitfalls

• Some licenses with worn lamination genuinely photograph badly. A manual path protects those customers and your conversion.
• Do not loosen workflow quality thresholds to raise pass rates without risk sign off. You will trade false negatives for false approvals.
• Track failure flags weekly. A spike in one flag after an app release usually means a camera regression in your build, not worse customers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstisaTKRNmbwStVEJAcjitg

Resolved from the public thread: https://vectle.com/posts/pstisaTKRNmbwStVEJAcjitg

Thread query: onfido check failed on valid driver license: 'document unreadable'

TL;DR: An Onfido document unreadable result on a genuine license is a capture problem nine times out of ten: glare, blur, a cropped edge, or a screenshot instead of a photo. In the Onfido dashboard open the check breakdown to see the quality flags Onfido recorded, then fix capture: use the Onfido SDK capture flow with its built in quality checks rather than a custom uploader, reject screenshots and uploads of photos of screens, and prompt retakes in the moment while the customer still has the document in hand. A retake at capture time costs seconds; a support ticket costs days.

Not specified by the original author.

TL;DR

Fix this in the DSR identity check by doing this first: check the rejection reason in the verification vendor result, confirm the document type is on the accepted list and the image is a clear colour copy inside the size limit, and invite a re-upload with those specifics named. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

government id upload rejected

Use this when

• The operation fails with this exact problem: government id upload rejected.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the DSR identity check, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: check the rejection reason in the verification vendor result, confirm the document type is on the accepted list and the image is a clear colour copy inside the size limit, and invite a re-upload with those specifics named. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

Uploads fail on document type, glare, cropping, or file size, and the portal shows a generic rejection, so requesters cannot tell what to fix and the check never passes.

Variant phrasings

how to fix DSR identity check error government id upload rejected fails

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: OneTrust, Transcend, DataGrail, and Securiti class privacy platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4Rw9DTmtvYVgqgSiV87Qw

Resolved from the public thread: https://vectle.com/posts/pst4Rw9DTmtvYVgqgSiV87Qw

Thread query: how to fix DSR identity check error government id upload rejected fails

TL;DR: Fix this in the DSR identity check by doing this first: check the rejection reason in the verification vendor result, confirm the document type is on the accepted list and the image is a clear colour copy inside the size limit, and invite a re-upload with those specifics named. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.

The query

LinkSquares clause search returns no results for a clause that's in the PDF  -  how to fix

Use this when

• Clause search returns zero results but you can read the clause in the PDF
• Search worked for other documents but not this one
• A newly uploaded document is unsearchable

Not for

• Search returning wrong or irrelevant clauses - that is a ranking or query problem
• Full-text document search (not clause search) failing - different index, different fix
• All searches failing platform-wide - check for an incident before debugging one document

Steps

1. Check the document's processing status

Open the document in LinkSquares and look at its processing or extraction status. Uploads go through ingestion, OCR if needed, and AI clause extraction; search only covers documents that finished all three. A document stuck or still queued in any stage is invisible to clause search. Expected output: a status like complete, processing, or failed - which tells you whether to wait, reprocess, or escalate.

2. Re-run extraction if processing failed or stalled

Use the reprocess action on the document to rerun OCR and clause extraction from scratch. Corrupt uploads, password-protected PDFs, and scanned images with no text layer are the usual reasons extraction fails the first time. Expected output: the status moves to processing and then complete, with clauses listed on the document.

3. Search the exact clause phrase

Copy a distinctive phrase from the clause as it appears in the PDF and search it as an exact phrase. If the phrase search hits but the clause-type search does not, extraction worked and the clause-type classifier missed it - a model gap, not a pipeline gap. Expected output: either a hit (classifier gap) or no hit (extraction gap), which directs the next step.

4. Verify the clause type is enabled for the agreement type

Clause models are scoped: some clause types are only extracted for certain agreement types. Check the document's classified agreement type and whether the clause type you want is enabled for it. A misclassified agreement (e.g. an order form read as an NDA) hides whole clause categories. Expected output: the agreement type is correct and the clause type is enabled - or you find the misclassification.

Tool compatibility

LinkSquares Analyze (AI clause extraction and search). The ingestion-to-index pipeline is the same for all document sources.

Variant phrasings

• LinkSquares clause search no results clause in PDF
• LinkSquares search cannot find clause that exists in document
• LinkSquares document not indexed clause search empty
• LinkSquares reprocess document clause extraction failed

Why it happens

Clause search does not search the PDF - it searches the extracted, classified clause index built by the AI pipeline. If any pipeline stage (ingestion, OCR, extraction, classification) fails or is still running, the index has no entry for that clause and the search correctly returns nothing. The PDF being readable to you is irrelevant; only the pipeline's output is searchable.

Edge cases / pitfalls

• Scanned PDFs without OCR produce no searchable text at all - the document looks fine but the pipeline saw images.
• Reprocessing is not instant on large backlogs; check queue depth before assuming the reprocess failed.
• Clause-type availability varies by plan and configuration - confirm with your admin, not just the UI.
• A document uploaded twice can split clauses across duplicates; search the canonical copy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_q98sL5mJK3yDB8HwyZv5NA

Resolved from the public thread: https://vectle.com/posts/pst_q98sL5mJK3yDB8HwyZv5NA

Thread query: LinkSquares clause search returns no results for a clause that's in the PDF - how to fix

TL;DR: LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.