Extracting Data from PDFs into a Table with AI (Without Retyping Anything)

Learning how to extract data from a PDF into a table with AI is one of those tasks that looks trivial until you try it on real documents. The numbers are right there on the page. You can see them. And yet getting them into forty clean rows of a spreadsheet — with consistent columns, no invented values, and some way to check the ones that matter — is where most people give up and start retyping.

This is a practical guide to doing it properly: what makes PDF tables hard, a six-step workflow that survives messy real-world files, the prompt patterns that produce clean output, and — the part usually skipped — how to verify the result without re-reading every page you were trying to avoid reading.

Why "just copy it into a spreadsheet" stops working

Copying one table out of one PDF is a two-minute job. The problem is that real extraction work almost never looks like that. It looks like:

• 14 vendor invoices from 9 different suppliers, each with its own layout, and you need supplier, invoice number, date, net, tax, total.
• 30 research papers, and you need author, year, sample size, method, and effect size in one comparison grid.
• A 200-page annual report where the figures you need are scattered across a dozen tables that don't share a format.
• 60 employment contracts and a question about notice period, probation length, and non-compete duration for each.

Three things break at once. Volume makes manual entry expensive. Inconsistency means no single copy-paste recipe works across documents. And silent errors — a transposed digit, a row read from the wrong column — are invisible in the output, because a wrong number looks exactly like a right one in a spreadsheet cell.

That last point is the real reason to care about how you extract, not just whether you can. A table of extracted data is a table of claims. If you can't trace a claim back to the page it came from, you've converted a document you could check into a spreadsheet you can't.

What actually makes PDF extraction hard

PDF is a layout format, not a data format. It stores instructions for placing glyphs at coordinates. There is usually no "table" in the file at all — just text positioned so that a human eye perceives rows and columns. Everything downstream inherits that problem.

Three kinds of PDFs, three difficulty levels

Text-native PDFs — exported from Word, LaTeX, or an accounting system. The characters are real text. Extraction is mostly a matter of correctly inferring structure from position. This is the easy case and the majority of business documents.

Scanned PDFs — a photograph of a page wrapped in a PDF container. There is no text until OCR produces some. Quality depends on scan resolution, skew, and contrast. Expect character-level errors, especially in numbers: 1 and 7, 5 and S, 0 and O. Always spot-check scanned figures.

Hybrid and structurally awkward PDFs — text-native, but with merged cells, multi-line rows, footnote markers glued onto values, totals rows that look like data rows, and tables that break across pages so headers appear once and then never again. These are the ones that produce plausible-looking garbage.

The failure modes nobody warns you about

• Column drift. A row where one cell is empty shifts the remaining values left. The output is well-formed and completely wrong.
• Units and currency. 1,250 in a table labelled "£000s" is £1,250,000. The model will happily give you 1250 unless you ask it to normalize and record the unit.
• Page-break rows. A row split across two pages becomes two half-rows, or one row silently dropped.
• Footnote contamination. 4,320¹ becomes 43201 if the superscript isn't handled.
• The helpful invention. You asked for six columns; the source only supports five. A model optimizing for a complete-looking answer may fill the sixth with something reasonable rather than admitting the document doesn't say. This is the most dangerous failure of all, because it looks like success.

That last one is worth dwelling on. It's the same underlying behaviour behind AI hallucination on documents — a model answering from pattern rather than from the page in front of it. Extraction is where it hurts most, because output that arrives as a tidy grid reads as verified even when nothing has been verified.

The workflow: PDF to table in six steps

1. Define the schema before you ask for anything

Write down your columns first, with the exact type and format you want for each. Not "the invoice details" but:

supplier_name (text) | invoice_number (text) | invoice_date (YYYY-MM-DD) | currency (ISO code) | net_amount (number, no separators) | tax_amount (number) | total_amount (number) | payment_terms (text, verbatim)

This single habit removes most downstream cleanup. It forces you to decide what "date" means before you get three formats back, it makes mismatches obvious, and it gives the model an unambiguous target instead of an invitation to improvise a structure.

Add a rule for absence while you're at it: if a field isn't stated in the document, write NOT STATED — do not infer, calculate, or estimate it. You want gaps to be visible, not filled.

2. Upload the documents together, not one at a time

Extraction across a set is a different job from extraction from a single file. When all the documents are in one workspace, you can ask a question once and get one consolidated table with a source column, instead of running the same prompt 14 times and stitching the results by hand. It also lets you ask the cross-cutting questions that are the actual point of the exercise — which three suppliers account for the most spend? — once the grid exists.

3. Ask for the table explicitly, in one pass per column group

A good extraction prompt is boring and specific:

Extract one row per invoice with these columns: supplier_name, invoice_number, invoice_date (YYYY-MM-DD), currency, net_amount, tax_amount, total_amount. Numbers as plain digits, no currency symbols or thousands separators. If a value is not stated in the document, write NOT STATED. Include a source column naming the file and page.

If you need fifteen columns, don't ask for fifteen at once. Two or three passes of five or six columns each, joined on a key, is measurably more reliable — attention spread thin across many fields produces more drift than the same work done in focused batches.

4. Demand the source alongside every value

This is the step that separates a spreadsheet you can defend from one you can only hope about. Ask for the file and page (or clause, or table caption) for every row, and use a tool where the citation is a link that opens the source passage rather than a string of text asserting a page number. A citation you can't click is a claim about a claim.

Whichever tool you use, the test is the same: can you get from a cell in your output back to the ink on the page in one action? If not, verification means re-reading the document, which is the work you were trying to avoid.

5. Verify the cells that cost money if they're wrong

You don't need to check every cell. You need to check the ones with consequences, and you need a systematic sample of the rest.

• Every value you'll act on. Totals, dates that trigger obligations, thresholds, anything going into a filing or a decision.
• Every NOT STATED. A gap can mean the document is silent, or that extraction missed it. These are quick to check and often the most informative rows.
• A random 10%. If the sample is clean, your error rate is probably tolerable. If two of six sampled rows are wrong, stop and fix the process — usually the schema was ambiguous or the source is scanned and needs different handling.
• Anything that looks too neat. Suspiciously round numbers and perfectly uniform values in a column that should vary are both classic signatures of inference filling in for evidence.

6. Check the arithmetic the document should already satisfy

Documents carry internal consistency you can exploit for free. Does net + tax = total in every row? Do the line items sum to the stated subtotal? Do the percentages add to 100? Do the dates fall inside the contract period?

A single formula column that flags rows failing these checks catches column drift, dropped digits, and OCR errors in seconds, without reading anything. Run it before you look at the data, not after you've drawn conclusions from it.

Worked example: a comparison grid from research papers

The pattern generalizes well beyond invoices. Suppose you have twelve papers and need a methods comparison.

Schema first: paper (short citation) | year | design | n | population | primary_outcome | effect_size | ci_or_p | funding_source.

Then the prompt:

One row per paper. Report n as the analysed sample, not the enrolled sample, and note in the row if they differ. Copy effect sizes verbatim including the measure used — do not convert between measures. Where a paper doesn't report a field, write NOT STATED. Cite the section for every effect size.

Two details in there do most of the work. "Analysed, not enrolled" resolves an ambiguity that would otherwise be resolved silently and inconsistently. "Do not convert between measures" blocks a helpful-looking transformation that quietly destroys comparability — an odds ratio rendered as a risk ratio is not the same number, and the conversion depends on a baseline rate the paper may not report.

Verification here is unglamorous and fast: open the citation for every effect size and every n. Those two columns carry the argument. The rest can be sampled. If you're doing this regularly, the fuller workflow is in our guide to comparing two research papers with AI, and the same grounding principles apply to any research and analysis workflow.

Prompt patterns that produce clean tables

A few phrasings that consistently improve output:

• "One row per X." Naming the unit of the row prevents the model from choosing a different granularity than you expected.
• "Verbatim" for text fields. Payment terms, clause language, and outcome definitions should be quoted, not paraphrased. Paraphrase in a data table is lossy in ways you can't detect later.
• "Do not calculate." If you want derived values, derive them yourself in the spreadsheet where the formula is visible. A calculated value that arrives as an extracted value is indistinguishable from a stated one.
• "NOT STATED" rather than blank. Blanks are ambiguous — was it absent, or was it missed? An explicit marker is checkable.
• "List the documents where you found no matching data." This surfaces silent skips. A table of 11 rows from 14 files should tell you about the other three.
• Ask for the count first. How many invoices are in these files? If the answer is 14 and your table has 12 rows, you know before you start using it.

When AI extraction is the wrong tool

Honest limits, because pretending there aren't any helps nobody:

• High-volume, fixed-layout, recurring documents. If you process the same form 5,000 times a month, a template-based extraction pipeline or a vendor API is cheaper, faster, and more deterministic. AI extraction earns its keep on varied documents, not identical ones.
• Poor scans. Below roughly 200 DPI, or with heavy skew and bleed-through, fix the scan first. No amount of prompting recovers characters that aren't legible.
• Complex nested tables. Multi-level headers with merged spans sometimes genuinely need a human to interpret the structure once, after which the rest follows.
• Anything where an undetected error is unacceptable and unverifiable. If you can't check it, and being wrong is catastrophic, extraction should be a first pass that a person confirms — not the final answer.

The realistic framing: AI extraction turns hours of transcription into minutes of transcription plus a focused verification pass. That's a large, real win. It is not the same as zero work, and tools that imply otherwise are selling something.

Where the file actually goes

Worth asking before you upload, especially for invoices, contracts, or unpublished research. Three questions cover most of it: is the document used to train models, who can access it, and does deleting it actually delete it? Free consumer tools frequently answer those questions in ways that wouldn't survive review by your own compliance team.

FileAI is a private document workspace: your files aren't used to train models unless you explicitly opt in, and answers are grounded in the documents you uploaded — with numbered citations that open the exact source passage, and an honest "I don't know" when the documents don't contain the answer. For extraction specifically, that combination is the difference between a spreadsheet of claims and a spreadsheet of evidence. If verification matters to you, our guide to chatting with a PDF and actually trusting the answer goes deeper on the verification habit itself.

A checklist you can reuse

1. Write the schema — column names, types, formats — before prompting.
2. Add the absence rule: NOT STATED, never inferred.
3. Upload the whole document set together.
4. Ask for one row per unit, in batches of five or six columns.
5. Require a source citation per row that opens the passage.
6. Ask how many units exist; compare to your row count.
7. Run consistency formulas: sums, percentages, date ranges.
8. Verify every consequential cell, every gap, and a random 10%.
9. Keep verbatim text verbatim; derive calculations yourself.
10. Note what you didn't verify, so the next reader knows.

Summary

Extracting data from PDFs into a table with AI works well — provided you treat the output as a set of claims to be checked rather than a finished dataset. Define the schema first so the model has an unambiguous target. Force gaps to be visible instead of filled. Insist on citations that open the source, because a table you can't trace is a table you can't defend. Then spend your saved time on a focused verification pass over the cells that actually matter.

Done that way, the hours-long transcription job becomes a short extraction plus a short check — and unlike retyping, the result comes with its own audit trail.

Want to try it on a document of your own? Start free with one file — no card required — and ask for your first table.