Whole-document conversion is the wrong tool for most document work. You rarely want a PDF as a spreadsheet; you want six values out of it. The difference between those two asks is the difference between a page of approximated cells and a row you can sum.
This is about the six values: how to specify a field so that it has one answer, what to do when a document does not print it, and how to tell afterwards that you got the right thing.
A field is a question, not a position
There are two ways to say what you want out of a document, and they behave completely differently.
By position. "The value in the box 140mm from the left, 60mm from the top." This is how template-based extraction works, and it is exact — right up until a supplier changes their letterhead, adds a line to their address, or sends a two-page invoice where the total has moved to page two. Then it silently returns the wrong thing, because a coordinate is always occupied by something.
By meaning. "The total amount payable on this invoice." This is a question about the document rather than about the paper, and it survives the letterhead change, because the question did not depend on where the answer was printed.
Almost everything in this article follows from preferring the second. A field is a question you could ask a competent human holding the document, and if a human would have to ask you what you meant, so will anything else.
Write the field list before you look at a document
The field list is the specification of the whole job. Write it first, from what you need downstream, and not from what the document happens to print — otherwise you end up with whatever the first supplier's layout suggested.
Source file
Supplier name
Document reference
Document date
Currency
Net amount
Tax amount
Gross amount
Source file belongs at the front of every such list. It costs one column and it is the only thing that lets anyone reading the sheet later open the document behind a row. A figure that looks wrong and cannot be traced back is a figure that has to be re-done from scratch.
Then check each remaining field against three tests.
The three tests a field name has to pass
One answer per document. If a document could reasonably produce two answers, the field is not a field yet. "Date" fails this test on nearly every business document: invoice date, due date, delivery date, order date, date printed. Say which. "Amount" fails it for the same reason — net, tax, gross, amount paid, balance outstanding. The fix is always the same and always cheap: make the name longer.
Independent of any one layout. "The number in the top right" is not a field. "Invoice number" is. If a field name mentions where something appears, it will break on the next sender.
Stable in type. Decide what kind of value a field holds and keep it that way
down the whole column. A column holding 1,240.00 on one row and 1.240,00 on
the next, or 04/08/2026 and 2026-08-04, is not sortable and not summable, and
nothing about the sheet will warn you. Normalise on the way in: dates as
YYYY-MM-DD, amounts as plain numbers with a separate currency column, nothing
carrying a unit in the same cell as its figure.
That last one has a practical consequence worth stating separately: keep the currency in its own column, never in the amount. An amount that has been converted at an unrecorded rate cannot be reconciled against the payment that settles it.
Fields that look simple and are not
Four come up constantly.
The supplier name. Three candidates appear on most invoices — the trading name in the logo, the legal entity in the small print, and the remittance name on the payment block. They are frequently different. Pick the one that matches whatever you reconcile against, and say so in the field name: "supplier legal name" rather than "supplier".
The reference. Different senders call it an invoice number, a document number, a tax invoice reference or just a number, and some print two — theirs and your purchase order. If you need both, those are two fields, and extracting purchase orders to Excel is about precisely the matching problem that follows.
The total. On a document with tax, there are at least three totals and they are all correct answers to the word "total". Name the one you mean.
Anything repeating. Line items are not a field at all. A field has one answer per document; a line table has an unknown number, which is a different output shape entirely — see extracting invoice line items for the layouts that hold it.
An absent field must stay absent
This is the rule that matters most and it is the easiest one to break.
If a document does not state a value, the cell stays empty. Not zero, not the previous document's value, not something inferred from the rest of the page. An empty cell is a true statement about the document; a plausible figure is a guess that will be summed alongside real ones and will never be distinguishable from them again.
It is also more useful than it looks. Filter a column on blanks and you have a list of exactly the documents that were missing something — which is a question people ask constantly and normally answer by re-reading the whole stack.
So deliberately include fields that only some documents carry. A partly empty column is information. A column that has been filled in to look complete is not.
Check the document has text at all
Before planning any of this, find out whether your PDFs contain text or pictures of text. A file produced by an accounting system contains text. A scan or a phone photograph contains an image, and the words on it exist only as pixels — no amount of field specification reaches them.
Extract Text from PDF answers this in your browser in a few seconds: open a representative document, 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 — converting scanned PDFs to Excel covers it.
Do this before you plan the work, not after the first batch returns empty.
Checking the result without re-reading everything
Five checks catch nearly everything, and none requires opening a document.
- Row count against file count. Equal, or you know which documents are unaccounted for.
- Blanks per column. A column that is 90% empty is usually a field that was specified wrong rather than a stack that does not state it.
- Arithmetic that should hold. Net plus tax equals gross, on every row, as a formula. The rows where it does not are your entire review list.
- Dates in range. Sort the date column. Anything outside the period you expected is a misread date or a misnamed field — a document date read where the due date was wanted shows up here immediately.
- One spot check per sender. Open one document from each distinct source and compare it with its row. Errors in this work are systematic by sender, not random, so one document per sender finds almost all of them.
Other ways to do it
Copy and paste. Fine for one document, and understand its limit: a PDF stores text with positions rather than structure, and the reading order in the file is often not the order on the page. A two-column layout regularly pastes as interleaved lines.
A script with regular expressions. Genuinely good when the documents all come from one system and that system never changes — a utility bill, a payroll report. It is a position-based approach wearing different clothes, though: it matches what is around a value, so a layout change breaks it, usually silently.
Template tools. You draw boxes on a sample document once, and every matching document is read fast and cheaply. Excellent for high volume from a fixed set of senders; a maintenance job with a long tail of senders, because every new layout needs a new template.
Asking for fields by name. No per-sender setup, because you are naming meanings rather than positions, so a document from a sender you have never dealt with needs nothing configured. This is the approach this article describes and the one ExtractToExcel implements: you name the fields, hand over the documents, and each comes back as one row under your own headings. How it works sets out the mechanics.
None of these is the right answer for every case. The useful distinction is whether your senders are few and fixed, or many and changing.
Common questions
How many fields should I ask for? As many as you need and no more, but the marginal cost of one more is low and the cost of re-running the batch later is not. Include the ones you are unsure about.
What if different senders call the same thing different names? That is the point of naming fields by meaning. You choose the column name; their wording is their problem.
Can a field appear twice on one document? If it genuinely does — two dates, two references — then you wanted two fields. Name both.
Does each sender's layout need setting up first? Not with the by-meaning approach. That is the main practical difference between it and template tools.
What about documents that are not invoices? Nothing in this article is about invoices specifically. Delivery notes, purchase orders, lab reports, inspection certificates and bank statements all work the same way: decide the questions, ask them of every document, keep the blanks.