AI in Document Workflow: Automation Without an EDMS

In short

An LLM agent is a program in which a language model (Claude, GPT) runs a chain of actions on its own: reads a document, extracts data, runs checks, writes a row into a register. For small and mid-sized business it's a way to clear the routine of inbound paperwork — parsing contracts and primary accounting documents, keeping registers, checking legal details — without buying an EDMS (СЭД, an internal electronic document management system) for hundreds of thousands of rubles. The working combination: Claude Code plus an engine that keeps the agent inside the process. A prototype takes 1–3 evenings; stabilizing it on a real document flow takes 2–4 weeks. The limits are honest: an agent won't replace legally binding exchange with counterparties (VAT invoices, universal transfer documents) — that's the job of an EDO operator (a licensed e-document exchange provider) — and approval routes involving dozens of people are EDMS territory. Below: a reproducible recipe, a comparison table, and what to keep in mind under 152-FZ (Russia's personal data law).

What an LLM agent does in document workflow

Let's separate three tools. An EDMS is a system for handling documents inside a company: approval routes, versions, an archive, execution control (1C:Document Management, Directum, ELMA365). EDO is legally binding document exchange with counterparties through an operator (Diadoc, SBIS) using a qualified electronic signature. An LLM agent is a third layer that doesn't replace the first two — it covers what they handle poorly: unstructured routine.

What the agent does well:

• extracts fields from contracts and primary documents: counterparty, INN/KPP (Russian tax and registration IDs), number, date, amount, VAT rate, subject, deadlines;
• reads scans and messy PDFs — a multimodal model parses a page image without a separate OCR service;
• maintains a register in Excel, Google Sheets, or a database and files documents into folders with meaningful names;
• flags anomalies: VAT that doesn't add up, an expired contract, a duplicate invoice.

What it doesn't do: it doesn't sign, doesn't approve on people's behalf, and doesn't give documents legal force. For an overview of the whole task class, see the article on AI agents for business.

The recipe: an inbound-parsing pipeline without an EDMS

The reference task: contracts, invoices, and acceptance certificates land in your inbox, and you need a register plus early detection of problems before the documents reach accounting. A six-step pipeline:

1. Intake. An "Inbox" folder synced with mail or cloud storage. Formats: PDF, DOCX, JPG scans.
2. Reading. A digital PDF is read directly; a scan is parsed by the model as an image. No separate recognition step is needed at the start.
3. Extraction. The model gets a strict field schema and the rule "if unsure, write null and raise a flag." That's the main defense against invented details.
4. Validation in code. Anything deterministic is not left to the model: the INN checksum, the KPP format, the arithmetic of "net + VAT = total," a date within a sane range. The agent writes this code once, and from then on the checks run without the model.
5. Register. A row in the table, the file renamed to a mask like "2026-07-17_Romashka-LLC_contract-14.pdf" and moved into the folder structure.
6. Exceptions. Flagged documents go to a "Handle manually" folder plus a Telegram notification. A human only looks at those.

The principle behind the whole design: the model extracts, code verifies, a human decides. Approval and signing stay with people — that's the red line.

How to reproduce it in Claude Code: a step-by-step plan

There's no code in this article — the agent writes it. Your job is framing the task and accepting the result.

1. Assemble a sample: 20–30 real documents, a third of them "bad" — crumpled scans, non-standard counterparty templates.
2. Describe the register schema: which fields the accountant and the lawyer actually need. Ten fields beat forty.
3. Brief the agent in Claude Code: goal, field schema, validation rules, naming mask, folder structure. The Quest engine isn't mandatory here — the pipeline comes together without it — but it removes the usual pain: it holds the decomposition and the context so the agent doesn't drift on a multi-step task and the result stays reproducible. For pipelines involving tables and reports there's the Data Insight module.
4. Run the sample and measure per-field accuracy. INN numbers, amounts, and dates should match almost 100% of the time — thanks to code validation, not faith in the model. Free-form fields like the contract subject can be corrected by hand without drama.
5. Set a confidence threshold: at the start everything suspicious goes to manual review; as statistics accumulate, you lower the threshold.
6. Automate the trigger: cron or a watched folder. The register updates itself and you only handle the exceptions.

Honest timelines: prototype — 1–3 evenings; stabilization on a live flow — 2–4 weeks of tweaks. Ready-made cards on process automation live in the free Business arsenal section. A prompt template for extracting contract fields is in the pinned post of the Telegram channel t.me/qvib.

LLM agent, EDMS, or manual work: what to choose

Bottom line: these aren't competitors, they're layers. The typical SMB stack is EDO as the channel for legally binding exchange and an LLM agent as the "hands" that parse the whole inbound flow and keep the registers. An EDMS gets added once the number of approvers grows. On the "build it yourself or hire a contractor" dilemma there's a separate breakdown.

When you can't do without an EDMS and EDO

• Legal validity. Electronic VAT invoices and universal transfer documents travel only through an EDO operator with a qualified signature; for traceable goods, electronic exchange is an obligation, not a choice.
• Approval routes. A document signed off by five or more people with roles, delegations, and deadlines calls for a mature EDMS, not a script.
• An audit trail for inspections. Regulated industries need immutable action logs.
• HR document workflow. It has its own regulation in the Labor Code — not a place for DIY.

A practical sign that it's time to look at an EDMS: you've automated inbound parsing, but documents still get lost during human approval.

What about personal data

Contracts and primary documents almost always contain personal data: signatories' names, sole proprietors' passport details, representatives' phone numbers. Sending a document to a cloud LLM means transferring data to the provider's server, usually a foreign one. The practical minimum:

• start with the flow that contains the least personal data — inbound invoices from legal entities, for instance;
• mask anything extra before calling the model: the agent strips passport details and phone numbers with regular expressions on its own side;
• write down what may and may not be sent to a model in an internal AI usage policy;
• for strict requirements there are local models, but that's a different budget and a different quality level.

A breakdown of the legal requirements is in the article on AI and 152-FZ; the technical risks of agents are covered in the piece on vibe coding security. This is not legal advice: auditing a specific process needs a personal data lawyer.

Honestly about qvib

qvib.pro is one person and AI. We sell the Quest engine (4 900 ₽ one-time) and modules for it at 1 900 ₽ each — a box and knowledge, not implementation services. You build the pipeline from this article yourself: the knowledge base with 500+ cards is free, and the engine is there so the agent holds a complex task steadily. Don't want to do it yourself? Hire an integrator; for agencies that do the rollout we have a partner program with a 25–40% commission.

FAQ

Won't the model invent details in the register?

It will, if you let it. That's why details, amounts, and dates are checked by ordinary code — the INN checksum, VAT arithmetic — and the model is required to write null instead of guessing. Only validated rows reach the register; the rest goes to a human.

At what monthly document volume does this pay off?

A rough benchmark: 100–200 inbound documents a month, which is 10–20 hours of manual parsing the agent takes off your hands. It works at smaller volumes too, but the payoff is in nerves more than money.

Can outbound documents be prepared this way?

Drafts, yes: the agent assembles a contract from a template and counterparty data. But sending legally binding documents happens only through an EDO operator with a signature. The agent prepares, a human checks and signs.

Do I need a separate OCR service for scans?

Not at the start: multimodal models read a page image directly. A dedicated OCR pays off at high volumes of poor scans, when it's cheaper to send already-recognized text to the LLM.