The problem shows up identically in a records office, a credit office and a purchasing office: different documents, always the same information.
What follows is an illustrative scenario, built on the recurring use cases in the sectors we work in. It doesn’t refer to a specific client: named case studies get published after projects conclude and the relevant approvals are obtained. Where we report a figure measured on a real project, we say so explicitly.
The problem
An office receives several thousand documents a month from external parties. They come from different sources and none of them follows a format defined by the receiving organization.
The information to extract, though, is always the same: the party’s identifier, subject, amounts, dates, references to related documents.
Today the operation is manual. An operator opens the document, locates the information, transcribes it into the management system, checks it against what’s already on file, and archives it.
The costs are three. Time, spent on an activity nobody considers skilled work. Transcription errors, which surface downstream and require rework. And dependence on experience: the more senior operators recognize at a glance where to look for a piece of information in a given document type; new hires take months.
The analysis
The analysis covered four aspects, and produced the most useful outcome of the project: defining what to exclude.
Document types. A census over a representative period showed a sharp concentration: a few types covered the large majority of the volume, while a long tail of rare cases represented a minimal share.
Fields to extract. Not all of them carry the same value. Some are used in every downstream step, others rarely. The scope was narrowed to the fields actually used downstream.
The impact of an error, by field. An error in an amount has different consequences than an error in a description. This distinction determined where to set confidence thresholds and mandatory verification.
The quality of incoming files. A share of the documents turned out to be unprocessable automatically: low-resolution scans, photographs, protected files. This was identified as a separate flow, not a case to be solved.
What was excluded, and why
This section is the most useful for anyone evaluating a similar project.
Rare document types were excluded. The cost of configuration and maintenance wasn’t justified by the volume, and they remain manually processed.
Sporadically used fields were excluded. Every added field brings configuration, verification and maintenance.
Documents of insufficient quality were excluded, routed to a manual flow with an automatic notice to the sender about minimum file requirements.
Any judgment on the merits was excluded. The system extracts and flags; it doesn’t decide or classify risk.
And automatic writing into the management system without confirmation on economically material fields was excluded.
The solution
The system performs five operations.
It recognizes the document type. Below a confidence threshold, it routes to human review instead of proceeding.
It extracts the fields defined for that type, keeping, for each one, the link to its position in the source document.
It compares extracted values against data already present in the systems and against other documents in the same case file, flagging discrepancies.
It presents the operator with a record showing the extracted data, the confidence level per field, and a preview of the document with the positions highlighted.
It logs the operator’s confirmation or correction, which feeds into quality monitoring.
The architecture
Optical recognition with quality control on the incoming file and routing of unprocessable documents. Type classification. Field extraction with models that interpret text and page structure together, returning the source position. Deterministic rules for validations expressible as conditions: tax-code format, date consistency, amount totals. Read integration with master data and, on write, with the management system, subject to confirmation. Full logging of every extraction, confirmation and correction.
A point of method: validations that could be expressed as rules were implemented as rules. They’re more reliable, cheaper, and easier to explain during an audit.
The implementation
Rollout in three phases.
First phase running alongside the existing process: the system extracts, the operator works as before and compares. This measures real accuracy and builds trust.
Second phase in production on the highest-volume type, with mandatory verification on all economically material fields.
Third phase extending to the other types within scope, with thresholds calibrated on the data collected.
Training included the errors found during testing, with real examples.
The results
Indicators were recorded before launch and measured afterward: average processing time per document, transcription errors detected downstream, share of documents handled without corrective intervention, time to autonomy for newly onboarded operators.
The return shows up in hours freed, reduced rework, and less dependence on individual experience.
On a real project in manufacturing, with similar characteristics applied to technical CAD drawings, we measured 86 percent accuracy in automatically extracting dimensional callouts from the client’s real drawings, with low-confidence cases flagged for review by the technical office. This is the order of magnitude to expect on non-standardized documentation, and the reason human review on uncertain cases is part of the architecture rather than a fallback.
What it didn’t solve
It didn’t solve the quality of incoming files, which depends on the senders.
It didn’t eliminate manual processing, which remains for the excluded types and for unprocessable documents.
It didn’t reduce overall procedure time where the bottleneck was downstream of extraction.
And it required stable ongoing ownership: periodic accuracy checks, analysis of corrections, updates whenever incoming formats change.
In closing
What determines the outcome of a project of this kind isn’t the extraction technology, which by now is mature. It’s the definition of scope: which types, which fields, which thresholds, what stays manual.
A narrow, well-defined scope produces a reliable system. A broad scope produces a system that works half-well at everything.
The scenarios and projects we publish are available on the site. If you have a document flow with these characteristics, we’re available for a conversation about your case.
