Integrating AI into document workflow: where manual processing breaks
Manual processing of incoming documents almost always rests on a single shared department mailbox: scans, invoices, contracts, and requests lie in one stream, and email triage is done by an on-duty employee between their own tasks.
Until an email is opened, the document does not exist for the system — no number, registration date, or owner. Registration delay is measured in hours, and on peak days in days, and the regulatory deadline is violated before the document even enters work.
Loss of documents rarely looks like deletion. More often it is an email forwarded to a personal address "I'll deal with it later," an attachment that failed to open, a request left unanswered due to the wrong email thread. This can only be found by reconciling the mailbox with the register, and that is not done daily.
Duplicates in the register appear where there is no matching key: an invoice arrived both in accounting and in the shared mailbox, a copy of the contract lies both in the email body and in the attachment.
Manual registration creates two cards, and the flow diverges along two routes with different assignees; reconciling the pair back is more expensive the longer it lives.
Blurred responsibility for the route is a consequence of the same thing: the assignee is appointed upon reading, not by rule. While an employee is on vacation or an email went to their folder, the document remains without an owner.
The flow bottleneck here is not the speed of a person's work, but the absence of a deterministic path from email to card in the system — we analyze how this is closed.
Automation of incoming documents: deadlines, errors, operator relief
The incoming flow is scans, emails, PDFs with waybills, nested archives. Now an operator opens each document, reads the details, and manually creates a card in the EDMS: number, date, counterparty, amount, subject.
With a flow of several hundred documents per day, this is not "slow" but a queue: a document waits for registration for hours, and the morning peak load is spread across the entire workday.
We put document parsing at the intake: extraction of details, reconciliation against reference data and rules, and we send disputed cases to a human.
Each extracted value keeps a link to the source, so verification takes seconds — you can see which fragment the field was taken from.
The main class of failures — an error in a detail that surfaces later, in payment or reconciliation — is eliminated: the field is either filled confidently or marked for review.
Measurable effects: the path "received → registered" is reduced from hours to minutes, registration happens upon receipt, not as the operator becomes available. The share of input errors falls because values are taken from a single source rather than retyped by hand.
The burden on operators shifts from routine input to handling exceptions — the same people are enough for the increased flow without expanding staff.
We embed this into the working 1C:Document Management and other EDMS: the card, approval route, and access rights remain standard; only the source of field filling changes.
Methods of data extraction from incoming documents
Parsing an incoming document has two layers: first, text recognition from a scan or photo, then determining the document type and extracting fields.
The second layer is solved differently, and the choice of approach determines how much effort goes into maintenance and how the system behaves on an unfamiliar form.
| Approach | When it fits | Limitations |
|---|---|---|
| Rules and templates | Stable forms: invoices, acts, certificates from the same counterparties | A new layout means a new rule; breaks on a skewed scan and a changed template |
| Trained classifier | Mass flow of similar documents: classify by types and fields | Requires labeling and retraining when formats drift; recognizes rare types worse |
| Language model | Free form: contracts, letters where fields are hidden in the text | Requires checking the answer against the source fragment; higher response time |
| Hybrid scheme | Mixed flow: typical documents are parsed quickly, complex ones more accurately | More complex maintenance: two processing branches and routing rules between them |
In practice, the hybrid scheme covers most flows: typical documents go by rules in fractions of a second, non-standard ones go to the model where accuracy matters more.
Text recognition is kept in your own environment or given to an external service — this determines whether the document leaves your perimeter and how predictably parsing behaves on poor scans.
Processing pipeline: implementation stages from audit to handover
The pipeline is assembled for a specific document flow, not the other way around. We start with an audit: how many incoming documents arrive per day, which types account for the main share, where the operator spends time on moving data, and where on actual decision-making. This picture shows which routes are worth automating and which are cheaper to leave manual.
- Audit of document flow and systems. We export statistics by incoming types for a period, look at entry points — email, scans, portal, electronic exchange — and record which systems send and receive documents.
- Processing and routing scheme. We agree on what goes fully automatically, what goes to an operator for review, and what is rejected. We separately describe behavior at low recognition confidence.
- Setting up detail extraction. We assemble field dictionaries, templates of standard forms, and rules for normalizing dates, numbers, and counterparties — for the customer's real documents.
- Testing on historical documents. We run the settings on a sample of already processed incoming documents and compare the result with what operators entered manually.
- Integration with the accounting system and access rights. We check that the document lands in the right card, and access remains within existing roles.
- Pilot operation. We launch on one department or business line, compare actual accuracy with the measurement on the sample.
- Handover to operation and team training. We hand over regulations, settings, and clear instructions: how to fix a rule, what to do when handling a disputed document.
After handover, the metrics remain visible: the share of documents processed without manual intervention, the number of reworks, and typical causes of errors.
Delivery package: flow diagrams, rules, regulations
The delivery package is not a folder with a presentation, but a set of working artifacts that can be handed to a shift engineer or another contractor.
Everything is described so that changes are made by editing configuration, not rewriting code: rules are kept separate from processing logic.
What remains in your hands:
- Extraction configurations — which details we take from an incoming document, with labeling of reference samples and examples of non-standard forms.
- Route scheme — a map of incoming document types and points where automatic processing turns on and where a human is mandatory.
- Routing rules — by document type, sender, and department, with conditions for transfer to manual handling.
- Prioritization rules — what goes first under peak load and how the queue behaves if the external service is unavailable.
- Access policies — which roles see the source document, extracted fields, and processing history.
- Processing regulation — the procedure for low model confidence, a disputed detail, or repeated registration.
- Operator instructions — how to confirm or correct extracted data and where to look in case of failure.
- Journal and metrics — the share of documents that passed without human involvement, and the time from receipt to registration.
Each artifact is checked on your documents at acceptance: you accept not a description, but a working route on a real flow.
Case: processing incoming documents without manual sorting and losses
The customer's incoming flow went through three channels — corporate email, scans from paper, and a counterparty portal — and was handled manually.
An operator opened a document, determined the type, entered details, and chose a route: a document took 5–8 minutes, and 12–14% of routes were erroneous.
An invoice went to the wrong department, the response deadline to the counterparty was missed, and some emails remained in personal folders altogether.
Parsing was moved to a model: classification by types — contracts, invoices, claims, memos — extraction of details and amounts, reconciliation with the counterparty reference data.
Documents with high confidence go to 1C:Document Management on their own; the rest enter a queue for revision with fields already filled, not an empty card.
What the metrics showed
Registration time decreased from 6 minutes to 35 seconds, 88% of incoming documents are processed without human involvement, and the share of erroneous routes fell from 14% to 2%. Not a single document remains unprocessed for more than a day — previously such documents were lost.
The logic was not tied to one document type. A new type of incoming document is connected after brief additional training on operator labeling, and the system takes their corrections into training itself.
The implementation case showed the main thing: the flow stops depending on the attentiveness of a particular employee.
How does rule-based extraction differ from model operation?
Rules are a set of anchors and templates: we look for the invoice number after the word "Invoice" in the top block, verify details by checksum, and bring the date to a unified format. Parsing is deterministic: the same file always gives the same result.
Each field is traceable to a specific match — this is verifiability: you can see which condition fired and why. The flip side is rigidity. A supplier's form changed, the document went into a scan at an angle, a stamp covered an area — the rule will silently return an empty value.
The model works differently: it does not look for a template match but assigns a fragment to a field type based on the context of the entire document. Therefore, it parses non-standard scans and forms that no one described in advance without modifications.
The price is a probabilistic result: it requires a confidence threshold and verification, and errors are distributed unevenly across forms.
In practice, the choice is rarely binary. Stable fields with formal validation — numbers, codes, dates — we give to rules: there the extraction accuracy is close to absolute, and a miss is visible immediately.
Free-form wording, non-standard scans, attachments with an unfamiliar structure — to the model: describing them with rules is more expensive than labeling a sample of examples.
Verifiability remains key. A rule returns a trace of the fired condition, a model returns a probability and the supporting fragment, and a discrepancy between the two paths sends the document to the manual handling queue.
For each field we calculate accuracy, the auto-processing rate, and the return rate — they show where to fine-tune the model and where to add a rule.
Technical doubts: AI accuracy, labeling, access rights
Engineering doubts are usually not about whether the system can read text, but about behavior on poor scans, data access boundaries, and maintaining accuracy six months after launch. Below are answers to those most often heard in technical discussions.
What happens with poor scans, faxes, and copies?
Before recognition, the document is assessed for quality: skew, noise, cropped fields. If confidence is below the threshold, the document does not disappear silently — it goes to the manual review queue, so the share of automatic processing remains predictable. We adjust the threshold for a specific document type.
Where are documents processed and who sees the content?
Processing happens in the customer's environment; data is not given to external services. Rights are inherited from the EDMS: an employee sees the same documents as before, and access to the system is logged. Deleting a document means deleting its text in the storage as well.
How many examples need to be labeled?
For one document type, a few hundred labeled samples are usually enough. We label not the entire archive, but the disputed cases where the system makes mistakes — this makes labeling examples faster. The appearance of a new form adds samples; this is part of flow maintenance.
Does accuracy hold after launch?
We maintain a regression set and regularly run the flow through it: a change in a form template becomes visible before errors reach operators. Additional training on operator corrections raises recognition accuracy for key details.
Let's discuss the task: what is needed to assess your flow
To come back with an assessment and implementation plan rather than general considerations, we need an analysis of your specific flow. Below are the inputs by which we calculate effort, the order of work, and integration points.
If some data is missing, we will collect it together at the meeting; separate preparation is not needed.
- Document types: what goes in mass and what requires exceptions — invoices, acts, contracts, incoming correspondence.
- Flow volume: documents per day, peak periods, the share of operations currently done by hand.
- Current systems: what is in place now, who owns the environment, what data exchange channels exist.
- Integration points: where we embed — intake, registration, routing, approval, archive.
- Access requirements: where data is stored, who has access, whether there are restrictions on external services.
- Acceptance criteria: how we measure the result — the share of documents processed without corrections, time to registration.
- Priorities: which area we launch first and what we consider a completed stage result.
From these inputs, an implementation plan takes shape: a pilot on one document type, measurement of detail extraction quality on your sample, then expansion to other types and rollout into the working environment. Describe the task — we will come back with an assessment, plan, and scope of work.