How Do You Get Clean Data Out of PDFs Without Retyping It?

How Do You Get Clean Data Out of Documents Without Hiring a Typist?

Send the document to a model that can read both the text and the page image, ask for a fixed output shape, and check the result against a rule you can verify. The reading part is close to solved. The checking part is where the project lives or dies.

Almost every B2B company has this problem somewhere. Invoices arriving as PDFs. Security questionnaires. Signed order forms. Insurance schedules. Someone opens each one and retypes fields into a system, and that person is usually expensive and bored.

This piece covers what the current tools can genuinely do, the limits you will hit first, and how to build the checking layer so the automation is trustworthy rather than merely impressive.

What Kinds of Documents Is This Actually Good At?

Documents with a stable meaning and an unstable layout. An invoice always has a total, a date, and a supplier, but every supplier formats theirs differently. That is the exact gap a model closes better than a template or a regular expression ever did.

It is much weaker where the meaning itself is ambiguous. A contract clause that a lawyer would argue about is not a field extraction problem. If two careful humans would disagree about the answer, an automation will disagree with both of them and give you no warning.

Our rough filter is whether a new employee could be taught the task in a morning with a one page instruction sheet. If yes, this works well. If the instruction sheet needs a flowchart and three exceptions, expect to build a review step rather than an automation.

Should You Use a General Model or a Purpose Built OCR Service?

It depends on whether you need judgement or throughput. A general model reads layout and meaning together and needs no training. A dedicated document service handles far bigger files, more pages, and gives you positional data. Many real systems use both.

The published limits make the split concrete. Anthropic's PDF support documentation puts the maximum request size at 32 MB and the maximum pages per request at 600, dropping to 100 "when the request's context window is under 1M tokens." That is a whole document, not a page.

Amazon Textract sits at the other end. Its published quotas allow asynchronous PDF and TIFF operations up to 500 MB in memory and 3,000 pages, while its synchronous operations are capped at 10 MB and, for PDF and TIFF, 1 page. Two very different shapes of tool.

What you need	General model	Document OCR service
Read a table nobody labelled	Strong	Needs configuration
Very long documents	600 pages per request at most	Up to 3,000 pages asynchronously
Coordinates of each field on the page	Not the design	Core output
Handwriting	Varies by document quality	Supported, English only
Setup effort	A prompt and a schema	An SDK, a bucket and a job poller
Judgement about what a field means	Strong	Not its job

In our work the pattern that holds up is a dedicated service for the mechanical read on very large files, and a model for the interpretation step afterwards. For everything under a hundred pages, the model on its own is usually simpler and good enough.

What Limits Will You Hit First?

Context, not accuracy. Anthropic's documentation is explicit that page limits are not the real ceiling. It warns that "dense PDFs (many small-font pages, complex tables, or heavy graphics) can fill the context window before reaching the page limit," and that requests with large PDFs "can also fail before reaching the page limit."

The reason is how the pages get processed. The documentation says "the system converts each page of the document into an image" and that "the text from each page is extracted and provided alongside each page's image." So you pay for the page twice, as text and as pixels, and a graphics heavy page costs far more than a plain one.

The token estimate makes this planable. Anthropic's cost guidance says each page "typically uses 1,500 to 3,000 tokens per page depending on content density," before image costs. Multiply by your real page count before you promise anyone a price.

The practical answer is almost always to split. Send the pages that matter rather than the whole document, and do the splitting with cheap deterministic code rather than asking the model to find its own way through 400 pages.

How Do You Design the Output So It Is Usable?

Define the shape first, in code, and make the model fill it. Every field gets a name, a type, and a rule for what unknown looks like. The most important field in any extraction schema is the one that lets the model say it could not find the value.

Without that field, a model will guess. It will produce a plausible invoice number because your schema demanded a string and it had nothing better to offer. Give it an explicit null or an unknown marker and the guessing mostly stops.

We also keep the raw evidence alongside the parsed value. For each field, store the text the model says it read it from, and the page number. That one habit turns every dispute from an argument into a lookup. Our piece on structured outputs for AI automations covers how to enforce the shape itself.

Keep the schema small. Ten fields you actually use beats forty fields where thirty are empty and nobody knows which ones are trustworthy.

How Do You Handle the Documents It Gets Wrong?

With arithmetic, not with more prompting. Most document data has internal checks available for free. Line items should sum to the subtotal. Tax should match the rate. Dates should fall in a plausible range. A supplier name should match one in your own records.

Run those checks in plain code after the extraction and route failures to a human. This is far more reliable than asking the model to double check itself, because the check is independent of whatever caused the first mistake.

Build a dead letter path for the documents that fail. A queue nobody watches is the same as no queue, so give it an owner and a number to look at each morning. We wrote about that plumbing in our guide to handling AI automation failures.

Finally, keep every failing document. The ones that break your automation are the best test set you will ever assemble, and they cost nothing to collect.

What Does This Cost at Volume?

Model cost scales with pages, not documents, and that catches people out. At roughly 1,500 to 3,000 text tokens per page plus image tokens, a 40 page document costs more than ten 4 page documents even though it is one file.

The cheapest lever is sending fewer pages. If the total you need is always on the last page, find it with code and send two pages. We have seen page filtering cut the bill by most of its size on document sets where the useful content is concentrated.

The second lever is caching. Anthropic's documentation recommends prompt caching to "improve performance for repeated analysis," which matters when you ask several questions about the same document rather than one.

Compare all of that against the current cost, which is a person's time. Most teams discover the automation is cheap and the review process is what actually costs money, which is the right thing to learn early.

Where Does a Human Still Belong in the Loop?

Wherever the output moves money, creates a legal obligation, or is hard to reverse. Extraction that feeds a report can run unattended. Extraction that feeds a payment run should not, no matter how good last month's accuracy looked.

The useful design is not full review of everything. It is confidence based routing. Documents that pass every arithmetic check and match a known supplier go straight through. Anything that fails a check, or comes from a supplier seen for the first time, goes to a person.

That split is what makes the economics work. Reviewing every document saves nobody any time. Reviewing only the minority that failed a check is a genuinely smaller job than the one you started with, and you can measure that share on your own documents in a week. We covered the wider pattern in our piece on keeping a human in the loop.

What About Handwriting, Scans, and Other Languages?

This is where published limits matter most, because the marketing rarely mentions them. Amazon Textract documents text detection for "English, French, German, Italian, Portuguese, and Spanish," and states that handwritten character recognition "is only supported in English."

Its quotas also set a floor on image quality. The minimum height for text to be detected is 15 pixels, which the documentation notes "at 150 DPI, this would be the same as 8 point font." A phone photo of a folded receipt may simply be below the threshold.

Two more constraints are worth knowing before you scope anything. Textract "does not support vertical text" alignment, which rules out some Japanese and Chinese documents, and its AnalyzeID feature "only supports US passports, and US driver's licenses." If your documents fall outside those lines, find out in week one rather than month three.

For a general model, the honest answer is that quality varies with the document and we test rather than predict. We have no vendor published accuracy figure for handwriting that we would repeat here, so we run a sample of the client's real documents before committing to anything.

How Would We Start a Project Like This?

With twenty real documents and one spreadsheet. Extract the fields by hand once, so you have a truth set. Then run the automation against the same twenty and count the disagreements. That number is your business case, and it takes an afternoon.

What we avoid is building the pipeline first. Ingestion, queues, and dashboards are easy to build and easy to build for the wrong accuracy level. Learn the accuracy first, then decide how much review infrastructure it needs.

If you have a document pile someone is retyping by hand and you want to know whether it is worth automating, we are happy to look at a sample with you. You can find us at phoenix.studio.