Converting one PDF to a spreadsheet is a formatting problem. Converting a folder of them into a single spreadsheet is a different problem entirely, and most tools built for the first make the second harder rather than easier. This is about the second.

One row per document, not one file per file

Start with what you actually want at the end, because it decides everything else.

If you convert fifty PDFs one at a time, you get fifty spreadsheets. Each one is shaped like the document it came from, which means fifty different column layouts, and you now have a merging job on top of the conversion job you just finished. Nothing you can sum, sort or filter exists yet.

What you want is one sheet with a header row you chose, and one row per document. Fifty rows. The supplier's layout does not appear anywhere in it, because layout was never the thing you wanted — the values were.

That inversion is the whole idea. Instead of asking "what does this document look like as a spreadsheet?", once per document, you ask "what do I want from every document?", once, and then apply it to all of them.

Where the batch approach fits

This is worth doing when three things are true:

The documents repeat. Not identical — supplier invoices from twenty different suppliers repeat in the sense that matters — but the same kind of document, so the same questions make sense of all of them.

You want the same fields from each. Supplier, date, reference, total. If each document needs different questions asked of it, you have a reading task, not a conversion task.

There are enough of them that doing it by hand is a scheduled activity rather than a two-minute interruption. That threshold is lower than people think, because the cost of hand-transcription is not the typing — it is the concentration, and the checking afterwards.

Invoices, receipts, purchase orders, delivery notes, bank statements, remittance advices, timesheets, lab results, inspection reports: all of these arrive as a stack of PDFs that someone eventually re-types.

Choose the column set once

The column set is the specification of the whole job, so it deserves a few minutes before anything is uploaded anywhere.

Source file
Supplier
Reference
Date
Currency
Total

Source file first, always. It costs one column and it is what lets anyone reading the sheet in six months open the document behind any row. Without it, a figure that looks wrong is unresolvable.

Name the remaining columns after what they mean to you, not after what any one document prints. Your documents will call the same field several different things; the point of choosing the column set is that you stop caring which.

Include a column that only some documents carry, and expect it to be partly empty. That is more useful than it sounds — a blank cell is a fact about the document, and a filter on blanks tells you which documents were missing something.

What the output looks like

Take three delivery notes from three different logistics providers. Each one prints its reference in a different place, calls the recipient something different, and formats the date in its own way. Ask for the same five columns from all three and you get:

Three delivery notes, five columns, one row each
Source fileCarrierReferenceDelivery dateGross weight
dn-4471.pdfNorthgate FreightNF-44712026-08-03412 kg
ship-2026-08-05.pdfCorrick LogisticsCL/882132026-08-0596 kg
delivery-note-9.pdfVantage DistributionVD-0001192026-08-11

Three things are worth noticing.

The Reference column holds three formats that no single pattern would have matched, and they are in one column anyway, because the question asked was "what is this document's reference" rather than "what is in the box at coordinates x, y".

The Delivery date column is one format across all three, which is what makes it sortable. The documents did not agree on a date format; the sheet does.

The last row's Gross weight is empty, because that delivery note does not state one. It is not zero and it is not estimated. An empty cell is correct, and it is the only answer that keeps the column safe to sum.

Doing it by hand, if the stack is small

For a handful of documents, hand transcription is still the right answer, and there is a way to do it that does not produce errors.

  1. Put every document in one folder and name the files so they sort in an order that means something.
  2. Build the header row first, including Source file, and freeze it.
  3. Fill one complete row per document, in folder order. Do not fill a column downwards across documents — that is the mistake that shifts a row and hides itself.
  4. Check the row count against the file count before you do anything else with the sheet.

If you find yourself merging the PDFs into one file first so you can scroll through them, notice what that means: the merge is not the task. Merge PDF is genuinely useful for assembling a document you are about to send, but merging in order to read and re-type is a sign that the stack has outgrown the manual method. The merge PDF guide says the same thing from the other direction.

Where the usual tools stop

A single-file PDF-to-Excel converter is the tool most people reach for first, and it is worth knowing exactly where it runs out.

It converts layout. The output is the PDF's visual structure approximated as cells — which is what you want if the PDF contains one big table you need verbatim, and not what you want if it contains a document you need four values from. Run a folder through it and you get a folder of approximations, each shaped differently, and the consolidation work is untouched.

Copy and paste has a related limit. PDF records text with positions, not with table structure, and the reading order stored in the file often is not the order on the page. Pasting a two-column layout regularly produces interleaved lines, and pasting a table produces a single column of values with no way to tell which row each came from.

Neither problem is a defect in those tools. They are answers to a different question.

The scan question, first

Before choosing anything, find out whether your PDFs contain text or pictures of text. A file produced by an accounting system contains text. A file that went through a scanner or arrived as a phone photograph contains an image, and the words on it exist only as pixels.

Extract Text from PDF answers this in your browser in a few seconds: open a representative file, and if text comes back, your stack is readable. If nothing comes back, the documents have to be recognised from the image first, which is a different and less certain job.

Check this before you plan the work, not after the first batch returns empty.

Converting the folder in one pass

The workflow this article describes is what ExtractToExcel is built to do. You name the columns you want — the set you chose above — hand over the documents, and each one comes back as a row in a single Excel workbook under your own headers.

Two specifics are worth stating plainly. There is no template to configure per supplier, because you are naming fields rather than mapping positions, so a document from a sender you have never dealt with needs no setup. And a value that is not printed on a document is returned as an empty cell rather than filled in with something plausible, for the reason the delivery note above shows: a plausible value in a currency or weight column is worse than a blank one, because it will be summed.

There is a full walkthrough of the workflow on multiple PDFs to one Excel, and if your documents are specifically invoices, extracting invoice data to Excel covers the column choices that matter for accounts payable.

Common questions

How many PDFs can go into one batch? There is a limit, and the current one is stated on the converter's drop zone and on the FAQ page rather than here, because it is a setting rather than a fixed property of the product. If your stack is larger than the limit, split it by period or supplier — the resulting sheets share a header row, so they stack.

Do all the documents have to be the same type? They have to be answerable by the same questions. Twenty suppliers' invoices are fine. Invoices mixed with contracts are not, because most of the columns would be empty for half the batch. Run them as two batches.

What if one document in the batch is unreadable? You want to know which one, by name, rather than getting a sheet with an unexplained gap in it. A batch that silently drops a document produces a total that looks complete and is not.

Can I get several rows from one document? Line items — many rows per document — are a different shape of output and need a different sheet layout. One row per document is what this workflow produces.

Is CSV or Excel the better output? Excel, if the values include anything that a spreadsheet might mangle on import: leading zeros in reference numbers, dates in a non-US format, or currency. CSV has no way to say "this column is text".

Start with the column set

If you take one thing from this: write the column list down before you start, put Source file at the front of it, and let cells stay empty when the document does not say.

Everything else — which tool, which method, by hand or in one pass — is a choice you can revisit. The column set is the thing that is expensive to change once there are rows underneath it.