Not In Good Order results are visible only to the sender and others with edit access to the transaction. Signers never see extracted data, check results, confidence, or tamper findings.
On the transaction page, each file a signer has uploaded shows a status badge under its name, and a Verification result button that opens the results for that file:
Badge | Meaning |
|---|---|
Detected type named, with a check mark | The document was recognised as the type you asked for at high confidence, and no check has reported a warning or failure |
Detected type named, with a warning, flagged for review | A type was detected (or shows as unknown), but either it was not reported as a match — see the mismatch callout below — or at least one check reported a warning or failure |
Type not identified, with a warning, flagged for review | Classification produced no type at all: the file had a quality problem, or the file was never validated (see below) |
Reviewed | You have marked the file as reviewed. This replaces the other badges |
The Verification result dialog shows, for the file:
A summary of the checks. Any file problem is listed first as a failure. Then a document type line, reported as a match or a mismatch alongside the type that was detected. Then one line per content check, marked as passed, warning or failed, in plain language — for example, the expiry date that was found and has passed. Passing lines are collapsed by default.
The extracted data, as a list of field names and values — dates in your locale's format and country codes as country names — or a message that no extracted data is available.
A preview of the file, and the Mark as reviewed button (see Mark as Reviewed).
Extraction runs after the upload and takes a little longer than classification. Until it completes, the dialog reports no extracted data.
When the detected type doesn't match what you asked for
Nothing is blocked. The upload stands and the attachment requirement remains satisfied.
On the transaction page the file is flagged for review. In the results dialog the document type line reads as a mismatch, alongside the type that was actually detected, so you can see what the signer sent instead. Extraction is skipped for that file.
The signer sees a single message on their upload indicating the document does not appear to be what was requested. They are not prevented from continuing, are not asked to re-upload, and receive no email or notification.
Two different things read as "mismatch". A genuinely wrong document — the detected type is not the one you requested — and the right document detected at medium or low confidence, where the detected type is the one you requested but a match is only reported at high confidence. Neither case is extracted or checked: extraction is only performed on a high-confidence classification, so in both cases the dialog shows no extracted fields. The badge and the document-type line name the detected type but never show the confidence, so the badge alone does not tell you which case you are in. Compare the named type with what you requested: the same type reported as a mismatch means low confidence — the signer very likely sent the right document, and a clearer copy may let it be recognised; a different type means the wrong document.
When a document can't be classified
Three distinct situations, all non-blocking:
The document type could not be determined. The file was readable but did not match any supported type. The file is flagged for review with its type shown as unknown, and extraction is skipped.
The file had a quality problem. The file was rejected before classification could be attempted — for example it was too blurry, too dark or too low-resolution, had glare, was corrupted, was too large or too small, or was an unsupported format. Validation accepts PDF, Word, JPEG, PNG, TIFF, BMP and GIF files between 1 KB and 10 MB, and images of at least 200 × 200 px. The specific problem appears as the first line of the results summary, and extraction is skipped. This is the one situation where the signer also sees a message describing the actual problem with their file, which they may act on by uploading a better copy.
The validation service was unavailable. No result is recorded for the file at all. On the transaction page it is flagged as type not identified; its results dialog reports that there is no result, and does not offer Mark as reviewed. The upload itself is unaffected, but validation will not run for the file later; if you need it validated, ask the signer to replace it.
Verification checks
Verification checks run over extracted field values, so they require Verify document to be on and extraction to have succeeded. Each check reports Pass, Warning or Fail, and names the fields it looked at.
Check | What it does | Outcomes |
|---|---|---|
Data completeness | Confirms the fields that matter for this document type were found and are not blank | Pass — all present. Fail — one or more missing, and the missing field names are listed |
Expiry | Confirms a document that carries an expiry date has not passed it | Pass — not expired. Fail — expired. Warning — the date was absent or could not be read |
Recency | Confirms a dated document is recent enough to be useful | Pass — within the window. Fail — older than the window. Warning — the date was absent or could not be read |
Coverage period | For insurance documents, confirms today falls inside the policy's coverage window | Pass — in force. Fail — coverage has ended. Warning — coverage has not started yet, or a date was absent or unreadable |
Tax year recency | For T4 slips, confirms the tax year is recent enough | Pass — within range. Fail — too many years behind. Warning — the year was absent, non-numeric, or implausible |
A missing or unreadable date produces a Warning, never a Fail. Only a date that was successfully read and found to be out of range produces a Fail.