Extracting data from hundreds of PDFs into Excel (and why a converter is not enough)

Adapted from an article originally published in French on closiqode.com.

Getting data out of one PDF into Excel is a copy-paste job. Getting it out of hundreds of PDFs is a pipeline problem: identify each document, extract the text, structure the useful fields (one column per field), then check the result.

A plain PDF-to-Excel converter breaks down as soon as the files are scanned, badly framed or laid out differently. And there is one rule I never drop: every extracted value must stay linked to the document it came from.

A PDF is not necessarily a data source

Two documents can look identical on screen. Technically, the first one contains selectable text; the second one is just an image. A third one mixes text, tables, stamps and scanned pages. So processing starts by classifying the files, not by running the same extractor blindly over the whole folder.

OCR turns areas of an image into usable characters. The French National Library (BnF) points out that its quality depends on contrast, deskewing, print defects and layout complexity. And recognizing the words correctly does not guarantee that the right value was attached to the right field.

A first triage can be as simple as checking whether each page has a text layer. As an example, with PyMuPDF:

# Example: route each page to native extraction or OCR
import fitz  # PyMuPDF

def route_pages(path, min_chars=50):
    doc = fitz.open(path)
    for page in doc:
        text = page.get_text().strip()
        yield page.number, "native" if len(text) >= min_chars else "ocr"

The threshold is a heuristic, not a rule: a scanned page with a stamp may carry a few characters, and a native page may be almost empty. The point is to make the routing decision explicit and logged.

Where manual processing hits a wall

The problem rarely shows up with ten files. It becomes visible when a team opens hundreds of reports, invoices, technical sheets or regulatory files every week. People know exactly what to look for, but their time goes into navigating, copying, pasting and repeating the same checks.

At that point, the goal is not "read every PDF". You need to define a useful output: one row per document in a spreadsheet or a database, an alert on an inconsistency, a list of references, a status to review. Without that decision, the project automates noise.

So before talking about tools, write down:

• the fields you need;
• their possible formats;
• the known exceptions;
• the checks each value must pass;
• the expected result.

A traceable pipeline, step by step

1. Inventory: formats, languages, scans, tables and known variants.
2. Route: native extraction for text, OCR for images, specific processing for complex tables.
3. Normalize: dates, units, references and missing values.
4. Apply the business rules: consistency checks, thresholds and exceptions.
5. Trace: keep the document, page and zone each value came from.
6. Send ambiguous cases to a person: anything below a confidence threshold goes to human review.

In practice, an extracted value is not just a cell. It is a small record, for example:

{
  "source_file": "report-0412.pdf",
  "page": 3,
  "field": "delivery_date",
  "raw_value": "12/04/26",
  "normalized_value": "2026-04-12",
  "method": "native_text",
  "status": "needs_review",
  "review_reason": "day/month order inferred from document locale"
}

The spreadsheet is then only a view over these records. When someone asks where a number comes from, the answer is the file, the page and the rule that accepted it.

Pick the processing path per document

Document observed	First approach	Risk to test	What to keep
PDF with selectable text and a stable layout	Native extraction with position or label rules	Mixed columns, repeated headers, value attached to the wrong block	Value, page, zone and source file
Clean scan of a known form	OCR, then extraction of the expected fields	Look-alike characters, misread checkbox, skewed page	Value, confidence level and image of the zone
Documents in varied formats	Classification first, then processing per family	One model works on frequent cases but fails on a rare variant	Detected family, processing version and reason for review
Complex table or degraded document	Specialized extraction with targeted review	Structure rebuilt in a plausible but wrong way	Extracted cells, coordinates and the untouched original

Test this routing on a sample that also contains the bad scans and the rare layouts. A good overall average must not hide the one document family where the errors concentrate.

Real example: a value present at the wrong level

Not all PDFs look alike. Some contain real text, others are scans, tables move around, and the same information can appear in several forms. But the harder problem is elsewhere: detecting a value is not always enough. You need to know what it means in the business.

In a project I built for an engineering firm, an important piece of regulatory information could be declared at the level of a component while remaining invisible in the main product information. The value was in the PDF, but reading it at the wrong level would have produced a wrong row in the spreadsheet.

The client deliberately included this case in a validation document, without telling me in advance. The tool caught it.

That is why document extraction is not just "reading text". The system has to reproduce the rules that make the information useful: read each file, then check each value against the business rules.

Measure quality in separate layers

A serious check distinguishes at least four results:

• Was the document opened and every page processed?
• Was the text recognized correctly?
• Were the fields attached to the right context?
• Did the business rule produce the right decision?

This separation avoids a false sense of precision. An OCR confidence score measures recognition; it does not prove that the extracted value answers the business question.

To validate, build a ground truth: a representative batch whose expected results have been checked by hand. Add difficult cases, compare the outputs, and measure the ability to find the information separately from the ability to interpret it correctly.

FAQ

Can scanned PDFs be processed?
Yes, with OCR. Scan quality remains decisive, and critical values must be checked.

Do you need generative AI?
Not systematically. Deterministic extraction is often the better choice for stable formats. AI can help with variable wording or layouts, as long as there is validation and traceability.

How do you handle errors?
The system must flag unread documents, missing fields and uncertain results. A silent gap is more dangerous than an alert.

Where do you start?
Pick a single document type, define the expected fields and prepare a representative sample. A first test then gives you a realistic view of feasibility and exceptions.

The spreadsheet is the easy part

The real work is being able to say, for every cell, which page it came from and which rule it passed.

---

I am Fabien Kost, an independent developer in France (ClosiQode). I build document data extraction tools that read every file, check every value against business rules and keep a link to the source page. More on how I approach document extraction (in French).

Sources (in French): BnF, text conversion techniques and formats and BnF digitization standards.