AI for Documents - How to Automatically Read, Organize and Search Contracts, Forms and Reports

AI for documents (Intelligent Document Processing) reads scans, PDFs and photos, extracts data into your company's systems, names the files and sorts them into folders - with a person checking wherever the model isn't sure. Manually retyping one document usually takes a few minutes. At 500 documents a month, 8 minutes each and an hourly cost of PLN 60, that's PLN 48,000 a year for one process. Ready-made models for common documents now cost about $10 per 1,000 pages. You gain the most not from the reading itself, but from validation that keeps errors out of your systems.

How AI reads scans and PDFs, extracts data into your systems and organizes files. Four document types, an architecture with validation, 2026 tools and prices, a real Google Drive case and a three-minute payback calculator.

This guide covers documents other than domestic invoices: contracts, handover reports, forms, HR documents, foreign invoices, receipts and correspondence. Since 2026, Polish B2B invoices arrive through the national KSeF system as structured files, so reading them is a separate topic - I cover it in the post on invoices from email to ERP. Here I show document types, the architecture, tools and prices, a real case of organizing Google Drive, and a calculator that tells you in three minutes whether implementation pays off.

Four document types, four approaches

There's no single "OCR system". The approach depends on how structured the document is.

With handwriting the rule is simple: automate the legible documents and route illegible ones to a person. Don't aim for 100% automation - aim for 80% automated and 20% quick review.

OCR plus a language model, or a multimodal model directly

Until recently the standard was a two-step process: OCR turns the image into text, then a language model extracts the data from the text. Today, multimodal models can read PDFs and photos directly. Which is better?

• OCR plus a language model - easier to control, cheaper at large scale, and each step has its own confidence measure. Good for high volumes and repetitive documents.
• A multimodal model directly - fewer moving parts, and it handles tables, stamps and page layout better. Good for varied documents and lower volumes.

In practice I often combine both: a specialized model for reading and a language model for interpretation and consistency checks.

The architecture step by step

1. 1.Intake. An email attachment, a Google Drive or SharePoint folder, a scan from a printer or a web form. n8n or Make starts the process.
2. 2.Preparation. Checking that the file is readable and not empty, rotating the scan, splitting multi-page files into separate documents.
3. 3.Type recognition. The model decides whether it's a contract, a report, a receipt or a letter - that determines which fields to extract.
4. 4.Data extraction. Reading and conversion into structured data (JSON) following a defined schema, with a confidence score for fields.
5. 5.Validation. Business rules: tax ID checksums, matching totals, sensible dates, whether the counterparty exists in the database, duplicate detection.
6. 6.Human review. Documents with low confidence or a validation error go to a queue. The reviewer sees the document and the filled-in fields - they only confirm or correct.
7. 7.Saving. Import into the ERP or CRM, renaming the file, moving it to the right folder, an entry in a spreadsheet.

An example of extracting data from a contract with a schema and validation:

import json, osfrom openai import OpenAIclient = OpenAI()MODEL = os.environ.get("EXTRACTION_MODEL", "gpt-5-mini")SCHEMA = {    "name": "contract",    "schema": {        "type": "object",        "properties": {            "doc_type": {"type": "string", "enum": ["contract", "amendment", "other"]},            "parties": {"type": "array", "items": {"type": "string"}},            "tax_id": {"type": ["string", "null"]},            "start_date": {"type": ["string", "null"], "description": "YYYY-MM-DD"},            "end_date": {"type": ["string", "null"], "description": "YYYY-MM-DD"},            "value_net": {"type": ["number", "null"]},            "notice_period_days": {"type": ["integer", "null"]},        },        "required": ["doc_type", "parties", "tax_id", "start_date", "end_date", "value_net", "notice_period_days"],        "additionalProperties": False,    },    "strict": True,}

def extract(text: str) -> dict: r = client.chat.completions.create( model=MODEL, messages=[ {"role": "system", "content": "You extract data from documents. If a field is not in the text, return null. Do not guess."}, {"role": "user", "content": text}, ], response_format={"type": "json_schema", "json_schema": SCHEMA}, ) return json.loads(r.choices[0].message.content)

def validate(d: dict) -> list: errors = [] if d["start_date"] and d["end_date"] and d["end_date"] < d["start_date"]: errors.append("End date before start date") if d["value_net"] is not None and d["value_net"] < 0: errors.append("Negative contract value") return errors

The schema enforces a valid response format, and validation catches errors the model won't notice on its own. Documents with errors don't go into the system - they go to the review queue.

Tools and prices

Prices come from vendor price lists in 2026 and may change, but they show the order of magnitude well: reading itself is cheap, and implementation cost lies in validation, integrations and handling exceptions.

A real case: order in Google Drive

A special case is a shared drive where everyone drops files any old way. Here AI doesn't just extract data but organizes the whole archive: it recognizes the document type, gives the file a descriptive name and moves it to the right folder.

Case study - a real estate agency with 15 agents. The agency produced hundreds of rental agreements and handover reports a month, and agents dropped them onto the drive with no structure. Finding the report for a specific apartment took tens of minutes. I built a scanner based on Google Apps Script and a vision model: AI recognizes the property address in the document's content, creates a folder for each unit and moves the documents into it. The system paid for itself in 22 days, the assistant who used to sort the drive by hand moved on to other tasks, and the time to find a document dropped from tens of minutes to a few seconds.

This is what the analysis of a single file looks like:

{  "type": "handover_report",  "address": "12/4 Example Street, Warsaw",  "date": "2026-04-28",  "target_folder": "Properties/Example-12-4/Reports",  "file_name": "2026-04-28_Handover_Example-12-4.pdf",  "confidence": 0.96}

Files with confidence below 0.85 go to a folder for review, and every rename and move is recorded in a log. Once documents have descriptions, you can build natural-language search on top of them ("show handover reports for apartments in Mokotów from 2025") - the technique described in the post on a company knowledge base with AI.

A three-minute payback calculator

Work out three numbers and plug them into a simple formula:

Annual cost of manual work = documents × minutes ÷ 60 × hourly cost × 12. In the example: 500 × 8 ÷ 60 × 60 × 12 = PLN 48,000. With 85% automation and the remaining documents reviewed in a third of the previous time, you recover about PLN 38,000 a year. Compare that with the cost of implementation and maintenance. In my experience, implementation clearly starts to pay off from around 200 documents a month. Below that, a ready-made subscription tool works better. I cover the full ROI method in the post on AI automation ROI.

What accuracy to expect

Aiming for 100% automation and 99% accuracy is expensive and unnecessary. My standard for production deployments:

• Critical fields (tax IDs, amounts, account numbers, dates) - at least 92% correct.
• Confidence threshold - documents below 85% automatically go to review.
• Automation - 80-85% of documents with no human involvement.
• The rest - review with pre-filled fields, not retyping from scratch.

Three pitfalls

• "Our documents are too varied." I hear this on every project. Before you rule it out, run a test on 50 real documents - the results are almost always better than expected.
• No validation. Without checking totals, tax IDs and duplicates, errors go straight into the ERP, tax returns and reports.
• Skipping GDPR. Contracts and HR documents contain personal data. Cloud processing requires a data processing agreement with the vendor, and for data that can't leave the company, local OCR and a local model remain. Details in the post on GDPR and AI.

Contracts are a case of their own: beyond extracting data, you often need to assess the clauses. I describe how to build that kind of review in the post on AI contract review.

---

I build document processing systems tailored to your documents and systems - from organizing Google Drive to contract review with validation and approval. I do this as part of AI process automation. Get in touch - I start with an accuracy test on 30 of your documents, so before I build anything you'll see real numbers.

Worth reading next:

• How AI Reads Invoices from Email and Enters Them into ERP
• AI Contract Review - Risk Analysis, Version Comparison and a Pre-Signing Checklist
• How to Build a Company Internal Knowledge Base with AI (RAG in Practice)
• Structured outputs from AI: Pydantic, Instructor and JSON Schema in production