What Is Entity Extraction? Definition and Guide

TL;DREntity extraction pulls named things — people, dates, amounts, organizations — out of unstructured text and labels each one. A developer's guide to how it works on PDFs.

Direct answer: Entity extraction (also called named entity recognition, or NER) is the process of finding specific, labeled things inside unstructured text — people’s names, company names, dates, dollar amounts, addresses, product codes — and tagging each one with its type. It’s the step between “I have text” and “I have data”: a PDF invoice extracted as plain text is still unstructured until entity extraction pulls out the vendor name, invoice number, line-item amounts, and due date as distinct, typed fields.

What entity extraction actually does

Given a sentence like “Acme Corp invoiced $4,200 on March 3, 2026, due within 30 days,” entity extraction produces a set of labeled spans:

ORGANIZATION: Acme Corp
MONEY: $4,200
DATE: March 3, 2026
DURATION: 30 days

That’s the whole job. The text stays the same; what changes is that a machine can now query “what’s the amount” or “who’s the vendor” instead of a human reading the sentence to find out.

Two approaches dominate:

Rule-based / regex — fast, free, and reliable for entities with a fixed shape: dates, phone numbers, invoice numbers, currency amounts. Breaks down on anything with natural variation, like company names or addresses.
Model-based (NER models or LLMs) — a trained model reads the surrounding context to decide what a span is. Handles the variation rule-based methods miss (“was that ‘Amazon’ the company or the river?”) at the cost of being slower and needing more compute.

Most production pipelines use both: regex for the fields with a predictable format, a model for the fields that need context to disambiguate.

Where it sits in a document pipeline

Entity extraction runs after text extraction, not instead of it:

PDF → text/markdown — pull the raw content out of the file. This is what PDF extraction does.
Text → structure — group the text into meaningful units (paragraphs, table rows, sections). This is layout analysis.
Structure → entities — this step. Label the specific values inside that structure.
Entities → schema — map the labeled entities onto a target format (an invoice JSON schema, a database row, a search index).

Skipping straight from PDF to entities without the intermediate structure step is where most naive extraction pipelines lose accuracy — an amount pulled out of the wrong table row is a correctly-typed entity with the wrong value, and nothing in the entity label itself catches that.

Entity extraction on real documents

Clean, well-formatted text is the easy case. Real documents make entity extraction harder in three specific ways:

Tables — a dollar amount’s meaning depends on which row and column it’s in (“Subtotal” vs “Tax” vs “Total”). Extracting the number as a MONEY entity without preserving its table position throws away the information that made it useful.
Scanned pages — entity extraction runs on whatever text OCR produced, so an OCR misread (“$4,2OO” instead of “$4,200” — a letter O for a zero) becomes a wrong entity with no obvious signal that it’s wrong.
Multi-page context — an entity like “the Contractor” on page 4 might resolve to a name defined on page 1. Extracting page-by-page without carrying that context forward produces technically-correct but practically-useless entities.

This is why entity extraction on PDFs works best downstream of an extraction pipeline that preserves table structure and flags low-confidence text, rather than running directly on raw OCR output. A confidence score on the source text is the difference between an entity you can trust and one you have to manually verify.

Common entity types by document

Which entities matter depends entirely on the document type. Generic NER models ship with a fixed set of general categories (person, organization, location, date, money), but production document pipelines usually need document-specific types on top of that baseline:

Document type	Entities that matter	Rule-based or model-based
Invoices	vendor name, invoice number, line items, subtotal, tax, total, due date	Mostly rule-based — fixed formats
Contracts	party names, effective date, term length, governing law, signature blocks	Mixed — dates are regex, party names need context
Resumes	candidate name, skills, employers, dates of employment, degrees	Mostly model-based — high format variance
Receipts	merchant, date, items, payment method, total	Mostly rule-based
Medical records	patient name, diagnosis codes, medication names, dosages	Model-based, often with a domain-specific NER model (medical entities aren’t in general-purpose training data reliably)

The pattern holds across all five rows: the more standardized the document format, the more of the extraction regex handles alone; the more free-form the writing, the more it depends on a model reading context.

Entity extraction vs. classification

It’s easy to conflate the two, but they answer different questions. Classification asks “what kind of document is this?” — a single label for the whole document (invoice, contract, resume). Entity extraction asks “what specific values are inside this document?” — many labeled spans within it. A real pipeline usually does both in sequence: classify the document first to pick the right entity schema, then extract entities using that schema. Running entity extraction with the wrong schema — pulling “invoice” fields out of a document that’s actually a contract — produces entities that are confidently wrong rather than obviously missing.

Example: extracting entities from an invoice

import pdfmux

result = pdfmux.extract_structured(
    "invoice.pdf",
    schema="invoice"  # Built-in preset
)
# Returns: vendor, invoice_number, date, line_items[], total, tax

Using schema="invoice" runs pdfmux’s built-in invoice profile, which combines table-aware extraction with the regex and model-based entity rules for the fields invoices reliably contain. For fields outside a predefined schema, a general vision-LLM backend (see Claude PDF parsing for when that’s the right tool) can extract arbitrary entities from a prompt instead of a fixed schema, at the cost of losing the deterministic guarantees a schema gives you.

PDF Extraction — pulling raw content out of a PDF, the step before entity extraction
Table Extraction — structuring tabular data, which entity extraction depends on for table-context accuracy
Document Intelligence — the broader field entity extraction is one piece of

FAQ

What’s the difference between entity extraction and named entity recognition (NER)?

None in practice — they’re the same task. “NER” is the term more common in academic NLP; “entity extraction” is more common in applied/product contexts. Some people use “entity extraction” more broadly to include custom, domain-specific entity types (invoice numbers, SKUs) beyond the standard NER categories (person, organization, location, date).

Can entity extraction work on scanned PDFs?

Yes, but accuracy is capped by OCR quality — entity extraction runs on the text OCR produced, so an OCR error becomes an entity error with no distinguishing signal. Route scanned pages through an OCR step that reports per-page confidence, and treat entities extracted from low-confidence pages as unverified.

Do I need a machine learning model for entity extraction, or is regex enough?

Depends on the entity. Dates, amounts, phone numbers, and other fixed-format values are reliably caught with regex, no model needed. Names, organizations, and anything requiring context to disambiguate need a model. Most real pipelines combine both rather than picking one.