Getting AI to Read Your Documents
What actually happens with PDFs, spreadsheets, and long reports
① "Reading a document" isn't skimming like a person does — it's converting the whole thing into tokens and pushing it into the input at once. So results vary enormously with the document's shape: text or scan, table-heavy or not.
② The two most common failures are missing content in the middle of a long document and table structure breaking apart. Both are avoidable once you know why they happen.
③ A number pulled from a document isn't automatically safe. Whether you read it off a table or asked in conversation, it's still a product of prediction — that fact doesn't change.
① "Read this" quietly covers two very different situations
Upload a PDF and say "read this" and it looks like one request. In practice, what happens depends entirely on what kind of document it is.
A text PDF (converted straight from Word or a similar app, where you can select and drag characters) already carries character data — that text gets pulled out, split into tokens, and pushed into the input as-is. A scanned PDF (a photographed or scanned page, where text can't be selected) is an image from the start. Reading it requires a separate step, OCR (optical character recognition), to convert the image's characters into text.
For a scanned PDF, OCR accuracy becomes the ceiling on final quality. Tables, handwriting, faint print, or a skewed scan all get misread. That error carries straight into every later step, and the model continues treating the misread character as though it were correct. When output looks off, the first thing to check is whether the source was a text PDF or a scan.
For what it's worth, in newer models this OCR step usually isn't a fully separate program anymore — it's folded into the multimodal pipeline that converts images into coordinates directly. That integration doesn't reduce errors on a low-quality scan, though — the caution above still applies.
② The longer the document, the hazier the middle
This is exactly "axis 1" from our AI tools comparison. No matter how large the context window is, the beginning and end of a document tend to be remembered well while the middle gets lost — a pattern that shows up consistently across models. It's often called "lost in the middle."
Why does this happen? Attention lets every token reference every other token in principle, but the training data contains relatively few cases that demand precisely referencing a truly long document start to finish. So the learned bias toward "important content is probably near here" skews toward the start and end.
| Position in document | Accuracy tendency | Practical implication |
|---|---|---|
| Opening | High | Documents that front-load a summary or table of contents fare better |
| Middle | Tends to drop | Detailed clauses, footnotes, appendices here risk getting skipped |
| Closing | Comparatively high | Conclusions and signature blocks tend to be caught reliably |
There's a direct test: plant one distinctive sentence in the middle of a long document ("if you find this, respond 'checkpoint'") and ask about it. If it's missed, reliability at that length is in question, and for anything that actually matters, splitting the document and feeding it in pieces is the safer route.
① For long documents, summarize section by section and combine at the end.
② For a clause that really matters, ask by specifying its location — "quote the third clause on page N" — rather than a blanket search. Accuracy is noticeably higher.
③ After summarizing, add the constraint "don't include anything not stated in this document" to reduce hallucination.
③ Why tables break
Documents with tables deserve extra caution. To a person, rows and columns are obviously distinct; but the moment a table gets extracted as text, the structural information (which cell belongs in which row) is easy to lose. Inside a PDF, a table is really just a list of "this character at this coordinate, that character at that coordinate" — nothing marks it as "this is a table."
| Breakage pattern | Why it happens |
|---|---|
| Merged cells | The merge information vanishes and only text remains, shifting columns |
| A table spanning pages | Headers repeat or split as the page turns |
| Wide tables | Column order can get rearranged out of reading order |
| A table inserted as an image | Has to go through OCR, so errors compound |
If a table matters, capturing just that table and asking separately — "transcribe this table into markdown, and check it against the original cell by cell" — is more accurate than feeding the whole document at once. Focusing on one table also shrinks the range you have to verify.
For documents where comparison tables are the whole point — expense ratios, tracking error, volume, as in an ETF prospectus — verifying each table this way matters even more. See our ETF primer for what those comparison criteria actually are.
④ Working with spreadsheets and financial statements — the rule doesn't change
Feed in a spreadsheet or a financial statement and ask "summarize the revenue trend," and you get a clean-looking table back. But the fact that it wasn't computed by a calculator hasn't changed. As covered in why AI gets numbers wrong, the model predicts numbers the same way it predicts anything else — reading them off a table doesn't alter that structure.
Document handling adds one more risk on top. If the table collapse from §3 happens inside a financial statement, you can end up with "revenue" and "operating income" columns shifted against each other, attaching the wrong label to the wrong number. The digits themselves were really in the document — it's which line item they belong to that goes wrong.
Summarizing a quarterly earnings PDF with AI and using it for investment decisions is increasingly common. It's convenient, but the real danger is that a collapsed table gets summarized without anyone noticing it's wrong. Core figures — revenue, income, margin — should be checked against the original table by eye, not the summary. For verified figures, work from grounded material like our Big Tech earnings guide.
⑤ A practical workflow — checklist by document type
| Document type | Before uploading | How to verify results |
|---|---|---|
| Text PDF, short | Upload as-is | Standard review is enough |
| Scanned PDF | Check scan quality — rescan if blurry | Compare a few paragraphs against the original directly |
| Long document (dozens of pages) | Split by section before feeding in | Test by asking it to quote a specific mid-document clause |
| Table-heavy document | Capture and request the table separately | Check the whole table against the original cell by cell |
| Financial statements, spreadsheets | Check for table collapse first | Core figures must be re-verified against the original |
Think of this workflow as a document-specific version of the "verify the source" stage in our four-stage researching with AI loop (gather → summarize → cross-check → verify). For the full research flow, see that article; for handling a single document precisely, this one.
The question to ask when handing AI a document isn't "how accurate is this," it's "which part of this document has a structure that's easy to lose." Checking three things in advance — whether it's scanned, how long it is, and whether it has tables — avoids most failures.
※ This article describes the general architecture of publicly documented document-processing AI as of August 2026. Individual commercial tools differ in implementation. Companies mentioned are illustrative for the architecture and this is not investment advice.
※ This guide is provided for general educational purposes and simplifies technical details for readability.
New guides, when they land
We publish AI literacy guides twice a week. Subscribe and the next one comes to you — free, unsubscribe anytime.