Read and Organize PDFs with AI: Turn a Pile of Files into Checkable Answers

The goal

When you are done, you should have: a table that flattens twenty-odd PDFs into one structure — one row per document, one column per field you care about, a filename and page number behind every key claim, and a spot-check that tells you roughly how accurate this extraction run was.

"With page numbers" and "with a known accuracy rate" are what separate this from "summarise these for me." Without page numbers your summary cannot be verified, and putting it in a report is gambling. Without a spot-check you don't know whether to trust it, so you end up either believing all of it (dangerous) or none of it (wasted effort).

This path covers batches of documents you need to compare: papers, industry reports, vendor proposals, product manuals, meeting minutes, tender documents, the commercial terms of contracts. It does not cover three things — legally binding contract review conclusions, financial audit, or medical diagnosis. In those, the cost of an error is yours; AI can do first-pass screening only, and the final judgement belongs to a qualified human.

The tool stack

Figure 1: The seven steps. The spot-check is the only quality gate; skip it and the reliability of everything downstream is unknown.

Why this stack

Why triage comes before uploading. "AI can't read my PDF" usually hides four completely different problems: the scan has no text layer at all, a two-column paper is being parsed out of order, a table has been flattened into gibberish, or a very long document is being truncated. The fixes differ, and testing them blindly by switching models is the slowest possible approach. Thirty seconds of classification beats three model swaps.

Why the field template is locked first. Ask "summarise this" twenty times and you get twenty differently shaped summaries that cannot be compared — you have merely moved the work downstream. Lock eight to twelve fields and the twenty outputs stack straight into one table, which is what "organising" actually means.

Why every line needs a page number. Page numbers do three jobs: they let you verify; they make invention harder (demanding a citation measurably reduces fabrication); and they make the result usable by someone else — nobody will rely on a table whose claims have no source.

Why the spot-check is mandatory. Extraction accuracy swings wildly by document type: a clean text PDF may be near-perfect, while a scanned document full of tables may be half wrong. Twenty minutes checking three random files tells you whether this batch can be used directly or must be verified line by line.

The full steps

Step 1: Triage and naming

List every file and open each one briefly to classify it:

• Text: you can select the text, single column. Easiest case.
• Scanned: text can't be selected, or selecting yields garbage. Needs recognition first.
• Multi-column: papers, journals, two-column reports. Prone to out-of-order parsing.
• Table-heavy: mostly large tables. Needs separate handling.
• Very long: past a hundred or two hundred pages. Needs splitting by chapter.

Standardise names at the same time: year-source-topic.pdf. It looks like busywork, and every later claim depends on the filename to locate it.

Step 2: Preprocess

• Scans: run recognition. The test is whether text can be selected, not whether it looks legible.
• Multi-column documents: if the extracted text runs across columns (a sentence interrupted by material from the other column), change the parsing approach, or screenshot the pages and hand them to a multimodal model.
• Very long documents: split by chapter, keeping the chapter number in the filename.
• Noise pages: covers, copyright pages, blanks, raw data appendices. Remove them first — they carry no information and consume context.

Step 3: Lock the field template

The pivotal step. Write down what you actually want this batch of documents to answer, then work backwards to the fields. Usually eight to twelve: document type, publisher, publication date, core conclusion, key figures, method or scope, stated limitations, relevance to your question, page locations.

The template must include two special values: "not stated in the source" and "uncertain". Without those escape hatches, the model will fill the blank.

Step 4: Extract, one document at a time

One file per run. Do not paste twenty in together. The classic batch failure is attribution drift — a figure from document A attached to document B, in a way you cannot see.

Paste each result into the table as you go. This step is where a fixed prompt pays off; see the second prompt below.

Step 5: Spot-check

Pick three files at random (not the ones you know well) and verify the extracted values word by word against the source. Record three numbers: fields fully correct, fields wrong, and fields that should have said "not stated" but were filled in. Any value above zero on the third number means your prompt isn't tight enough.

If accuracy is low, go back to step 2 and check preprocessing rather than reaching for a different model.

Step 6: Consolidate and cross-question

Once twenty rows sit in one table, do three things:

1. Find contradictions: where two documents give different numbers for the same thing.
2. Find blanks: any field empty across most rows usually means your question isn't covered by this batch at all.
3. Cross-document Q&A: load the whole batch into a citation-enforcing tool like NotebookLM, ask a few synthesis questions, and check whether the passages it cites agree with your table.

Step 7: Archive

Store three things together: the original files, the results table, and the prompt version you used. The third is the one people skip, and it halves the time next time you do a similar job.

Figure 2: The triage decision tree. Four questions split "AI can't read my PDF" into four distinct diagnoses, each with its own treatment.

Prompts

1. PDF triage

I need to process a batch of PDFs. Below are the text extraction results for the first
two pages of one of them, plus a page screenshot. Classify this document and recommend
how to handle it.

Assess:
1. Text-based or scanned (is the extraction empty, garbled, or obviously OCR error).
2. Single or multi-column (does the extracted text run across columns).
3. Body text or mostly tables.
4. Whether headers, footers, watermarks or a table of contents pollute the body text.

Output: classification / evidence for it / handling recommendation (recognition needed,
screenshots needed, splitting needed) / expected extraction difficulty (low/medium/high).

Extracted text:
{paste the first two pages of extraction}

2. Structured extraction template

You are a research assistant responsible for document information extraction. Extract
the following fields from this PDF and output a Markdown table, one column per field.

Fields:
1. Document title
2. Publisher / author
3. Publication date
4. Document type (report / paper / proposal / manual / contract)
5. Core conclusion (one sentence)
6. Key figures (max 5, each stating what the number measures and on what basis)
7. Method or scope
8. Limitations or exceptions explicitly stated
9. Relevance to "{your question}" (high / medium / low, with a reason)

Hard rules:
- Every field must carry a page reference in the form "(p.12)". Spans are "(p.12–14)".
- If the source does not state something, write "not stated in the source". Never infer
  from general knowledge or from the title.
- Where you have a clue but are not certain, write "uncertain: {your evidence}" rather
  than a confident answer.
- Copy figures verbatim, including units, currency and time basis. Do not convert,
  do not round.
- Finish with a separate "risks in this extraction" note: which fields you suspect you
  may have misread, and why.

3. Cross-document comparison

Below is a structured results table extracted from {N} documents. Analyse across them.

Tasks:
1. Contradictions: where different documents give different values or conclusions for
   the same fact. List document names, each claim, and page numbers, and suggest the
   likely reason (different basis / different period / different sample / genuine conflict).
2. Blanks: which fields are mostly empty, and what kind of information this batch
   therefore doesn't cover.
3. Timeline: order by publication date and note how conclusions changed over time.
4. Confidence tiers: which conclusions have multiple independent documents behind them,
   and which rest on a single source.

Strict rule: use only what is in the table. Do not add background knowledge.
Where you cannot judge, write "needs checking against the source".

Table:
{paste the consolidated table}

4. Spot-check scoring

I will give you an excerpt from a document and the extraction result I produced earlier.
Check it field by field and score it.

For each field output: field name / extracted value / what the source actually says /
verdict (correct / wrong / should have been "not stated" but was filled / wrong page).

Finish with totals: fields correct, fields wrong, fields fabricated, page errors, plus a
one-line verdict: usable as is / needs line-by-line verification / should be redone.

Do not make excuses for my extraction. If it's wrong, say wrong.

Source excerpt:
{paste the source}

Extraction result:
{paste the extracted table}

Worked example: the page numbers matter more than the prose

Test setup: macOS with the Claude Code CLI 2.1.226, --model sonnet, August 2026. The PDF is fictional material generated for this demonstration — three pages, and since the page layout was authored deliberately, every page reference can be verified.

Before you start: install the CLI

The demos use the Claude Code command line. Three commands to install and verify:

# 1. Node.js 22 or newer is required
node --version

# 2. Install globally
npm install -g @anthropic-ai/claude-code

# 3. Verify
claude --version        # should print something like 2.1.226 (Claude Code)
claude doctor           # checks that the installation is healthy

The first run needs a login: type claude in a terminal to open the interactive interface and follow the prompts to authorise your account (claude auth manages the login state afterwards). Once that is done, the one-shot -p calls below run directly.

Every command here passes --model sonnet so that you reproduce against the same model tier used for these runs; without it you get your account's default model and the output will differ.

Step one: create the material (copy and paste)

Build a three-page PDF. The content distribution is intentional: page 1 holds the method (sample size, observation period, exclusions), page 2 holds the data (occupancy, time windows, median), page 3 holds the limitations and explicitly states that no data was collected on users' industries — that last item is the trap set for a refusal.

mkdir -p ~/demo/pdf && cd ~/demo/pdf

cat > source.html <<'EOF'
<!doctype html><meta charset="utf-8">
<style>body{font-family:-apple-system,Helvetica,sans-serif;font-size:14px;line-height:1.8;margin:0}
.page{padding:60px;height:1000px;box-sizing:border-box;page-break-after:always}
table{border-collapse:collapse;margin-top:12px} td,th{border:1px solid #999;padding:6px 12px}</style>
<div class="page">
<h1>Shared Desk Utilisation: Annual Record (fictional material, for demonstration)</h1>
<p>Prepared by: Farridge Research Room</p><p>Published: 18 April 2026</p>
<h2>1. Method</h2>
<p>This record covers 46 shared-desk sites across 12 cities, observed from September 2025
to February 2026, six calendar months. Each site was recorded on two working days per week.
Weekends and public holidays were not recorded.</p>
<p>Company-owned offices are excluded, as are single uses shorter than 2 hours.</p>
</div>
<div class="page">
<h2>2. Findings</h2>
<p>Average working-day desk occupancy across the period was <b>63.4%</b>, with Tuesday to
Thursday clearly higher than Monday and Friday.</p>
<table><tr><th>Window</th><th>Average occupancy</th></tr>
<tr><td>09:00–12:00</td><td>51.2%</td></tr>
<tr><td>13:00–17:00</td><td>74.8%</td></tr>
<tr><td>After 17:00</td><td>28.1%</td></tr></table>
<p>Median single-session length was 3.6 hours; sessions longer than 8 hours accounted for
9.2% of all records.</p>
</div>
<div class="page">
<h2>3. Limitations</h2>
<p>Nothing after March 2026 is covered, and no data was collected on users' industries or
payment methods. Sites were suggested by partners and may skew towards central districts.</p>
<h2>4. Appendix: definitions</h2>
<p>Occupancy is desks occupied at a point in time divided by total available desks.</p>
</div>
EOF

# Print the HTML to PDF with headless Chrome (macOS path; use your own chrome path elsewhere)
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --no-pdf-header-footer \
  --print-to-pdf="shared-desk-annual-record.pdf" "file://$PWD/source.html"

rm source.html && ls

No Chrome is no obstacle — any PDF of three or more pages will do, as long as you know which sentence sits on which page, because that is what lets you verify the page references.

Then save the second prompt above as extract-prompt.txt, swapping the field list for the seven this report calls for (title, publisher, publication date, observation period and sample size, key figures, limitations, industry breakdown of users) and keeping all four hard rules.

Step two: run it

--permission-mode acceptEdits is what lets it read the PDF sitting in the directory:

claude --model sonnet --permission-mode acceptEdits -p "$(cat extract-prompt.txt)"

View full-size image

×

Terminal window: entering the demo/pdf directory and listing the PDF, calling claude to extract fields, printing a table where every cell carries a page reference, the industry field reads not stated in the source, and a risks note follows

Figure 3: The actual terminal output of the commands in this section. The `(p.1)` and `(p.2)` markers after each cell are what you check next.

Step three: check the page references

Excerpt from the output:

| Field | Extracted content |
| Publication date | 18 April 2026 (p.1) |
| Observation period and sample size | 46 shared-desk sites across 12 cities, observed from
   September 2025 to February 2026 (six calendar months); each site recorded on two working
   days per week; weekends and public holidays not recorded (p.1) |
| Key figures | 1) Average working-day occupancy: 63.4% (p.2). 2) By window: 09:00–12:00 = 51.2%,
   13:00–17:00 = 74.8%, after 17:00 = 28.1% (p.2). 3) Median single-session length: 3.6 hours
   (p.2). 4) Sessions longer than 8 hours: 9.2% of all records (p.2) |
| Limitations explicitly stated | Nothing after March 2026 is covered; no data was collected on
   users' industries or payment methods; sites were suggested by partners and may skew towards
   central districts (p.3) |
| Industry breakdown of users | not stated in the source (p.3 — explicitly notes no data was
   collected on users' industries) |

Open the PDF at page 2 and all four numbers are there:

View full-size image

×

Page 2 of the demo PDF: heading "2. Findings", text stating average working-day desk occupancy of 63.4%, a three-row occupancy table by time window, and a closing line with a 3.6 hour median and 9.2% of sessions over 8 hours, with "Page 2 of 3" in the corner

Figure 4: Page 2 of the PDF. Every figure the extraction marked `(p.2)` can be pointed at on this one page — that is what "with page numbers" buys you: someone else can disprove your conclusion in thirty seconds.

Checked line by line against the source, every page reference is correct: method on p.1, data on p.2, limitations on p.3. The figures are verbatim too — 63.4% was not softened to "about 64%", 3.6 hours was not converted to minutes, 9.2% was not rounded.

The last row is the point of this demonstration: it did not invent anything. "Industry breakdown of users" is an entirely natural field, and the model could easily have produced a plausible distribution that you would never catch inside a twenty-row summary table. Instead it wrote "not stated in the source" and added that the document explicitly says the data was not collected — which carries more information than a bare "not stated."

Its own risk note contained something worth copying down:

- The "Key figures" selection mixes two different bases — the all-day average (63.4%) and the
  per-window figures — which are presented side by side in the source and can be mistaken for
  one comparable set.

That kind of "different basis, do not combine" warning is exactly what you are most likely to walk into, and least likely to notice yourself, when consolidating twenty documents. Keeping the "finish with a risks note" line in the prompt is close to free.

One thing to be clear about: this was a clean, text-based PDF — the best case. The same prompt against a scan stalls at step one, because there is no text layer at all. That is why the triage step cannot be skipped.

What you have to supply

• The PDF files themselves, plus a file list
• The three to five questions you want this batch to answer — the basis for designing fields
• Field definitions: state the basis for each, e.g. does "key figures" mean headline numbers or every number
• A naming convention and one directory to hold everything
• A confidentiality judgement: which documents must not go to a public cloud service
• Time for the spot-check: at least twenty minutes, and it cannot be skipped

What you end up with

• A structured table: one row per document, uniform fields, key claims with page numbers
• A spot-check record and accuracy figure, stating how far this batch can be trusted
• A contradiction list and a blank-field list
• A timeline showing how conclusions changed
• An archive: originals, results table, and the prompt version used
• A topic-clustered mind map, when you need to show this to someone else

Time

Estimated for 20 documents of 20–40 pages each:

Scans are the only factor that doubles the total. If triage shows more than half the batch is scanned, re-plan — or ask whoever sent them for the original digital files. That one question frequently saves three hours.

Cost

• Usually free: at twenty or thirty documents, the free tiers of mainstream assistants generally cover it, and cross-document tools have free plans too.
• Two places cost appears: text recognition for scans, billed per page at volume; and repeated questioning of very long documents, where token-based pricing scales linearly with document length.
• How to spend less: strip the noise pages during preprocessing (covers, copyright pages, blanks, duplicated appendices) — that alone removes twenty or thirty percent of the input; and batch your questions into one pass rather than a chat-style back and forth.
• What not to economise on: the spot-check. Saving twenty minutes in exchange for a table of unknown correctness is the worst trade available here.

How it fails

Figure 5: Seven failures. The first two happen before the model sees anything, the middle three during extraction, the last two are process problems.

1. Scans that were never recognised. The most common and the easiest to spot: ask about specific content and you get vague statements clearly guessed from the title. Three seconds to diagnose — try selecting a line of text in a reader.

2. Multi-column text running together. The symptom is a sentence that breaks off and continues with unrelated material. Don't push these through plain text extraction; screenshot the pages and use a model that can look at images.

3. Summaries with no page numbers. Not the model's fault — you didn't ask. A conclusion without a page reference cannot be verified and shouldn't go into a report.

4. Numbers quietly processed. Models love to be helpful: rewriting 12.5 million as 12,500,000, converting currencies, turning 47.3% into "about 50%." All of these poison a comparison table. Write it into the prompt: copy verbatim, no conversion, no rounding, no unit harmonisation.

5. Loading the whole batch at once. With twenty documents in context the model blends them, most often attaching A's figures to B's name. The error looks entirely normal and is only visible against the source. One file at a time is the simplest defence.

6. Confidential documents on a public service. Contracts, salaries, unpublished financials, client lists — check before uploading. There is no remedy afterwards, only prevention. Marking sensitivity during triage costs almost nothing.

7. Not keeping the template. Next month a similar job appears and you rediscover the fields and re-tune the prompts from scratch. Storing the field template and prompt version alongside the results is the highest-return action in this whole process.

Alternatives

If you only need one conclusion: skip this process. Hand a single document to a model with one specific question and you're done in two minutes. The seven steps only pay off when you need to compare many documents.

If you need exact numbers for a decision: use AI extraction as a first pass and confirm the final figures against the source yourself. Especially for financial figures, legal clauses and technical specifications — a high spot-check accuracy does not mean this particular line is right.

If this batch will be queried repeatedly: don't build a one-off table, build a knowledge base — see Build a Knowledge Base with AI. The rule of thumb: if it will be asked about three or more times in a month, a knowledge base is worth it.

If the documents cannot leave your network: go local — local recognition plus a local model. Quality drops, and it is the only compliant path.

Other tasks in this series: Build a Knowledge Base with AI, Run Product Research with AI, Run Competitive Analysis with AI.