Most automation tools are linear. Step one triggers step two triggers step three. Something unexpected at step two? The whole thing stops. Error notification. Investigate. Fix the rule. Restart. You've probably lived this cycle.
An AI agent works differently. It has a goal and a set of tools. At each step, it decides which tool to use based on what it sees. Hand it a stack of invoices and tell it to extract line items, match them against purchase orders, flag discrepancies, and update your spreadsheet. The agent reads each invoice, figures out the layout without a template, pulls the data, runs the comparison, and reports back. If one invoice is a scanned image instead of a native PDF, the agent doesn't choke. OCR. Keep going.
That's the real difference, and honestly it's a bigger deal than it sounds. Traditional automation handles the happy path. Agents handle the other 40% of documents that have been falling on the floor because nobody built a rule for them.
What does this look like in practice right now? Claude Code or Claude Desktop connected to extraction tools via MCP (Model Context Protocol). Claude handles the reasoning. Lido's MCP server reads documents and returns structured data. Put them together and you have an agent that processes documents, writes files, queries databases, and talks to APIs, all in one session.
Think about what a person actually does with an invoice. Opens the PDF. Reads each field. Types values into a spreadsheet. Checks the math. Looks up the vendor in the ERP. Files it. Five context switches, ten minutes, one invoice. Multiply by 500 and you've hired someone whose entire job is copying numbers from one screen to another.
Automation tools like Zapier or Power Automate can handle parts of this. A Zap might watch an email inbox and download the attachment. But it can't read the invoice. It has no idea that this invoice uses a different format than the last one, and it definitely won't catch that the vendor charged you $4.50 per unit when the PO says $4.25.
An agent chains all of it. One prompt. Here's what that looks like in practice:
The agent picks up documents from a folder, email, or cloud storage. It reads each one and pulls structured fields (vendor name, amounts, dates, line items) regardless of layout. Then it transforms what it found: reformatting dates, normalizing vendor names against your master list, converting currencies. It validates the math, checking that line items sum to the total and that there's no duplicate invoice number. Clean data gets written to a CSV, Google Sheet, or API endpoint. At the end, the agent tells you what it did and what needs human review.
All of that happens in one pass. The agent makes decisions throughout. Low extraction confidence on a field? It flags the row instead of guessing. Vendor name doesn't match anything in your master list? It marks the row for review rather than silently assigning a wrong match. That's what intelligent document processing actually looks like when it works. The system understands context, not pixel positions. Under the hood, the extraction relies on OCR data extraction powered by large language models rather than rigid rule sets.
MCP is an open standard that lets AI assistants call external tools. Think of it as a plugin system. The Lido MCP server exposes four tools to Claude. The main one is extract_file_data, which pulls structured fields from documents. There's also extraction_tips for refining results when the first pass isn't quite right, plus authenticate and extractor_usage for setup and quota tracking.
Install takes one command:
claude mcp add lido -- npx -y @lido-app/mcp-serverOnce connected, Claude can read any document you throw at it. The extraction is template-free. This matters more than it sounds, because agents need to handle variable inputs without crashing. You can't build a useful agent that breaks every time it encounters a new vendor's invoice format. Lido's engine uses large language models that understand what a document means, regardless of where text sits on the page. A three-column German invoice and a single-page receipt from a local shop? Same tool call. This is the same document capture technology that powers Lido's web app, exposed as an API tool for agents.
So what makes this an agent rather than a tool? Claude reasons about what to do with extracted data. It might pull line items, compare them against a PO, write matches to one sheet, put discrepancies in another, then send you a summary. You describe the end state. Claude figures out how to get there.
For the full list of MCP servers that handle document processing, we've reviewed nine options. Lido is the most practical for variable-format business documents because of the template-free approach, but specialized tools like Koncile exist for invoice-only workflows. If you're evaluating extraction APIs for a more code-driven integration, see our comparison of document extraction APIs for developers.
Let's build something real. Say you have a folder of 50 invoices from different vendors and you need the data in a spreadsheet formatted for QuickBooks import.
You need Claude Code installed and Node.js 18+ on your machine. You'll also need a Lido account for extraction. If you haven't set up the MCP server yet, follow the Lido MCP installation guide. For a more detailed implementation with folder structure and validation, see our step-by-step agent build guide.
Open Claude Code in your project directory where the invoices live. Type:
I have 50 vendor invoices in ./invoices/ (PDFs and scanned images, mixed formats).
Extract these fields from each one: vendor name, invoice number, invoice date,
due date, line item descriptions, quantities, unit prices, line totals, subtotal,
tax, and grand total. Write results to ./output/invoices.csv with one row per
line item. Add a column for the source filename. Flag any invoice where the line
items don't sum to within $1 of the stated total.That's the whole prompt. Claude will plan the work, iterate through each file, call Lido's extraction for each document, validate the math, and write the output.
After the first batch, check the CSV. If a specific vendor's invoices aren't extracting correctly (maybe they label invoice numbers as "Reference" instead of "Invoice #"), tell Claude:
The Müller GmbH invoices have the invoice number in the top right labeled
"Referenz-Nr." Can you re-extract those with that field mapping?Claude re-runs extraction on just those files with the updated instruction. No template to rebuild. No regex to write. Plain English.
QuickBooks needs vendor IDs, not names. If you have a vendor master list:
Match the extracted vendor names to the vendor list in ./vendor-master.csv using
fuzzy matching. Add the QuickBooks Vendor ID as a column. For any vendor that
doesn't match above 85% confidence, mark it as "REVIEW" in a status column.Claude reads both files and runs the matching logic. It updates your output CSV with the matched IDs and flags any vendor that needs human review, rather than silently assigning a wrong match.
Reformat the CSV to match QuickBooks bill import format: columns should be
Vendor, RefNumber, TxnDate, DueDate, ItemDescription, ItemQuantity, ItemCost,
ItemAmount. Dates as MM/DD/YYYY. Remove the validation columns.Now you have a file ready for QuickBooks import. The entire process, from 50 mixed-format PDFs to an import-ready CSV, took one conversation. This is a practical example of the broader category of invoice data extraction software at work. For teams that want this running automatically on incoming invoices, see our guide on automating invoice extraction from email.
Operations teams that manage vendors or subcontractors spend a genuinely surprising amount of time on certificates of insurance (COIs). Every vendor needs current coverage. Certificates expire. Coverage amounts change. Endorsements get dropped during renewals. And nobody wants to be the person who discovers a lapsed policy after an incident on a job site.
Here's how to build a COI review agent:
I have 75 certificates of insurance in ./coi-docs/. Extract these fields from
each: certificate holder, insurer name, policy number, general liability limit,
auto liability limit, workers comp limit, umbrella limit, effective date, and
expiration date. Write to ./output/coi-tracker.csv. Flag any certificate that
expires before July 31, 2026 or has a general liability limit below $1,000,000.The agent reads each COI (these are notoriously inconsistent in layout since they come from hundreds of different insurance companies) and extracts the coverage details into your compliance tracker. Certificates approaching expiration get flagged automatically. No more checking each one by hand to see if General Liability is above your minimum.
You can extend this further:
Compare the extracted COI data against our vendor requirements in
./requirements.csv. Each vendor type has minimum coverage amounts. Flag any
vendor whose actual coverage falls below the requirement for their type.Now you have a compliance gap report. The agent cross-referenced two data sources and surfaced the problems. A person doing this manually would spend a full day with 75 certificates. The agent does it in minutes.
Bank statement reconciliation is tedious for a simple reason: the data lives in two places that don't talk to each other. Transactions in the bank statement, records in your accounting system, and some poor human in the middle trying to match them row by row.
Extract all transactions from ./statements/march-2026-statement.pdf. Fields:
date, description, amount (positive for deposits, negative for withdrawals),
running balance. Write to ./output/bank-transactions.csv.Once you have clean transaction data:
Compare bank transactions in ./output/bank-transactions.csv against our GL
export in ./gl-march-2026.csv. Match by amount and date (within 3 days).
Write three files: matched-transactions.csv (paired records),
unmatched-bank.csv (in bank but not GL), and unmatched-gl.csv (in GL but
not bank).The agent does the matching and gives you three clean files. The unmatched items are what need investigation. Instead of spending hours comparing line by line, you go straight to the exceptions. Most people assume reconciliation requires manual work. It doesn't. This is document automation doing exactly what it's supposed to do.
Let's be specific about where agents win and where traditional tools are still the better choice.
Start with RPA (UiPath, Automation Anywhere, Blue Prism). These record and replay UI interactions. Click here, type there, press enter. If you're stuck with a green-screen mainframe that has no API, RPA might be your only option. But RPA bots expect things at specific screen coordinates, so they break the moment a vendor sends an invoice with a different layout. If your ERP has a stable API, skip RPA entirely.
Zapier and Make are a different animal. They connect cloud apps with trigger-action rules: "when X happens in app A, do Y in app B." Moving a file from Dropbox to Google Drive, sending a Slack notification when a form is submitted. Great at that. Terrible at anything requiring document comprehension. A Zap can move a PDF but can't read it. You'd need Zapier plus a separate extraction tool, and even then the Zap can't branch based on what the extraction finds.
Then there's Power Automate, which lives somewhere between Zapier and RPA. Deeper Microsoft integration, desktop automation capabilities, more complex branching logic. If your org runs on Microsoft 365 end-to-end, take a look. Same blindness to document content as Zapier, though Microsoft's "AI Builder" can handle simple, consistent form layouts.
AI agents (Claude + MCP tools) fit a different niche. Variable-format documents where the workflow requires reading content, making decisions based on what's there, then acting on those decisions. Messy real-world invoices, COIs from a hundred different insurers, bank statements that change format every quarter. Where agents fall short today: fully unattended processing on a fixed schedule. They're conversational tools. A person kicks them off.
The honest answer is that most teams will use a combination. Let the agent handle extraction and transformation (the hard, variable part), then hand off to a Zap or Power Automate flow for scheduling and routing (the simple, predictable part). They complement each other well.
Agents are overkill for processes that are already simple and consistent. If you receive the same invoice format from the same five vendors every month and just need the totals entered into your ERP, a basic accounts payable automation tool does that without the overhead of setting up Claude Code and an MCP server.
They're also not ideal yet for fully unattended, lights-out processing. Agents work in a conversation. Someone starts the session and types a prompt. Someone reviews what comes back. You can script around this, but the current paradigm is human-in-the-loop. If you need a fully automated email-to-ERP pipeline running 24/7 without anyone watching, Lido's web app with email ingestion is a more practical path than an agent workflow.
And if your documents are extremely high-volume (tens of thousands per day), agents processing documents sequentially through Claude won't match the throughput of a dedicated batch processing system. Agents are better for complex workflows at moderate volume than simple workflows at massive volume.
Start small. Pick one document type that's causing real pain for someone on your team. Invoices are the most common starting point (the ROI math is obvious: time saved per invoice times volume), but COIs and purchase orders work just as well. Grab a test batch of 10 to 20 documents with varied layouts.
Install the Lido MCP server:
claude mcp add lido -- npx -y @lido-app/mcp-serverOpen Claude Code, point it at your test documents, and describe what you need extracted. Check the first few results. If a field is off, tell Claude what to fix in plain English. Once extraction quality looks right, layer on the downstream work: validate the math, match against your master data, reformat for import, write the output file.
This same pattern works for any document type. We've seen teams apply it to invoices and POs, COIs, bank statements, tax forms, shipping documents, even medical claims. Variable layouts don't require per-document configuration on the extraction side. The agent layer on top handles all the logic you'd otherwise build in a spreadsheet or a script.
The gap between "I have a pile of documents" and "I have clean, structured data in my system" used to require expensive software, a six-month implementation, or a person spending all day on data entry. With an agent and the right extraction tools, you can close most of that gap in a single afternoon of experimentation.
An AI agent for document processing is a system that autonomously reads documents, extracts structured data, and then acts on that data (validating, transforming, exporting, or routing it). Unlike traditional automation that follows fixed rules, an agent decides which steps to take based on what it encounters. It handles format variations without templates, makes judgment calls about data quality, and doesn't require per-document configuration. In practice, this means connecting Claude to extraction tools like Lido via MCP and giving it a goal rather than a script.
Install the Lido MCP server with claude mcp add lido -- npx -y @lido-app/mcp-server, then open Claude Code and describe your goal in plain English. Tell Claude what documents to process, what fields to extract, where to put the results, and what validation to run. Claude calls Lido for extraction, transforms the data, and writes the output. The entire agent runs within a single Claude Code session. No orchestration code. No workflow builder.
Yes. This is the main advantage over template-based systems. Lido's extraction engine uses large language models that understand document content rather than relying on fixed page coordinates. Invoices from 50 different vendors with 50 different layouts all get processed with the same tool call. Scanned images, native PDFs, photos of paper documents all work. No separate configuration per format.
RPA bots replay recorded UI interactions, which works for stable, consistent interfaces but breaks when document formats change. AI agents understand document content and adapt to format variations without reprogramming. RPA is still the better choice when you need to automate processes inside legacy applications with no API. Agents are better for document-heavy workflows where formats vary across sources. Many teams use both, with agents handling extraction and RPA handling the final data entry into legacy systems.
The Lido MCP server runs locally on your machine, and API authentication credentials are stored in a local file that's automatically gitignored. Documents are sent to Lido's extraction API for processing, which uses the same security infrastructure as the Lido web application. For organizations with strict data residency requirements, the agent approach lets you control which documents are sent for extraction and review results before any data leaves your environment for downstream systems.
Any document with structured or semi-structured data. Common use cases beyond invoices: purchase orders, bank statements, tax forms (W-2s, K-1s, 1099s), COIs, bills of lading, medical claims, EOBs, contracts, and receipts. The template-free extraction means you can point the agent at a completely new document type tomorrow without any setup. Describe the fields you need and the agent figures out the rest.
%20(1).svg)
