How to Use LLMs for Information Extraction from PDFs, Emails, and Forms

Overview

If your team needs to pull invoice numbers from PDFs, contact details from emails, or structured fields from forms, LLM information extraction can save time compared with manual entry or brittle rule-only systems. The tradeoff is that LLMs are probabilistic. They can infer context well, but they can also omit fields, misread formatting, or return plausible-looking values that were not clearly present in the source.

The most useful way to think about document extraction is not “ask the model to read a file,” but “build a document parsing workflow with clear stages.” That workflow usually includes five parts:

• Ingestion: collect the source document and its metadata.
• Preprocessing: convert PDFs, emails, scans, and forms into clean machine-readable text and layout signals.
• Extraction: use structured output prompts to map content into a defined schema.
• Validation: check required fields, formats, confidence signals, and business rules.
• Handoff: send validated results to downstream systems or queue exceptions for human review.

This approach works well across several common use cases:

• Extract data from PDFs with AI for invoices, contracts, shipping documents, or statements.
• Email data extraction AI workflows for support requests, lead routing, or order updates.
• Form extraction with LLM logic for intake forms, onboarding packets, or semi-structured submissions.

It also helps you avoid a common implementation mistake: mixing OCR, prompt design, business logic, and QA in a single prompt. When those layers are separated, you can improve one without destabilizing the others.

For teams already building prompt-heavy workflows, this pattern also connects well to broader AI development practices such as prompt versioning, test sets, and schema validation. If you are standardizing prompts across teams, pair this tutorial with How to Build a Prompt Library Your Team Will Actually Reuse and Prompt Versioning: How to Track Changes, Roll Back Failures, and Ship Safely.

Step-by-step workflow

Here is a practical workflow for building extraction pipelines that can grow over time instead of collapsing under edge cases.

1. Start with a narrow document family

Do not begin with “all PDFs” or “all incoming emails.” Start with one document family that has a clear business purpose and a stable output. Examples include vendor invoices, customer onboarding emails, reimbursement forms, or proof-of-delivery PDFs.

For that document family, write down:

• The fields you need.
• Which fields are required.
• What counts as acceptable ambiguity.
• What downstream system will consume the output.

A narrow scope improves prompt engineering because the model can focus on a smaller set of extraction decisions. It also makes testing easier.

2. Define the target schema before writing prompts

Many extraction projects fail because the prompt is written before the output shape is defined. Reverse that order. Create a schema first.

A simple schema for invoice extraction might include:

{
  "document_type": "invoice",
  "invoice_number": "string | null",
  "invoice_date": "YYYY-MM-DD | null",
  "vendor_name": "string | null",
  "currency": "string | null",
  "total_amount": "number | null",
  "po_number": "string | null",
  "line_items": [
    {
      "description": "string",
      "quantity": "number | null",
      "unit_price": "number | null",
      "line_total": "number | null"
    }
  ],
  "warnings": ["string"],
  "evidence": {
    "invoice_number": ["snippet"],
    "total_amount": ["snippet"]
  }
}

Two details matter here. First, allow nulls instead of encouraging guessed values. Second, include evidence snippets or supporting text spans where practical. Evidence makes review faster and helps you debug prompt failures.

If you need help designing stable machine-readable outputs, see Structured Output Prompts for JSON: Patterns, Validation Tips, and Common Fixes.

3. Normalize the input before it reaches the LLM

LLMs perform better when the input is clean. Your preprocessing path will vary by source type:

• Text PDFs: extract text directly and preserve page boundaries, headings, and tables when possible.
• Scanned PDFs: run OCR first, then keep both the recognized text and page coordinates if available.
• Emails: separate subject, sender, timestamp, body, signature block, forwarded thread, and attachments.
• Forms: preserve field labels, checkbox states, handwritten uncertainty flags, and section headings.

Normalization is where many quality gains happen. Some practical preprocessing habits:

• Remove repeated headers and footers that add noise.
• Mark page numbers clearly.
• Keep tables in a layout-aware representation if your tooling supports it.
• Split long threads or appendices that are not relevant to the extraction goal.
• Label attachments separately rather than merging everything into one text block.

This is especially important when you extract data from PDFs with AI. A clean OCR layer usually improves outcomes more than endlessly rewriting prompts.

4. Classify the document before extracting fields

Before field extraction, ask a smaller model or a lightweight classification prompt: “What type of document is this?” This lets you route each input to the correct extraction schema and prompt.

A useful classification layer can answer questions like:

• Is this an invoice, receipt, statement, or contract?
• Is this email asking for support, renewal, cancellation, or status update?
• Is this form complete, partial, or duplicated?

Classification reduces prompt complexity and keeps extraction instructions specific. One prompt per document family is usually easier to maintain than one massive universal prompt.

5. Use a structured extraction prompt with explicit rules

Your extraction prompt should be precise, narrow, and deterministic in tone. It should define the task, the schema, the treatment of uncertainty, and the output rules.

A durable system prompt pattern looks like this:

You extract structured data from business documents.
Return valid JSON only.
Use the provided schema exactly.
If a value is not present or not readable, return null.
Do not infer missing facts.
For each populated critical field, include a short supporting evidence snippet.
If the document appears to belong to a different document type, add a warning.

Then pass the document text and the schema in the user message. You can also add a few-shot block with one or two realistic examples if the document family has recurring ambiguity. For guidance on that technique, see Few-Shot Prompting Examples That Actually Improve Accuracy.

For email data extraction AI use cases, it often helps to instruct the model to ignore quoted reply chains unless a field is only present there. For forms, tell the model how to handle unchecked boxes, crossed-out values, and illegible entries.

6. Validate the output outside the prompt

Never rely on the model alone to police its own output. Once the JSON is returned, validate it with code.

Validation layers usually include:

• Schema validation: required keys, data types, and enumerations.
• Format validation: dates, email addresses, phone numbers, currency codes.
• Business rules: totals add up, issue date is not after due date, state code is valid, order ID matches internal format.
• Cross-field checks: sender domain aligns with customer record, form section matches selected category.

If validation fails, do not immediately discard the result. Route it into one of three paths:

• Automatic repair for simple formatting issues.
• Second-pass extraction with a narrower corrective prompt.
• Human review for substantive ambiguity.

This is where practical AI tutorials often differ from demos: production quality comes from validators and fallback paths, not just better prompts.

7. Add confidence and review thresholds

LLMs do not produce confidence scores in a universally reliable way, so create your own operational confidence signals. Examples include:

• Number of required fields successfully extracted.
• Whether evidence snippets were found for critical fields.
• Whether the output passed all validation rules.
• Whether the document classifier and extractor agreed on document type.
• Whether OCR quality was poor.

These signals let you decide when to auto-accept a result and when to send it to review. In many document parsing workflows, this thresholding matters more than squeezing a small accuracy gain out of one prompt revision.

8. Build an error log and test set from real failures

Keep examples of failed or messy documents. Over time, those become your extraction test set. Label why each one failed: OCR noise, missing page, unusual template, handwritten field, multiple totals, conflicting dates, forwarded email chain, or vendor-specific terminology.

A good prompt testing framework for extraction should evaluate:

• Field-level accuracy.
• Complete-record pass rate.
• Null-vs-hallucination behavior.
• Cost and latency.
• Reviewer burden.

For a broader testing method, review Prompt Testing Framework: How to Evaluate Quality, Consistency, and Cost.

Tools and handoffs

The best extraction stack is usually modular. You do not need one tool to do everything. You need a clean handoff between stages.

A practical stack

• Document intake: email inbox, upload form, API, or cloud storage trigger.
• Preprocessing: OCR engine, PDF text parser, email parser, attachment handler.
• Classification: rules, embeddings, or an LLM prompt.
• Extraction: LLM with structured output support.
• Validation: JSON schema validator and business-rule checks.
• Routing: database, CRM, ERP, ticketing system, or review queue.

Keep the interfaces between these steps explicit. For example, define one internal JSON object for normalized document text and metadata, and a separate one for extracted business fields. That way, you can change OCR vendors or swap LLMs without rewriting everything downstream.

Recommended handoff design

At minimum, pass the following between stages:

• Input metadata: source, timestamp, sender, file type, document ID.
• Normalized content: cleaned text, page blocks, sections, attachment references.
• Model instructions: schema version, prompt version, extraction mode.
• Output record: extracted fields, evidence, warnings, validator status.
• Audit data: model name, run ID, processing time, reviewer decision.

Auditability matters. It helps you compare prompt engineering changes over time and trace regressions when a model update or parser change introduces new errors.

Security and prompt safety considerations

Documents can contain untrusted text, especially in emails and attachments. Treat them as hostile inputs. If you feed raw content into an LLM, make sure your prompt makes the model ignore any instructions embedded in the document itself. Also isolate system instructions from document text and keep tool permissions narrow.

For a broader treatment of these risks, read Prompt Injection Prevention Checklist for LLM Apps.

Choosing the right model strategy

Not every extraction problem needs the same model or architecture. In practice, you might use:

• A smaller model for classification and simple field extraction.
• A larger model for complex forms, long PDFs, or reasoning-heavy edge cases.
• RAG only if you need external reference data to disambiguate extracted values.
• Traditional rules or regex for high-confidence postprocessing of known formats.

If you are evaluating model approaches, RAG vs Fine-Tuning vs Prompting: Which Approach Fits Your Use Case? is a helpful companion piece. And if you are comparing general-purpose LLMs for workflow fit, see ChatGPT vs Claude vs Gemini for Prompt Engineering Workflows.

Quality checks

A working extractor is not the same as a trustworthy one. Quality checks should be built into the process from the beginning.

Use field-level acceptance criteria

For each field, define what counts as correct. “Close enough” is not enough for operational systems. For example:

• Invoice number: exact string match after normalization.
• Date: normalized to ISO format and tied to the right label.
• Total amount: final payable total, not subtotal or tax line.
• Email intent: mapped to an approved category list.

This makes it easier to compare versions of prompts and models.

Prefer null over invention

One of the most important prompt design best practices for extraction is to reward abstention. If the source is unclear, null is usually safer than a guess. This should be reflected in prompts, validators, and reviewer guidance.

Review evidence, not just values

When possible, require the model to return a short supporting snippet for important fields. Reviewers can then confirm whether the extracted value was anchored in the source. This is especially useful for PDFs with repeated totals or emails with long reply chains.

Track drift by document subtype

Do not measure only average accuracy. Break performance down by subtype: scanned vs native PDF, short vs long email, old template vs new template, typed vs handwritten form. Drift usually shows up first in one segment.

Measure operational outcomes

Useful quality metrics often include:

• Auto-accept rate.
• Reviewer correction rate.
• Time saved per document.
• Rate of downstream processing failures.
• Top recurring error categories.

These metrics tell you whether the workflow is truly reducing effort or just moving it around.

If your team is operationalizing prompt libraries, consider storing extraction prompts, schemas, examples, and known failure modes together. This keeps the workflow maintainable and easier to hand off across teams.

When to revisit

The right extraction workflow is never fully finished, but it should be easy to update. Revisit your pipeline when tools change, when model behavior shifts, or when documents evolve.

Update triggers to watch for

• A new PDF layout or vendor template appears.
• Email formatting changes because of a new platform or CRM.
• Forms add fields, remove fields, or change labels.
• Your OCR layer starts producing lower-quality text.
• A downstream system requires stricter formats.
• A model or platform feature changes structured output behavior.

A simple review routine

1. Sample a batch of recent documents every month or quarter.
2. Compare extraction outputs against a human-labeled subset.
3. Group failures by root cause, not by symptom.
4. Decide whether the fix belongs in preprocessing, prompting, validation, or routing.
5. Version the update and retest against your saved edge-case set.

This review cycle keeps the workflow durable. It also prevents a common anti-pattern in AI development: reacting to every failure with a larger prompt instead of improving the system boundary where the problem actually lives.

What to do next

If you are building your first document parsing workflow, start with one document family, one schema, and one validator. Gather real failures, then expand slowly. If you already have extraction in production, review whether your pipeline separates normalization, extraction, and validation clearly enough to support change.

For teams maturing their broader AI workflow automation, the next practical steps are to formalize prompt tests, version schemas and prompts together, and build a reusable prompt library for extraction patterns. Related reads include Prompt Testing Framework: How to Evaluate Quality, Consistency, and Cost, Prompt Versioning: How to Track Changes, Roll Back Failures, and Ship Safely, and AI Meeting Notes Automation: Prompts, Workflows, and Review Checkpoints.

The durable lesson is simple: treat LLM extraction as an editable system, not a single clever prompt. That mindset will help you handle new PDFs, noisier emails, updated forms, and future model changes without rebuilding from scratch.