Get a Scope
Operations

How to extract data from documents with AI

The short answer

To extract data from documents with AI, first classify each incoming file by type, then send it to a vision-capable model with a strict schema for that type, require the page number and source text for every extracted value, and check the results in code with format rules and cross-field checks. Documents that pass go straight to your database or spreadsheet, and the rest go to a review screen that shows each uncertain field next to the page it came from. A first document type usually takes two to four weeks.

What this automation does

Files arrive in a folder or inbox, and structured rows come out the other side, with every value traceable to the page it came from.

  1. Collect. Files land in a watched Google Drive, SharePoint or Dropbox folder, an email inbox, or an upload form. Each file gets an ID and its original is stored untouched.
  2. Split and classify. Multi-document PDFs, such as a packet with an application, a certificate and an ID, are split by page ranges. Each part is classified by type, for example W-9, certificate of insurance, bill of lading, rental application or purchase agreement.
  3. Extract per type. Each document goes to a vision-capable model with that type’s schema. For every field the model returns the value, the page number and the exact source text it read.
  4. Check in code. Format checks (EIN pattern, ZIP code, date), cross-field checks (policy expiration after effective date, weights summing to the total), lookups against your records, and a check that the quoted source text appears in the page’s text layer when one exists.
  5. Route. Documents with every field passing are written straight to the destination. Others go to a review queue with only the failing fields highlighted.
  6. Learn. Every reviewer correction is stored with the original value, building the error log you use to improve prompts and schemas.

When it is worth building

This is worth building when people spend hours a week reading documents and retyping values, the documents come in many layouts, and the data has a clear destination. Insurance certificates from dozens of carriers, shipping paperwork from many shippers and onboarding packets from many clients are good fits.

For invoices specifically, there is a dedicated invoice processing guide with accounting-specific checks. For freight paperwork, see bill of lading processing. If your documents are digital forms you control, skip extraction entirely and send form submissions straight to a database. And if you process one fixed form at very high volume, compare per-page pricing of cloud document processing services before building on a general model.

Architecture

LayerWhat we useWhy
IntakeGoogle Drive, SharePoint or Dropbox folder watch, or an email inboxMeets documents where they already arrive
Orchestrationn8nBuilt-in Drive, Dropbox, Airtable, Postgres and SharePoint nodes, with Microsoft Graph for anything the SharePoint node does not cover
Pre-processingPDF splitting, rotation fix and text-layer extractionRotated or merged scans are a leading cause of bad extraction
ClassificationClaude Haiku 5.5 or a small OpenAI GPT model on the first pagesCheap and fast, and routes each document to the right schema
ExtractionClaude Sonnet 5.5 or a comparable OpenAI GPT vision model with structured outputReads layouts, tables and scans and returns schema-valid JSON with page citations
ValidationCode step with per-type rulesFormat, arithmetic and lookup checks are exact and testable
ReviewAirtable interface or a small internal web app showing field and page side by sideReviewers fix one field in seconds instead of re-reading the whole document
DestinationPostgres, Airtable or your system of record’s APIStructured data where downstream work happens

How to build it

  1. Pick the first document type by volume times pain. One type done well beats five types done halfway.
  2. Build a labeled test set of 50 to 100 real documents with the correct value for every field, including the ugly ones: faxes, phone photos, rotated pages.
  3. Write the schema with field names, types, allowed formats and a one-line description of where the field usually appears. Mark which fields are required.
  4. Write the extraction prompt requiring page number and verbatim source text per field, and telling the model to return null rather than guess when a field is missing or unreadable.
  5. Write validation rules for every field you can check, and a source-text check against the page’s text layer.
  6. Run the test set and measure accuracy per field, not per document. A 95 percent document score can hide one field that is wrong a third of the time.
  7. Build the review screen, showing the page image next to only the fields that failed.
  8. Go live with review on every document, then allow straight-through processing for fields and document types that hold up on live traffic.

The downloadable starter template below covers folder intake, classification, extraction with page citations, validation and an Airtable review queue.

What breaks in production

  • Mixed packets. One scanned PDF holds four different documents. Without splitting, the model extracts fields from the wrong one. Classify page by page and group pages before extracting.
  • Helpful normalization. The model “fixes” a name’s spelling or reformats an ID number. Require verbatim values for identifiers and normalize in code afterwards, never in the prompt.
  • Ambiguous dates. 03/04/2026 is March 4 in the US and April 3 elsewhere. Return the raw string alongside the parsed date and flag any day value of 12 or less on documents from outside the US.
  • Tables spanning pages. Line items or schedules split across pages get truncated or duplicated. Extract the table across the full page range in one call and check row counts.
  • Low-quality scans. Faxes and phone photos produce plausible but wrong digits. Run a quick image quality check and send poor scans to review by default.
  • New layouts and versions. A carrier or agency updates its form. Track review rates per source and look at any source whose rate jumps.
  • Sensitive data in logs. Workflow execution logs store full extracted payloads by default. Mask sensitive fields or turn off payload logging for those steps.

Timeline and cost

One document type with a review queue and one destination typically takes two to four weeks. Lumeor builds document extraction workflows in the range of $4,000 to $12,000 per workflow. The low end is a single, consistent document type written to Airtable or Sheets. The high end covers mixed packets with splitting and classification, several document types, a custom review screen and writing to a system of record through its API. Model costs depend on page count and image quality, and are usually a small fraction of the review time saved.

How to measure success

  • Field-level accuracy on the labeled test set, re-run whenever the prompt, schema or model changes
  • Straight-through rate: share of documents written with no human touch, by document type
  • Review time per document, which should fall as reviewers only see failing fields
  • Corrections per field, from the error log, which shows exactly what to fix next
  • Cost per document, including model usage and reviewer time

Free starter template

Import a working n8n workflow that implements the core of this guide, then adapt it to your systems.

View the template Download JSON

Frequently asked questions

Is an LLM better than traditional OCR for document extraction?

For varied layouts, usually yes. Template-based OCR needs a template per layout and breaks when a form changes. A vision-capable model reads the document like a person would. For one very high-volume, fixed-layout form, a dedicated document processing service from a cloud provider can be cheaper per page and is worth comparing.

Can AI read handwriting and checkboxes?

Current models read neat handwriting reasonably well and messy handwriting poorly. Checkboxes and signatures are detectable but are a common source of errors on low-quality scans. Treat handwritten and checkbox fields as review-by-default until your own test set shows they are reliable.

How do you know which extracted values to trust?

Models do not give reliable confidence scores on their own. Trust comes from checks in code. The value matches its format, totals add up, dates fall in sensible ranges, IDs exist in your system, and the quoted source text actually appears on the cited page. Fields that fail any check go to review.

What about documents with Social Security numbers or other sensitive data?

Use API access, not consumer chat apps. OpenAI and Anthropic do not train on API data by default. Store sensitive fields encrypted, mask them in review screens and logs, and limit who can see the originals. Healthcare documents need HIPAA-compliant handling and a BAA with every vendor that touches them.

How many example documents do we need?

For setup, five to ten examples per document type to write the schema and prompt. For testing, 50 to 100 real documents per type with correct values filled in by a person. The test set matters more than the examples, because it is how you measure accuracy and catch regressions.

Where does the extracted data go?

Wherever your team works from. Common targets are Airtable or Google Sheets for small teams, a Postgres table behind an internal tool, or directly into a system of record such as a TMS, agency management system or CRM through its API.

Next steps

01 Get the free n8n template Import a working starter workflow. No email required. 02 Take the 5-minute AI readiness assessment Get a score and a recommended first project in your browser. 03 Get a written scope and estimate Tell us what you want to automate. We reply within two business days.

Keep reading