Somewhere in your company a person opens PDFs and types what they see into a spreadsheet. This is the walkthrough for replacing that loop in an afternoon, starting with the one step everybody skips.
By the end of this you should be able to point at a folder of PDFs, invoices, signed contracts, certificates of insurance, RFP responses, and have the four or five fields you actually care about land in a spreadsheet without anyone opening a single file. Right now that job belongs to a person, and the tell that it belongs to a person is that it has never once appeared on a roadmap. It just quietly eats a chunk of somebody's week, every week, in perpetuity, and everybody has agreed not to look directly at it.
The build takes an afternoon. Most of the afternoon is spent on a step that has nothing to do with AI.
The reason these projects usually produce mush
Here is the mistake, and almost everybody makes it on the first try. You upload a document and ask the assistant to "read this invoice and tell me what's in it." You get back a paragraph. It is a good paragraph. It is also a different paragraph every single time, and a paragraph does not go in a spreadsheet column.
What you want instead is structured extraction, which is a technical-sounding name for a boring idea: you tell the model the exact fields you want, the exact type each one should be, and what to say when it cannot find one. Not "summarize this." Instead, "return vendorname as text, invoicenumber as text, invoicedate as a date, totalamount as a number, and the literal value not_found for anything missing." Same nine columns every time, whether the document is a two-page invoice from a vendor who uses Word or a fourteen-page contract from a firm that still faxes.
So the schema is the spec. Whoever writes the column list is doing the actual design work here, and that person does not need to be an engineer. It needs to be whoever currently knows why the third column exists.
Step one: write the columns before you touch a tool
Open a blank sheet. Write one row of headers, and next to each one, in plain English, a sentence describing what belongs in it. Not "amount." Something more like "total_amount: the final amount due including tax, as a number with no currency symbol."
This takes twenty minutes and it is the part people skip. It is also where you discover the interesting stuff: that two of your columns are the same field under different names, that one of them is a judgement call nobody wrote down, that the person doing this manually has been silently correcting a vendor's date format for two years. Those discoveries are worth the twenty minutes on their own, before any automation exists.
Step two: run twenty by hand, in the tool you already pay for
Do not automate anything yet. Grab the last twenty documents that came through, drop them into whatever assistant your team already has a subscription to, and ask for a table with exactly your columns and your not_found convention.
Know the ceilings before you start. Anthropic's PDF support documentation puts the maximum request size at 32 MB and caps a single request at 600 pages, dropping to 100 pages when the context window is under 1M tokens, and the file has to be a standard PDF with no password or encryption. That last one matters more than it sounds. Locked PDFs are common in finance and legal workflows and they will fail the whole batch quietly if you do not check.
Now count. Out of twenty, how many rows would you have accepted without editing? That number is your go or no-go, and it is the only benchmark in this build that means anything. Eighteen out of twenty is a workflow. Twelve out of twenty is a document-quality problem you need to fix upstream before automation makes it faster.
Step three: wire the loop
This is the trigger, AI step, action pattern this series has covered before, pointed at documents. In n8n, the three pieces are all built in and none of them require code.
The trigger watches wherever documents arrive, a Drive folder, an inbox, a form upload. Then n8n's Extract from File node has an explicit Extract From PDF operation that pulls the text out of the file. Then the Information Extractor node takes that text and does the structured part, and it has a Schema Type setting with three ways to define your fields: From Attribute Descriptions, where you list attributes and describe each one in plain language, Generate From JSON Example, or Define using JSON Schema. The first option is the one you want, because it is exactly the sheet you wrote in step one, typed into a form. Last step writes the row.
That is four nodes. The work you did in step one becomes the configuration of node three, which is why the twenty minutes with the blank sheet was not a warmup.
Step four, only when volume justifies it: stop paying for the easy pages
Paid extraction services bill per page whether or not the page needed the expensive machinery. Unstructured gives you 15,000 pages a month free and then charges $0.03 a page, capped at $3,000 a month. For most teams the free allotment covers everything and this step is irrelevant. If you are past it, the number worth knowing comes from Firecrawl's pdf-inspector, which trended hard on GitHub this week: roughly 54 percent of PDFs in a typical pipeline already carry machine-readable text underneath and never needed optical character recognition at all. The library sorts text-based from scanned in 10 to 50 milliseconds, for free, under an MIT license, before anything paid touches a page.
Being straight with you: this is a Rust library, and wiring it in is the one step in this build that wants somebody technical. It is also the one step you can defer indefinitely. Nobody at 3,000 pages a month needs it.
What goes wrong
Extraction that is 95 percent right is more dangerous than a person who is 99 percent right, because the errors are silent and they are plausible. A human who cannot read a smudged total leaves the cell blank and asks somebody. A model fills it in with a number that looks completely reasonable and sits in your spreadsheet forever.
So build the doubt in. Add a review column, and flag any row where a required field came back not_found, where the total does not parse as a number, or where the date falls outside a sane window. Those rows go to a review tab, not the main sheet. And for at least the first month, the loop writes to a staging sheet that a human promotes, not straight into your system of record. The checkpoint costs you thirty seconds a day and it is the difference between an automation you trust and one you quietly stop looking at.
You can try this today
Open the folder where these documents pile up and pull the twenty most recent. Write your column headers first, with one plain-English sentence describing each field. Upload the twenty and ask for a table with exactly those columns and the literal value not_found for anything missing. Count the rows you would have accepted without touching. If that count is sixteen or better, you have an afternoon of wiring ahead of you and a recurring line of manual work about to disappear.
The interesting part is not that AI can read a PDF. It is that the moment you sit down and write the columns out, you find out how little of that job was ever really reading.