Reviewing uploads
Every upload is read and checked before it reaches you. The verdict is advice — you're still the one who accepts it.
What the check does
When a file lands, Claude reads the document itself — PDFs and images directly, no separate scanning step — and answers four questions:
| Check | The question it answers |
|---|---|
| Type | Is this actually the document you asked for, or a payslip where a bank statement should be? |
| Period | Does it cover the dates you need, or is it last year's? Needs a period to check against — see below. |
| Readable | Can it be read at all — or is it a blurred, cropped, glare-covered photo? |
| Complete | Is anything obviously missing, like page 3 of 4? |
Your item's own label and description are always part of the check — whether or not you picked a named document type. They're the most specific thing ChaseDocs has about what you wanted, so an upload is never marked wrong just for being a document ChaseDocs has no name for, and a period you wrote into the item name is a period the check knows to enforce.
Each file comes back as pass, warn or fail, with a plain-language list of anything wrong, plus a suggested filename so you're not renaming downloads by hand.
"Period — not checked"
The period check can only run against a period you've stated. If nothing on the request names one, that check comes back not checked in grey rather than a green tick — the AI won't vouch for a period nobody specified.
To turn it on, put the period where the check can see it:
- In the item name — "Bank statement — Apr to Jun 2026" is enough on its own.
- In the item's description — "All pages covering January to March".
- As the request's date range, which applies to every item on it.
A grey not checked is not a problem with the document. It means one fewer thing was verified for you, so that item is worth your own eyes before you accept it.
Expiry dates
For documents with a validity window — a passport, most obviously — the expiry date is read off the page and checked against the dates on the request. A passport that expires two weeks after the return flight gets flagged before it becomes an airport problem. This check is on every plan, including Solo.
It needs a date to measure against. On a request with no date range, the expiry check shows as not checked rather than quietly disappearing — so a passport that was never measured never looks like one that passed. Set the request's dates and it runs.
Long PDFs
On a long PDF — an audited financial report, a full year of statements — the check reads the first three pages rather than the whole file. Those pages settle the type, the period and whether the scan is legible, which is what the check is for; reading eighty more pages would cost far more and answer the same three questions.
The one check this narrows is Complete. On a truncated read it means "these pages are intact and legible", not "nothing is missing from the document" — the later pages weren't read, so nothing is claimed about them. You'll see the page range under the verdict, like "Checked the first 3 pages of 81", so it's clear what the verdict covers. Short documents are read in full and carry no such note.
When the check can't run
Occasionally a document defeats the check — a file that's far too large, a PDF that won't open, a hiccup on our side. That comes back as a warn saying so, never as silence: an upload with no verdict at all would be indistinguishable from one the AI had cleared. Treat it as a document to review yourself, and accept or ask again as normal.
The AI never decides
The verdict is advisory. Nothing is accepted, rejected, or sent back to your client automatically. It exists to tell you which files need your eyes and which are routine, so a stack of twelve uploads becomes two you actually inspect.
Treat a warn as "look at this one", not as a rejection. Models misjudge unusual documents, and you know your client's paperwork better than it does.
Accepting, or asking again
Two buttons on each item:
- Accept — the line is closed. Your client sees it as accepted and there's nothing more for them to do. Once every required item is accepted, the request completes on its own — reminders stop and it releases its slot against your plan cap. Nothing to close by hand.
- Ask again — the line reopens with your note attached. Your client sees "Needs update" in red on the same link they already have, with your note explaining what to fix. No message goes out at this point — see below.
Write the note as an instruction, not a verdict. "Needs the page showing the closing balance" gets the right file back. "Rejected — incomplete" gets you a reply asking what's wrong.
Optional items don't hold a request open if your client skips them — that's what optional means. But one they did upload still needs your decision: an item waiting on review keeps the request open whether it was required or not, so nothing gets closed out from under a document you haven't looked at. And if you undo an accept on a finished request, it reopens and takes its slot back.
The note carries further than the portal: it's the text your client receives, so write it for them rather than for your own records.
Telling your client, once
Work through the whole request first. As soon as you send anything back, a bar appears above the checklist — "3 items sent back — the client has not been told yet" — with a Tell the client button. Press it when you've finished reviewing, and one message goes out on the request's usual channel naming what was sent back, quoting your note, with the link to upload replacements.
Being told is the one review outcome a client can't discover on their own — they uploaded, closed the page, and as far as they know they're finished. But one message, not fifteen: a message per rejected item would flood a client who owes you a long list, and a burst of identical messages is exactly what gets a WhatsApp sender number rated down and an email domain marked as spam. That number and domain are shared by every firm on ChaseDocs.
- One message covers everything. Send fifteen items back — one at a time or with Reject all — and your client gets a single message.
- Pressing it twice doesn't message twice. Only items sent back since the last message count, so a second press sends nothing.
- There's a short wait between notices. If you send more items back a few minutes after telling them, the button counts down before it can be pressed again. Nothing is lost — those items stay in the bar until they've been included in a message.
- Accepting sends nothing. There's no "we got it" message — the portal already shows that, and reminders stop on their own when the request is complete.
- Consent still applies. If the client hasn't consented to messages, or has no contact details, the rejection is still recorded — you're told the message didn't go, so you can reach them another way.
Asking again is cheap; guessing isn't. Clients re-upload from the same link in seconds. Accepting a marginal document to avoid an awkward message is how bad files end up in your files.
What we do with the file while checking it
The check runs on a temporary copy held in memory only, for as long as the pass takes, and then it's gone. We store the verdict — the four checks, the issues, the suggested name — and never the document's contents. Nothing from inside your clients' documents is logged.
Full detail in Storage and security.
Still stuck? Email support@usechasedocs.com and a human will answer.
ChaseDocs