Extract Data From Documents Without Building Templates

TL;DR: To extract data from documents without templates, you name the fields you want in plain English, for example "get vendor, amount, and due date", and the step reads each document and returns those values. Template based capture maps coordinates on a sample layout and breaks when a supplier redesigns an invoice. In The Drive AI, each named value flows into later steps, so a total or a renewal date can appear in the filename, the folder path, the approval question, a message, or a webhook body.

Someone in accounts payable opens a PDF, reads four numbers off it, and types them into another system. Then does it again, 180 times, in the last three days of the month.

Data capture software was supposed to end that. Most of it starts by asking you to upload a sample document and draw boxes around the fields you want. Vendor here. Invoice number there. Total in the bottom right cell. It works on everything that looks exactly like that sample. Then a supplier switches billing systems, the total moves two inches left, and the box you drew returns a shipping address.

Document data extraction is the act of turning something printed on a page into a value another system can act on: a vendor, an invoice number, a total, a renewal date. The difficulty was never reading the characters. It was knowing which characters are the field.

How has document data extraction worked until now?

Historically, extraction has been configured per layout. Someone teaches the system where a field sits on one version of one document, and it repeats that lookup on everything that follows. Three approaches carry most of the load.

Zonal or template based OCR. You define a zone, a rectangle at fixed coordinates, and the system runs OCR inside it. Fast, cheap, deterministic. Invoice data capture products built this way have served finance teams for two decades.

Regular expressions and keyword anchors. Instead of coordinates, you search the page text for a pattern such as INV-\d{6}, or the number after the word "Total". This survives small layout shifts, but the anchor has to be present and unique. Documents saying "Amount Due", "Balance Due", and "Total Payable" need three patterns, and a page with a subtotal and a total will hand you the wrong one.

Per layout training. Better systems learn a layout from several annotated samples rather than one drawn box, which tolerates minor variation. The unit of configuration is still the layout.

All three scale with the number of formats you receive, not the number of documents.

What breaks a template based extractor?

Templates break on change, and documents change constantly. This is what fills the exception queue.

• A new vendor. The document is legible, the extractor has no configuration for it, and it routes to manual review. Every supplier adds setup work before their first invoice can be processed.
• A supplier redesigns their template. Extraction keeps succeeding, which is worse than failing, because the zone now returns a plausible value from the wrong place.
• Rotated, skewed, or photographed scans. A page scanned upside down, or a phone photo at an angle, breaks the geometry the zones assume.
• Multi page documents and variable length tables. Ten line items push the total down the page. Two pull it up. A zone on page one finds nothing when the total lands on page three.
• The wrong document entirely. A remittance advice lands in the invoice queue, and a template cannot notice it.

The pattern repeats: the system was configured against a document's appearance, not its meaning.

What is the difference between extracting text and understanding a field?

Extracting text gives you characters. Understanding a field gives you the right characters, correctly labelled, out of a page full of plausible candidates.

OCR on a typical invoice returns a company name at the top, another in the "Bill To" block, four dates, and up to thirty numbers. Every one is text, and the OCR was flawless. What remains is which company is the vendor, which date is the due date rather than the issue date, and which number is the total rather than a subtotal, a tax amount, or a line item.

Answering that means reading the page the way a person does, using the labels, the structure, and the arithmetic between the numbers. It is a comprehension problem, not a coordinates problem, which is why a person can process an invoice from an unfamiliar vendor with no setup at all.

How does Read Details from File extract data from documents?

Read Details from File is an action in a workflow in The Drive AI. Its one field asks "What data should be extracted?", and you answer in plain English, for example "get vendor, amount, and due date". There is no sample document and no zone to draw.

The step carries the ai cost badge: it opens the file and reads it with AI. That costs a little per file and can occasionally be wrong, hence the limits below.

The important part is what you do with the answer. You name the fields, and each named value becomes available to every step that follows. Ask for vendor, invoice number, total, and due date, and you get four values to point at later, under the names you chose.

Sending document types down different paths is a separate step, Ask AI About the File, which picks a branch instead of returning values. A workflow often does both: classify first, then extract the fields that matter for that type.

Where do the extracted values go?

Into later steps, through the {{...}} token system. An extracted value can appear anywhere a step accepts text.

From the source you already get the file name, the file type, and which source it came from, written as {{trigger.file.name}}, {{trigger.file.mimeType}}, and {{trigger.sourceName}}. Beyond that it depends on where the file came from, because a source can only offer what it can actually fill: an email source has {{trigger.sender}} and {{trigger.subject}}, a chat source has {{trigger.channelName}} and who shared it, and a landing folder name is offered where the source has one. Those values are free, because they are already known. You insert them by clicking the value in the panel rather than typing it, and a workflow that references a value its source cannot provide is refused when you save it.

A Read Details from File step adds the fields you named to that same set. Each one points at the step that read it and the name you gave it, so a field called vendor reads {{nodes.extract_1.entities.vendor}} once inserted. Field names can contain spaces, so they read the way you wrote them. A vendor or a total read out of the page can then appear in:

• a filename, so an invoice is named by vendor and invoice number, not scan_0047.pdf
• a folder path, so a lease files itself under the property address printed inside it
• an approval question, so the approver sees the renewal date without opening the file
• a Slack or email message, so the notification carries the amount, not just a link
• a webhook body, so another system receives structured fields rather than a file

Move and Rename read the file themselves, so they offer earlier values only once such a step exists. Put Read Details from File before them. If you only need the file named sensibly, Rename alone is enough, and one step cheaper.

Example workflows

Each is typed as one sentence. The steps appear on a canvas and can be edited there.

When an invoice arrives in Finance/Inbox, get the vendor, invoice number, and invoice date, rename it with the vendor and invoice number, and file it under the vendor and year, like Vendors/Pinecone Systems/2026.

When a lease is uploaded to Properties/Incoming, get the property address, the tenant, and the start date, then move it to that property's folder under Properties, in a Leases subfolder, named with the tenant and start date.

When a contract arrives by email from @acme.com, get the counterparty and the renewal date, ask Dana to approve filing it and show her the renewal date in the question, and if she approves move it to Clients/Northwind/Contracts.

When an invoice arrives in Finance/Inbox, get the vendor, invoice number, total, and due date, then POST those fields to our accounts payable system at https://api.internal.example.com/ap/invoices.

The last one uses Send to Another App, the webhook step covered in sending workflow data to any app. It takes a URL, a method of POST, PUT, or PATCH, and authentication, and sends a standard payload of file details or your own JSON body with the extracted fields in it.

How does this compare to the alternatives?

Power Automate is strong on Microsoft ground: triggers and actions for SharePoint, OneDrive, Outlook, and Teams, plus an Approvals action. It acts on file events, metadata, and column values rather than on what a document says, unless you add AI Builder.

What will this not do?

It is an AI step, so the guardrails matter more than the demo.

• ai steps can be wrong. A field can come back empty or misread, particularly on poor scans. Every run is recorded in an activity feed, can be replayed on the canvas exactly as it happened, and can be retried from the step that failed.
• Hold the risky ones for a person. Add Ask a Person to Approve before anything hard to undo. Set "When to ask?" to Only when unsure, pick a caution preset of Careful, Balanced, or Relaxed, and choose how long to wait: 24 hours, 3 days (the default), or 1 week, after which the file takes the Expired exit. See human review inside a document workflow.
• Extraction does not write into your accounting system by itself. Values go into a filename, a folder path, a question, a message, or a webhook. Send to Another App is the path onward.
• Files stay where they are. A workflow watching a folder in Google Drive, OneDrive, SharePoint, or Dropbox renames and moves files in place inside that storage. Nothing is imported unless you add a Save a Copy step.
• Plan requirement. Workflows on files uploaded to The Drive AI work on every plan. Connecting Gmail, Outlook, Slack, Teams, Google Drive, OneDrive, SharePoint, or Dropbox needs the Max plan on a personal workspace, or any Team plan, and each file processed counts once against a monthly allowance.

Setting it up

1. Decide where the documents arrive. An invoice mailbox is an Email Attachment source, scoped by sender or "Subject contains", as in Gmail attachment workflows. A watched folder is File Uploaded.
2. On Workflows, type one sentence describing what should happen, naming the fields: "get vendor, invoice number, total, and due date".
3. Open the Read Details from File step on the canvas and check the field list. Add anything missing, remove anything you will not use.
4. Point the later steps at those values: the Rename field, the Move destination, the approval question, the message, or the webhook JSON.
5. Run ten real documents, including the two ugliest scans you have, then replay each run on the canvas to see which step produced which value.
6. If the stakes are high, add Ask a Person to Approve on Only when unsure, so confident filing proceeds and borderline documents wait.

For invoices in particular, see automating invoice processing without templates and accounting workflows. The wider picture is in the complete guide to automated document workflows.

Frequently Asked Questions

Can I extract data from documents without building templates?

Yes. Instead of drawing zones on a sample document, you name the fields in plain English, for example "get vendor, amount, and due date". The step opens each file and returns those named values. Nothing is configured per vendor or per layout, so a new supplier's document is handled like a familiar one.

What happens when a vendor changes their invoice layout?

Nothing changes on your side. No template records where the total used to sit, so there is nothing to update when it moves. That is the practical difference from zone based capture, where a redesigned layout often keeps returning values from the wrong part of the page rather than failing outright, which makes the error harder to spot.

How do extracted values get into the filename or folder path?

Through the {{...}} token system. Each field you named in a Read Details from File step becomes a value later steps can insert, alongside source values such as {{trigger.file.name}} and {{trigger.sender}}. Move and Rename read the file themselves and offer earlier values only once such a step exists, so place extraction before them.

Does it work on scanned PDFs and photographed documents?

The step opens the file and reads it, scans and photographs included, rather than looking at fixed coordinates, so a rotated or skewed page is not automatically a failure. Quality still matters: a very poor scan can produce an empty or incorrect field, which is the argument for a review step before anything hard to undo.

Can the extracted fields be sent to our accounting system?

Yes, with Send to Another App, which is a webhook. You give it a URL, a method of POST, PUT, or PATCH, and authentication: no key, a Bearer token, or an API key sent as an X-API-Key header. It sends a standard payload of file details by default, or your own JSON body containing the extracted fields.

Start with three fields

Pick the document you handle most and the three fields someone retypes from it every week. Describe that in one sentence on Workflows, run ten real files through it, and read the activity feed before trusting it with the rest. Create an account and try it on a folder you already have.