A scanned PDF is not a document. It is a photograph of one, wrapped in a PDF container. There are no words inside the file — only pixels arranged so that your eyes assemble words from them — which is why the usual PDF-to-Excel advice produces an empty spreadsheet and no explanation.
Everything here follows from that one fact. First, how to confirm it in ten seconds. Then what actually has to happen, and what you can do to make it work better.
Check whether your PDF is a scan
Three ways, quickest first.
Try to select the text. Open the PDF and drag across a word. If you get a selection highlight that follows the words, there is a text layer. If you get a blue rectangle over the whole area, or nothing at all, it is an image.
Search it. Press Ctrl+F or Command+F and search for a word you can plainly see on the page. No result means no text.
Check a whole stack at once. Extract Text from PDF reads a document in your browser and tells you per page whether there is a text layer. When there is not, it says so explicitly rather than handing you an empty box — which is the answer you need before planning any work. It does not do the recognition step itself; it tells you whether the recognition step is required.
Do this on a representative handful before you plan anything. A stack is often mixed: the supplier's own PDFs have text and the three that were faxed and rescanned do not.
Why a converter returns nothing
A PDF-to-Excel converter reads the text objects in a file and works out which cells they belong to. A scan has no text objects. There is one big image object per page, and the converter has nothing to read — so it either returns an empty sheet or, worse, a sheet with one cell containing the image.
This is not a defect in the converter and no setting fixes it. The missing step is optical character recognition: looking at the pixels and deciding which letters they depict. OCR has to happen before any conversion is possible, and it is a genuinely different kind of operation — conversion is reading a file, OCR is interpreting a picture, which means it produces a best guess rather than a fact.
That distinction is the one to keep hold of. With a text PDF, the characters in the file either are read or are not. With a scan, every character is a judgement, and judgements are occasionally wrong in ways that look entirely plausible on the page.
The two-step route, and what each step costs
For a scan, the job is always:
- Recognise the characters from the image, producing text.
- Structure the text into the columns you want.
Plenty of tools do step one. Adobe Acrobat has a "Recognise Text" feature. Free OCR engines exist. Most modern scanners and multifunction printers will do it at scan time if you ask for "searchable PDF" rather than "image PDF" — and that is much the best place to do it, because the device has the original page at full quality rather than a compressed picture of it.
Step two is then the ordinary extraction problem: name the fields you want and ask them of every document, exactly as extracting specific fields from PDFs describes. Nothing about it is special to scans.
What is special to scans is that step one introduces errors that step two cannot
detect. A 5 read as S inside a reference number looks like a reference
number. A decimal point lost in a speck of dust turns 1,240.00 into 124000. The
structuring step has no way to know, which is why the checking advice below is
not optional padding.
Make the scan better before you make it readable
The quality of the image sets the ceiling for everything downstream, and it is the cheapest thing to improve. If you control the scanning at all:
Scan at 300 dpi. 200 is visibly worse on small print; above 400 gains little and costs a lot of file size. 300 is the long-established sweet spot for text.
Scan in greyscale, not colour, and not bitonal. Colour triples the size for no
recognition benefit. Pure black-and-white is worse than greyscale, because
thresholding throws away the edge information that helps distinguish 8 from B.
Get the page straight. Skew is the single biggest avoidable cause of bad recognition, because most engines assume text runs horizontally. A couple of degrees is enough to matter. Use the flatbed rather than the feeder for anything creased.
Turn off heavy compression. Aggressive JPEG on a page of 8-point text produces exactly the artefacts that turn digits into other digits.
Ask the device for a searchable PDF. If the scanner will embed a text layer, let it. You skip a whole step and get the best-quality input doing it.
And for documents you receive rather than produce: ask the sender for the original. A supplier emailing you a scan of a printout of a PDF almost always has the PDF. One email replaces the entire problem, and it is worth sending before building any process around the scans.
What a scan cannot give you back
Some information is not recoverable at any image quality, and it is better to know which before the review step.
A faded or low-contrast original. Recognition cannot see what the scan did not capture. Rescanning helps; processing does not.
Handwriting. Handwritten amendments — a corrected total, an initialled discount, a hand-written delivery quantity — are a different recognition problem altogether and should be treated as requiring a human.
Stamps and signatures over text. Where a stamp overlaps a figure, the figure is partly gone.
Anything outside the scan. A two-sided document scanned single-sided is missing half its content, and nothing in the file says so. Check page counts against what you expect — PDF Page Counter will do it across a folder — because a stack of even-page documents with an odd page count somewhere is a scanning error you want to find now.
Checking a batch that came from scans
Treat the output as needing verification in a way a text-PDF batch does not. Four checks, all in the spreadsheet, none requiring you to reopen a document:
- Arithmetic that should hold. Net plus tax equals gross, as a formula on every row. Misread digits break arithmetic far more often than they survive it, which makes this the single most effective check available.
- Magnitude. Sort every amount column and look at the extremes. A lost decimal point shows up as a number a hundred times too big, and it is obvious at the top of a sort and invisible in the middle of a sheet.
- Reference format. If your references are
INV-00000shaped, a reference that is not is a misread. A conditional format on the pattern finds them all. - Dates in range. Sort the date column; anything outside the period you expected is a misread.
Keep the Source file column, and keep the scans. On a scanned batch, being able to open the image behind a suspicious row is the whole of your audit trail.
Other ways round the problem
Get the data, not the document. If the scans are statements from a bank or a portal, a CSV or XLSX export almost certainly exists behind a login. It will be better than anything OCR can produce from paper, and it takes five minutes to check.
Re-key the few. For ten scanned invoices, typing four fields each is twenty minutes and produces no recognition errors at all. The threshold at which automation wins is higher for scans than for text PDFs, precisely because the review step is real work.
Split the stack. Run the text PDFs and the scans as two batches. They need different amounts of checking, and mixing them means the whole sheet inherits the scans' review burden.
Common questions
Can ExtractToExcel handle scanned documents? Yes — the extraction pipeline accepts them. Results vary with the image quality and legibility of the scan, which is why the scanning advice above is worth following, and why a scanned batch deserves the arithmetic check more than a text batch does. The FAQ says the same.
Will OCR give me a perfect spreadsheet? No, and no tool that claims otherwise should be believed about a photograph of a page. Plan for a review step; design the sheet so that review is a formula rather than a re-read.
Does the free Extract Text tool do OCR? No. It reads the text layer of a PDF in your browser, and when there is not one it tells you that OCR is what would be needed. That answer is the useful thing: it is how you tell a readable stack from a scanned one before committing to anything.
My PDF has text on some pages and not others. Common, and worth knowing per page rather than per file. A document assembled from an emailed PDF plus two scanned attachments behaves as two different problems in one file.
Is a photo from a phone as good as a scan? Usually worse — uneven lighting, perspective and curl all hurt. Most phones now have a document mode that flattens and squares the page; it makes a large difference.
The short version
Find out whether you have a scan before anything else, because it changes the plan rather than the settings. Fix the image where you can, ask the sender for the original where you can, and build the arithmetic check into the sheet rather than promising yourself you will spot-check later.
If your documents turn out to have a text layer after all, none of this applies and converting multiple PDFs into one spreadsheet is the workflow you want.