Extracting Information from Documents: Forms, Invoices, and Tables

A great deal of everyday work is really a copy-and-paste job with consequences. An invoice arrives as a PDF; someone retypes the vendor, the amount, and the due date into a spreadsheet. A stack of forms describes suppliers in slightly different layouts; someone pulls the name, tax number, and address from each. Done by hand, it is slow and error-prone. Done by machine, it is fast — and error-prone in different ways.

This article covers how to use AI to extract structured information from documents, where the approach beats older tools, and why verification is not optional. It pairs with our Summarizing Long Documents article and sits within the broader Document Workflows guide.

What extraction means

Extraction is the task of pulling specific facts out of a document and placing them into a defined structure — a field, a row, a database column. It is different from summarizing, which produces prose. Extraction produces data.

From unstructured to structured

Most documents are written for humans, not machines. A name might appear in a header, a footer, or both. A total might be labeled "Amount due," "Total," or "Balance." Tables often have merged cells and footnotes. Extraction is the work of identifying which piece of text answers which field, no matter how the document is arranged.

Why AI is used for this

Older extraction tools rely on fixed positions or patterns: the invoice number is always after the word "Invoice." AI models read documents more flexibly, which helps when layouts vary. The tradeoff is that a flexible reader can also be confidently wrong in ways a rigid template would never be.

Fields you might extract

• Invoices: vendor name, invoice number, invoice date, due date, line items, subtotal, tax, total, currency.
• Forms: applicant name, address, contact details, identifiers, dates, checkboxes.
• Contracts: parties, effective date, term, renewal conditions, obligations, governing region.
• Tables: each row's values mapped consistently to the same columns.

A sample extraction, and its errors

Suppose you ask a tool to pull three invoices into a table. A plausible output might look like this:

The table is tidy and easy to read. Now check it against the source. The third row is the interesting one: in the original, Northwind's total is $1,240.00 as well, and the tool has transposed two digits into $1,204.00. Nothing about the sheet looked wrong; the swap was invisible. This is the characteristic failure of automated extraction: a plausible value that is subtly incorrect.

Designing the extraction

Most extraction quality is decided before the tool runs. A few decisions up front prevent a lot of cleanup later.

Define every field and its format

Write down the columns you want and the format for each: dates as YYYY-MM-DD, currency with two decimals and a currency code, numbers without thousands separators. A precise target makes deviations obvious during review.

Say what to do when a field is missing

Instruct the tool to leave a field blank or write "not found" rather than guess. Left unspecified, a model may fill a gap with a plausible value — the worst outcome for data you will rely on.

Extract in consistent units

Decide whether amounts include tax, how to handle multiple currencies, and how to treat credit notes. Ambiguity in the target format produces inconsistent data that is harder to verify.

A reliable extraction workflow

1. Choose a bounded batch. Start with a small set of representative documents, not the whole archive.
2. Define the fields and formats. Write the exact schema before extracting anything.
3. Instruct the tool to flag uncertainty. Require "not found" for missing values instead of a guess.
4. Extract the batch. Process the documents and capture the structured output.
5. Verify against the source. Open each document and confirm every field. For amounts, dates, and identifiers, check character by character.
6. Reconcile totals. Where a document carries its own totals, confirm your extracted numbers add up correctly.
7. Fix and document. Correct errors, note which fields failed most often, and tighten the schema or instructions before scaling up.
8. Keep a human accountable. A named person signs off before extracted data is used in payments, filings, or reports.

Getting documents ready to extract

Extraction quality depends heavily on what you feed the tool. A few preparation steps reduce errors before they happen.

Check that the text is actually text

A file that looks like a document on screen may be a scan — an image of a page with no underlying text. Tools that read text can struggle with scans, and adding optical character recognition first often improves accuracy. If a tool offers a document-reading mode versus a plain-text input, the document mode is usually the better fit for PDFs and images.

Start with a representative sample

Layouts vary across suppliers, templates, and time. Extracting a small, varied sample first tells you which document types the tool handles well and which ones it fumbles, before you commit to a large batch.

Watch multi-page and multi-column documents

Totals on a final page, values split across two columns, or a table that continues across a page break are common places for errors. These are exactly the spots to inspect first when you verify.

Keep the original alongside the output

Never discard the source once extraction is done. The original is what lets you confirm a value, settle a dispute, and correct a batch that turns out to be wrong. If you cannot keep the source, record enough of it — a page number or a stored copy — to check later.

Limitations and risks

Automated extraction is a productivity tool with a sharp edge. Understand the failure modes before you trust it with anything consequential.

Values can be misread

Digits are easily transposed, letters confused with numbers, and decimals dropped. A single mistyped character can change $12,400 into $12,040 or a due date by a month. These errors are invisible in a neat table.

Fields can be misassigned

In multi-column tables and forms, values can shift into the wrong row or column. The result looks correct in isolation but is silently attached to the wrong record.

Values can be hallucinated

When a field is missing or unclear, a model may supply a value that fits the pattern of the document rather than what is actually written. It will not warn you. This is why "not found" must be an explicit instruction.

Formatting can hide problems

Rounding, dropped thousands separators, or a currency symbol applied to the wrong amount all produce data that looks clean. Always confirm the format before trusting the values.

Context can be dropped

Footnotes, riders, and conditions often change what a number means. An extracted total without its qualifier can be technically copied and still misleading.

Because these errors are quiet, every extracted figure that will be paid, filed, or reported must be verified against the source. Spot-checking a sample is fine for volume; it is not sufficient for numbers that carry consequences. For more on this discipline, see AI Limitations and Verification and our Limitations & Verification guide.

Where extraction fits in a workflow

Extraction is most useful as one step in a larger process. If you are automating the surrounding steps — routing, notifications, reconciliation — the decision framework in Automating Repetitive Tasks helps you judge what to automate and what to keep manual. The Task Automation guide explores the topic further.

Where data is sensitive — payroll, health records, personal identifiers — review Protecting Confidential Information before sending anything to a tool, and check your organization's policies on where documents may be processed.

Speed is easy; correctness is the job

Extraction tools turn hours of retyping into minutes of processing, which is real value. But the point of extraction is not a filled table; it is a table you can act on. Because errors hide inside tidy output, the checking step is not a formality — it is the work that makes the speed worthwhile.

Set a clear schema, demand "not found" instead of guesses, and verify anything that matters. Continue with the Document Workflows guide or the practical Task Automation guide.