# Extract Data from Scanned PDF to Excel, Field by Field

- Author: FastBankConvert (https://www.fastbankconvert.com)
- Published: 2026-03-06
- Updated: 2026-03-06
- Category: Scanned and image statements
- Canonical: https://www.fastbankconvert.com/blog/extract-data-from-scanned-pdf-to-excel

> Extract data from a scanned PDF to Excel when you need a few fields: OCR the page, find labels such as Total or Date, and pull the values beside them.
To extract data from a scanned PDF to Excel when you need only a few fields, first run OCR so the page has real text. Then search that text for fixed labels such as "Total", "Date" or "Invoice No" and pull the value printed beside each one. A short set of Excel formulas does the pulling.

## Which fields can you extract from a scanned PDF page?

Fields that sit next to a fixed printed label are the easiest to extract from a scanned PDF. An invoice total follows the word "Total", a statement period follows "Statement period", and a reference number follows "Ref" or "Invoice No". The label is the anchor, and the value is whatever comes right after it.

Good candidates share three traits. The label is printed the same way on every document of that kind. The value sits on the same line as the label, or directly below it. And there is only one of it on the page. Typical examples:

- **Document numbers:** invoice, order, policy or account numbers.
- **Dates:** an issue date, a due date or a statement end date.
- **Single amounts:** a total, a balance due, an opening or closing balance.
- **Names:** a customer or vendor name printed after "Bill to" or "Account holder".

Fields that repeat, such as every line item on an invoice or every transaction on a statement, are a different job. They form a table, and a table needs row and column detection rather than label searches. That distinction decides which method you use, so settle it before you start.

## Giving the scanned PDF a text layer before extraction

A scanned PDF is a picture of a page, so it contains no searchable text until OCR adds a text layer. Field extraction depends on that layer: a formula cannot find the word "Total" in pixels. Run OCR first, then confirm the result by searching the PDF for a word you can see on the page.

Most PDF editors have an OCR or "recognize text" command, and many scanner apps run it automatically when they save a PDF. Online tools do the same in a browser, and [what an online image to Excel converter does to a photo](/blog/image-to-excel-converter-online) explains the trade-offs of that route. Whichever you use, the output you want for field extraction is plain text, one printed line per text line, in reading order.

The quality of the scan decides the quality of the text layer. A page scanned at too low a resolution gives labels with broken letters, and a broken label cannot be found. [The best DPI for OCR on statements and tables](/blog/best-dpi-for-ocr) covers which setting to use. Greyscale usually beats black and white for faint print.

Once you have text, copy it from the PDF and paste it into column A of a blank sheet. Each printed line should land in its own cell. If everything lands in one cell, paste into a text editor first and then copy from there, or use Excel's text import with no delimiters so each line becomes a row.

## How do labels such as Total or Date locate a scanned value?

A label locates a value in two steps. First, find the line of text that starts with the label. Second, take everything after the label on that line, trim the spaces and convert it to a number or date. Because the label stays fixed, the same steps work on every page of that kind.

The first step needs care, because a label can appear more than once. "Total" can be part of "Subtotal" or "Total due". Searching for lines that begin with the label, rather than lines that merely contain it, avoids most of those collisions. If two lines still begin the same way, decide which one you want and search from the bottom of the page, where totals usually sit.

The second step depends on how the label and value are separated. A colon, as in "Date: 03/14/2026", is the cleanest case: take the text after the colon. A run of spaces, as in "Total 142.35", is also manageable: take the text after the label and trim it. A value printed on the line below its label is the awkward case, covered in the section on misreads further down.

## Excel formulas that pull scanned PDF fields into columns

Excel's text functions turn the label search into formulas you can reuse. XLOOKUP with a wildcard finds the line that starts with the label, and TEXTAFTER returns what follows it. Wrap the result in VALUE or DATEVALUE and you have a real number or date, ready to sum or sort.

TEXTAFTER is available in Excel for Microsoft 365 and Excel 2024, and returns #N/A when it cannot find the delimiter, according to [Microsoft's TEXTAFTER function reference](https://support.microsoft.com/en-us/office/textafter-function-c8db2546-5b51-416a-9690-c7e6722e90b4). Older versions can do the same with MID and SEARCH, at the cost of longer formulas.

### A worked example

The lines below are example OCR output from a scanned invoice, pasted into A1:A10.

| Cell | OCR text |
| --- | --- |
| A1 | ACME OFFICE SUPPLY |
| A2 | Invoice No: 10482 |
| A3 | Date: 03/14/2026 |
| A4 | Bill to: Example Bakery LLC |
| A5 | Paper, 5 reams 42.50 |
| A6 | Toner cartridge 89.00 |
| A7 | Subtotal 131.50 |
| A8 | Tax 10.85 |
| A9 | Total 142.35 |
| A10 | Thank you for your order |

Now build a one-row summary. In D2, E2 and F2:

```
D2: =TRIM(TEXTAFTER(XLOOKUP("Invoice No*", A:A, A:A, "", 2), ":"))
E2: =DATEVALUE(TRIM(TEXTAFTER(XLOOKUP("Date*", A:A, A:A, "", 2), ":")))
F2: =VALUE(TEXTAFTER(XLOOKUP("Total*", A:A, A:A, "", 2), "Total "))
```

The last argument of XLOOKUP, 2, turns on wildcard matching, so "Total*" matches lines that begin with "Total". That is why F2 finds A9 and skips A7, where "Total" sits inside "Subtotal". The results are 10482, the date 14 March 2026 and 142.35.

Format E2 as a date. DATEVALUE reads the text using your computer's regional date order, so a US-style "03/14/2026" fails on a machine set to day-first dates. If that happens, split the text into day, month and year and use DATE instead.

Add one check before trusting the row. Subtotal plus tax should equal the total, so put `=VALUE(TEXTAFTER(A7,"Subtotal "))+VALUE(TEXTAFTER(A8,"Tax "))` beside F2. Here it returns 142.35, which matches. A mismatch means one of the three figures was misread.

For many documents, paste each one's OCR text into its own sheet with the same layout, and copy the summary formulas across. Each sheet then produces one row you can stack into a register.

## Misread labels and values split from their scanned field labels

A field comes back blank or wrong for one of three reasons: OCR misread the label, the value sits on a different line from its label, or the label appears twice. Each cause leaves its own trace, so the error tells you where to look on the scanned page.

### Misread labels

If OCR reads "Total" as "Tota1" or "TotaI", the wildcard search finds nothing and the formula returns an empty result or #N/A. Search the pasted text for the label with a shorter stem, such as "Tot", to see what OCR produced. Then either fix that line by hand or widen the search to match the misread. A label in bold or a coloured box misreads more often than plain text.

### Values on the next line

Some layouts print the label above the value, with "Total" on one line and "142.35" below it. TEXTAFTER returns nothing because there is nothing after the label on that line. Use the row of the label plus one instead: `=INDEX(A:A, XMATCH("Total*", A:A, 2)+1)`. Check a few documents to confirm the value is always on the next line, not two lines down.

### Two matches

When a label appears twice, as with "Date" for both an issue date and a due date, the search returns the first one from the top. If you want the second, use "Due date*" as the label, or search from the bottom with XLOOKUP's search mode set to -1.

Handwritten values deserve their own warning. A printed form with a total written in pen gives you a clean label and an unreliable value, and [what OCR can realistically read in handwritten PDF pages](/blog/convert-handwritten-pdf-to-excel) explains why a person should check those by eye.

## When field extraction from a scanned PDF is the wrong job

Field extraction is the wrong job when you need every row of a table rather than a few labelled values. A bank statement is the clearest case. You could pull the opening and closing balances with labels, but the transactions in between are a repeating table, and label searches cannot rebuild it line by line.

Signs you need full table conversion instead:

- You need more than a handful of values per page.
- The values repeat in rows, each with its own date and amount.
- You want to check the values against each other, as with a running balance.

For statements, the target layout is a transaction list with one row per line, which [turning a PDF bank statement into a clean Excel transaction list](/blog/pdf-bank-statement-to-excel) sets out column by column. FastBankConvert is built to produce that list from statement PDFs, scanned ones included, though scans take longer than digital files. It is getting ready to open, and [Get started](/get-started) puts you on the list.

Field extraction stays the right tool for summary work: building a register of invoice totals, collecting statement end balances for a year, or pulling a policy number from each of fifty scanned letters. In those cases, a few formulas and a pasted text layer will beat any full conversion.