A document processing agent is an AI that does more than extract data from a single file. It runs a multi-step workflow autonomously. You give it a goal ("process this month's invoices, match them to our PO records, and flag anything over $10,000 for review") and it figures out the steps: read each document, pull the right fields, cross-reference against your data, apply your rules, and produce output.
The difference between an agent and a simple extraction API call is the decision-making layer in the middle. An API call returns raw data. An agent takes that data, does something with it, handles edge cases, and gives you a finished result.
Until recently, building this kind of agent meant writing hundreds of lines of Python to orchestrate API calls, manage file I/O, handle errors, and implement matching logic. Claude Code with MCP changes that equation. As part of the broader shift toward AI agents for document processing, you describe the workflow in plain English, and Claude executes it using real tools. The Lido MCP server gives Claude the ability to extract structured data from any document, while Claude's own capabilities handle file operations, data transformation, and logic. You get an agent without writing agent code.
You need four things before starting: a package manager, a runtime, an AI tool, and an extraction account. The whole setup takes about ten minutes.
Node.js 18 or later -- the Lido MCP server runs via npx, which ships with Node. Check your version with node --version in your terminal. If you need to install it, grab the LTS release from nodejs.org.
Claude Code -- Anthropic's terminal-based coding agent. Install it with npm install -g @anthropic-ai/claude-code and authenticate with your Anthropic API key. If you've already been using Claude Code for development, you're set.
A Lido account. Sign up at lido.app and grab your API key from account settings. There's a free tier with enough pages to follow this tutorial and process real batches. You'll paste the key during the authentication step below.
A folder of test documents. Invoices work best for a first run, but any structured document will do. Five to ten files is plenty.
Open your terminal and run:
claude mcp add lido -- npx -y @lido-app/mcp-serverThat's the entire installation. This registers Lido as an MCP (Model Context Protocol) tool that Claude Code launches automatically whenever you start a session. No repo to clone, no Docker container to spin up, no YAML to edit, no environment variables to juggle. If you're using Claude Desktop or another MCP client instead, see the install options on the MCP page.
To verify it worked, start Claude Code and type:
"Show me my available MCP tools"
You should see four Lido tools: authenticate, extract_file_data, extraction_tips, and extractor_usage. If they appear, you're connected. For a deeper walkthrough of what each tool does and alternative installation methods for Claude Desktop or Cursor, see the full Lido MCP setup guide.
The first time Claude uses a Lido tool, it'll call authenticate and open a browser window at localhost. Paste your Lido API key there. Credentials save to .lido-mcp/credentials.json in your project directory and persist across sessions. One-time thing.
An agent needs a defined workspace. Create a folder structure that separates incoming documents from processed output:
mkdir -p ./doc-agent/inbox ./doc-agent/processed ./doc-agent/outputinbox/ is where you drop documents to be processed. processed/ is where the agent moves files after extraction (so you never accidentally re-process them). output/ is where results land: CSVs, JSON files, exception reports.
Drop some test documents into inbox/. Invoices work well for a first run because the fields are predictable. But this works just as well with purchase orders, receipts, bank statements, insurance certificates, or any document that has structured data you need to capture. Five to ten documents is enough to validate the pipeline before running a full batch.
The folder structure matters more than it seems. When you scale to hundreds of documents per run, having a clean separation between unprocessed and completed files prevents the kinds of errors that turn automation into a debugging session. I'd also recommend adding a ./doc-agent/errors/ folder where the agent can quarantine documents it can't process cleanly.
This is where the agent comes together. A good agent prompt is specific about the goal, the fields, the rules, and the output format. Vague prompts produce vague results. Here's a real example for an accounts payable workflow.
Start Claude Code in your project directory and paste something like this:
"Process every PDF in ./doc-agent/inbox/ as a vendor invoice. For each document, extract these fields: vendor name, vendor address, invoice number, invoice date, due date, payment terms, line item descriptions, quantities, unit prices, line item totals, subtotal, tax amount, and grand total. After extracting each file, validate that the line item totals sum to the subtotal within a $0.02 rounding tolerance. Flag any invoice where the math doesn't check out. Write all results to ./doc-agent/output/extraction-results.csv with one row per line item. Include a column for the source filename. After processing each file, move it from inbox/ to processed/. At the end, print a summary: how many invoices processed, how many passed validation, how many flagged."
That single prompt gives Claude enough to run the full pipeline. It calls extract_file_data for each document, applies the validation rule, writes the CSV, manages the file moves, and produces a summary report. No code to write. Just a description of what you want.
Here's what the output looks like for a batch of five invoices:
source_file,vendor_name,vendor_address,invoice_number,invoice_date,due_date,payment_terms,line_item_description,quantity,unit_price,line_item_total,subtotal,tax_amount,grand_total,validation
acme-inv-4521.pdf,Acme Industrial Supply,742 Commerce Dr Dallas TX 75201,INV-4521,2026-03-15,2026-04-14,Net 30,Hydraulic Pump Model HP-200,2,1250.00,2500.00,4750.00,380.00,5130.00,PASS
acme-inv-4521.pdf,Acme Industrial Supply,742 Commerce Dr Dallas TX 75201,INV-4521,2026-03-15,2026-04-14,Net 30,Replacement Seals Kit,5,450.00,2250.00,4750.00,380.00,5130.00,PASS
brightstar-8834.pdf,BrightStar Electronics,1200 Innovation Blvd Austin TX 78701,BS-8834,2026-03-18,2026-04-17,Net 30,LED Panel Array 4x8,10,89.00,890.00,890.00,71.20,961.20,PASS
summit-22019.pdf,Summit Office Solutions,500 Main St Suite 200 Houston TX 77002,SO-22019,2026-03-20,2026-04-04,Net 15,Copy Paper A4 Case,25,42.00,1050.00,2090.00,167.20,2257.20,PASS
summit-22019.pdf,Summit Office Solutions,500 Main St Suite 200 Houston TX 77002,SO-22019,2026-03-20,2026-04-04,Net 15,Toner Cartridge TN-450,8,130.00,1040.00,2090.00,167.20,2257.20,PASSEach line item gets its own row. The validation column tells you whether the math checks out. Documents that fail validation get flagged so you can review them manually rather than importing bad data into your ERP.
The agent approach gives you the same results as traditional document capture software but with far more flexibility in how you define rules and output formats. For non-invoice documents, adjust the prompt accordingly. A certificate of insurance workflow might look like:
"Extract certificate holder, insurer name, policy number, coverage type, coverage limit, and expiration date from every PDF in ./doc-agent/inbox/. Flag any certificate that expires before 2026-07-01. Write results to ./doc-agent/output/coi-audit.csv."
Same pattern. Different fields. The agent handles it the same way.
When you hit enter on that prompt, Claude processes the documents sequentially. For each file, you'll see Claude call the extract_file_data tool, get results back, run its validation checks, and move to the next document. A batch of 20 standard invoices typically completes in two to four minutes.
After the run completes, check these things.
Open the CSV and spot-check a few rows against the source PDFs. Look at vendor names, totals, and line item details. Lido's template-free OCR data extraction handles most layouts correctly on the first pass, but unusual document formats (multi-column line item tables, handwritten annotations over printed text, damaged scans, or invoices with merged table cells) might need refinement.
Then look at the validation column. Any rows marked FAIL deserve a manual check. Common causes: the document has a discount line that throws off the subtotal calculation, or tax is applied per line item rather than on the total. These aren't extraction errors. They're business logic that your validation rule needs to account for. Tell Claude what you're seeing and it'll adjust.
Finally, check the processed/ folder. Every file from inbox/ should have moved there. If a file is still sitting in inbox/, it means extraction failed on that document. Ask Claude what happened and it'll tell you (corrupted PDF, zero-byte file, password-protected document, that kind of thing).
If certain fields are consistently off for a specific vendor's layout, you can add field-level instructions. Tell Claude: "For BrightStar Electronics invoices, the invoice number appears in the upper right corner labeled 'Reference #' not 'Invoice #'." These are plain English hints that refine the extraction. For more on this technique, see the extraction tips section of the MCP guide.
The CSV from step 4 is already a usable output. But most real workflows need that data somewhere specific: a Google Sheet the AP team reviews, an Excel file formatted for ERP import, or a JSON payload for an internal system.
For spreadsheet export, tell Claude exactly what you need:
"Take the extraction results CSV and reformat it for our QuickBooks import. Columns should be: Vendor, Ref No., Date, Due Date, Item Description, Quantity, Rate, Amount. Map 'vendor_name' to Vendor, 'invoice_number' to Ref No., 'unit_price' to Rate. Drop the validation column. Save as ./doc-agent/output/qb-import.csv."
Claude reads the source CSV, remaps columns, and writes the import-ready file. You can get more specific than that, too: "format dates as MM/DD/YYYY" or "round all amounts to two decimal places" or "add a column called 'Class' with the value 'Operations' for every row." Whatever your import template expects.
For JSON output (useful if you're feeding a database or API):
"Convert the extraction results to JSON. Group line items under their parent invoice. Structure it as an array of invoice objects, each with header fields and a nested lineItems array. Save to ./doc-agent/output/invoices.json."
Claude produces clean JSON you can ingest directly. The structure matches whatever your downstream system expects because you described it in the prompt.
For teams that want data flowing directly into a spreadsheet they collaborate on, Lido's web app at lido.app has built-in Google Sheets and Excel export. The MCP-based agent approach is better when you need custom transformation logic, conditional routing, or integration with other terminal-based tools. Pick whichever fits your workflow.
Raw extraction gets data off documents. Business rules turn that data into something your team can act on. This is where the agent approach earns its keep, because you can layer rules into the same prompt without writing any code.
Fuzzy matching is the most common add. Extracted vendor names almost never match your ERP records exactly. "Acme Corp" on the invoice, "Acme Corporation Inc." in NetSuite. You can handle this two ways. In the agent prompt, tell Claude: "After extraction, compare each vendor name against the list in ./vendor-master.csv and find the closest match. Add columns for matched_vendor_name and vendor_id." Claude uses string similarity to resolve common variations. For production-grade matching with semantic AI (where "IBM" correctly matches "International Business Machines"), use Lido's Smart Lookup feature, which handles matching during extraction itself.
Duplicate detection is another one that pays for itself immediately. Vendors send the same invoice twice more often than you'd think. Add to your prompt: "Before writing results, check for duplicate invoices by matching on vendor name + invoice number + total. If a duplicate is found, skip the second occurrence and log it to ./doc-agent/output/duplicates.csv." APQC research shows duplicate payments average $1,500 each, so this single rule can save thousands per quarter.
Approval routing is straightforward too. "Add a column called 'approver' based on the grand total. Under $1,000 set to 'auto-approve'. Between $1,000 and $10,000 set to 'dept-manager'. Over $10,000 set to 'director'." The output spreadsheet is pre-routed before anyone touches it.
You can also add computed columns: "Add a column called 'days_until_due' that calculates the number of days between today and the due date. Add another called 'early_payment_eligible' that's TRUE if days_until_due is greater than 20 and payment_terms contains '2/10'." These let your team prioritize early payment discounts without manual calculation.
Each of these rules is one or two sentences added to your prompt. The agent applies them across every document in the batch. Compare that to building the same logic in a traditional automation platform, where each rule is a separate node in a visual workflow editor with its own configuration screen.
The agent architecture handles workflows well beyond basic invoice extraction. Here are patterns we see teams building with it.
The full accounts payable automation chain: extract invoices from an inbox folder, match vendors against a master list, apply approval routing, detect duplicates, validate line item math, and produce an ERP-ready import file. The agent prompt ends up being maybe 15 to 20 sentences, but each piece is simple. Run it daily or weekly. The output CSV drops into your ERP's bulk import tool without manual reformatting.
For teams that want this running continuously on email attachments instead of a folder, email-based ingestion through Lido's web app handles that side. The agent approach is best for batch processing where you control the timing.
Construction companies and property managers collect certificates of insurance from every subcontractor. These expire. Missing or expired coverage is a liability nightmare. The agent prompt: "Extract certificate holder, insurer, policy type, coverage limits, and expiration date from every COI in ./coi-inbox/. Compare against the required minimums in ./requirements.csv (general liability $1M, auto $500K, workers comp statutory). Flag any certificate where coverage is below the requirement or expiration is within 60 days. Write a compliance report to ./output/coi-compliance.csv."
One prompt replaces what most companies do with a spreadsheet that someone manually updates once a quarter (and that's always out of date by month two).
Extract transactions from monthly bank statement PDFs, match them against your GL entries in a reference spreadsheet, and flag unmatched items. The prompt: "Extract date, description, debit, credit, and running balance from each bank statement in ./statements/. Then compare each transaction against ./gl-entries.csv by matching on date (within 2 days) and amount (exact). Write matched pairs to reconciled.csv and unmatched items to exceptions.csv."
This is the tedious reconciliation work that eats the last few days of every month-end close. An agent finishes it in minutes. The exceptions file gives your team a focused list to investigate instead of working through every transaction line by line.
The Lido web app at lido.app is the right choice for teams that want a visual interface, automated email ingestion, built-in approval workflows, and shared team access without touching a terminal. If your AP team processes invoices daily and needs something they can point and click through, use the web app.
The Claude Code agent approach works better when you need custom logic that goes beyond extraction. Cross-referencing against local files, conditional routing based on document content, data transformation for specific import formats, chaining document processing with other development tasks. Developers and technical ops teams tend to prefer it because everything stays in the terminal and the "configuration" is a natural language prompt you can version-control in a text file.
Both use the same extraction engine under the hood. Same template-free approach, same accuracy, same document format support. The MCP server comparison covers how Lido's server stacks up against other document processing options in the MCP ecosystem.
After running many document processing agents, a few patterns make them noticeably more reliable.
Be explicit about field names and output format. "Extract the invoice data" is too vague. "Extract vendor_name, invoice_number, invoice_date, due_date, grand_total" gives Claude a concrete schema to work with. Column names in your prompt become column headers in your output.
Include validation rules in the prompt itself, not as a follow-up step. When Claude validates during extraction, it catches problems while the document context is fresh. Running validation on the CSV after the fact loses that context.
Start with a small batch. Test on five documents, review the output, adjust your prompt, then scale. Iterating on a prompt with 200 documents in the queue wastes time and API pages.
Save your working prompts to text files. A prompt that works well for invoice processing is a reusable asset. Store it as ./prompts/ap-extraction.txt and reference it in future sessions. This is as close to "configuring" the agent as you need to get. If you're evaluating dedicated tools for the extraction layer, the best invoice data extraction software comparison covers the landscape.
For extraction-specific tips on refining field accuracy, the API developer guide covers column instructions and formatting directives in detail.
A document processing agent is an AI system that runs multi-step document workflows autonomously. Instead of extracting data from one file at a time, an agent processes a batch of documents, applies business rules (validation, matching, routing), and produces structured output ready for your downstream systems. With Claude Code and the Lido MCP server, you build agents by writing natural language prompts rather than code. The agent reads documents through Lido's extraction engine, then uses Claude's reasoning to handle the logic between extraction and output.
Yes. The agent prompt is written in plain English. You describe the fields to extract, the rules to apply, and the output format you want. Claude handles the technical execution: calling the extraction API, reading and writing files, applying your business logic, and managing the document pipeline. You do need basic comfort with a terminal since Claude Code runs in the command line, but no programming is required.
Claude Code can process hundreds of documents in a single session. The practical limit is your Lido account's monthly page quota and the session's context window. For most accounts, batches of 50 to 200 documents per session work well. Larger volumes are better handled by splitting into multiple runs or using Lido's web app, which has built-in batch processing and email ingestion for high-volume workflows. Each standard document takes a few seconds to extract, so a batch of 100 invoices typically completes in under ten minutes.
Yes. The Lido MCP server implements the open Model Context Protocol standard and works with any MCP-compatible client. That includes Claude Desktop, Cursor, Windsurf, Cline, and other editors that support MCP. The installation method varies by client (Claude Code uses a terminal command, Claude Desktop uses a JSON config file), but the extraction capabilities are identical. See the full MCP setup guide for configuration details per client.
The MCP server calls the same extraction API as the Lido web application. Field-level accuracy on standard document types (invoices, receipts, purchase orders) is typically 95 to 98 percent for header fields like vendor name, invoice number, dates, and totals. Line item extraction runs 90 to 96 percent depending on table complexity. The extraction is template-free, so it handles any document layout without per-vendor or per-format configuration. Accuracy doesn't degrade when a vendor changes their invoice format.
Any document with structured or semi-structured data. Invoices, receipts, purchase orders, bills of lading, bank statements, tax forms (W-2s, K-1s, 1099s), certificates of insurance, medical claims, contracts, packing lists, customs declarations, and shipping manifests are all common use cases. The extraction engine reads PDFs, scanned images, and photos. You define the fields you need per document type in your agent prompt. A single agent session can even process mixed document types if you instruct Claude to identify the document type first and apply different extraction schemas accordingly.
%20(1).svg)
