How do you extract data from a PDF (digital or scanned)?

What's the difference between a digital PDF and a scanned PDF?

A digital PDF (sometimes called a "native" or "text-based" PDF) was exported from software — an accounting system, a word processor — and carries a text layer: the characters exist as selectable, copyable text inside the file. A scanned PDF is the opposite: it's a photograph of paper wrapped in a PDF container. There is no text inside, only pixels, so extracting anything from it requires OCR — optical character recognition, the step that turns those pixels back into characters.

Here's the part most guides skip: having a text layer does not mean the data is extracted. You can copy every character out of a digital invoice and still have no idea, programmatically, which number is the invoice total and which is a line-item subtotal, or which of the five dates on the page is the due date. Both PDF types need the same second step — understanding which text belongs to which field. The scanned PDF just needs one extra step before it (recognition), which modern vision-language models handle in the same pass anyway.

Why does "PDF to Excel" via copy-paste or converter tools usually break?

Generic converters map visual positions to spreadsheet cells, and that mapping is fragile. A line-item table where the description wraps onto two lines becomes two rows in Excel, with quantities and prices sliding into the wrong columns. A table that continues onto page 2 loses its header row, so the second half of the data arrives unlabeled. And a converted spreadsheet still isn't structured data — someone has to find the total, the tax breakdown, and the invoice number inside it by eye.

The deeper problem is layout diversity: every vendor formats invoices differently, so a manual cleanup recipe you build for one supplier's PDF is worthless for the next one. For a business receiving PDFs from 30 vendors, "convert then fix by hand" is 30 different fixing routines — which is just manual data entry with extra steps.

• Wrapped text in line-item cells splits one row into several, misaligning every column after it.
• Multi-page tables lose their header on continuation pages, so values arrive without labels.
• Merged cells, stamps, and logos get read as table content and pollute the output.
• Even a clean conversion gives you a grid of text, not fields — no invoice number, no total, no tax rate identified.

How does a PDF data extraction pipeline actually work?

A modern pipeline treats each PDF page as a document image and reads it with a vision-language model — the same approach whether the page carries a text layer or is a raw scan. Inferio's pipeline (built on Claude Vision) works page by page across multi-page PDFs, so a 6-page invoice with the line-item table continuing across pages 2–4 comes back as one document with one consolidated set of fields, not four disconnected fragments.

The output is structured JSON: named fields — vendor, invoice number, issue date, line items with quantity and unit price, tax breakdown, total — each carrying its own confidence score between 0 and 1. Fields scoring below the review threshold (0.75 by default) are routed to a human-in-the-loop correction UI instead of flowing downstream unchecked; a reviewer confirms or fixes just those values. That routing step is what separates an extraction pipeline you can post to your books from a converter whose output you have to re-verify line by line. The same pipeline reads documents in English, Japanese, and Vietnamese without a per-language setup.

How do you handle PDFs at volume — hundreds of invoices a month?

At volume, the bottleneck stops being extraction accuracy and becomes workflow: nobody wants to upload 300 PDFs one at a time and download 300 spreadsheets. The batch pattern is an upload or REST API call per document, asynchronous processing, and a signed webhook that notifies your system when each document's structured result is ready — your code never polls, and the webhook signature lets you verify the payload actually came from the extraction service.

The other half of volume handling is skipping the file-export step entirely. Extracted invoice data can sync directly into accounting software — Inferio connects to freee and MoneyForward via OAuth — or into an ERP through the API, so "PDF to Excel" becomes "PDF to posted journal entry" with Excel dropping out of the loop. For Japanese businesses this pipeline also carries the compliance work along: qualified invoice T-numbers are validated against the NTA's public API, consumption tax is classified into the 8% and 10% brackets, and documents are retained per the Electronic Bookkeeping Law's 7-year requirement.