Classification by document type
The system assigns each incoming document to one of the types you define beforehand, and derives from that which fields are expected at all.
Blueprint 04
Document Operations
Recognise documents, check them and write the results back into your existing systems
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.
Part of
AI Process AutomationStarting point
The problem.
Documents arrive from several directions: as attachments in a mailbox, as scans from a multifunction device, as forms from a portal. Each one is opened, read, assigned to a document type and then retyped into another system. Who handled which document, and when, can afterwards only be reconstructed from folder structures and email threads.
Before · After
The same process, twice.
On the left, the process as it typically runs today. On the right, the same process once an application takes over the repetitive steps.
Today
How the process runs if nobody changes anything.
- 01Scan mailbox and foldersHuman
- 02Open and read documentHuman
- 03Decide the document typeHuman
- 04Determine responsibility from memoryHuman
- 05Type data into systemHuman
- 06Mandatory field check in systemSystem
- 07File document in folderHuman
- 08Forward case by emailHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Incoming item captured automaticallySystem
- 02Document type is classifiedSystem
- 03Fields are extractedSystem
- 04Rule check flags certain or reviewSystem
- 05Case handler approvesHuman
- 06Target systems are updatedSystem
- 07Every step is loggedSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Interactive
The process, station by station.
The walkthrough stops at the point where a person decides. It continues only once you approve.
Document processing
Step 1 of 6
- Intakerunning
- Read documentwaiting
- Extract fieldswaiting
- Rule checkwaiting
- Human approvalwaiting
- Update systemwaiting
Input
eingang@musterlieferant.de
Auftrag M-0001 — Muster Industrie GmbH
auftrag-M-0001.pdf
Sample data. Sender, subject and values are recognisably invented — there is no real document behind this.
Recognition quality
- certainSendereingang@musterlieferant.de
- certainCustomerMuster Industrie GmbH
- certainOrder numberM-0001
- checkItemMusterartikel A
- checkDelivery addressMusterweg, Musterstadt
- checkContactM. Mustermann
The application marks which fields it recognises with certainty and which a person has to confirm. Two levels by design instead of a percentage — there is no measurement a percentage could come from.
A message with a PDF attached would reach the order mailbox and be filed as a case, with sender and attachment kept unchanged.
This process is a draft, not a running system. Everything shown is invented, and the steps describe how NeXsoft would build such a pipeline. Recognition quality would be shown as certain or review, and approval would stay with a responsible person — which document types, fields and rules apply in your organisation would follow from your own process. The processing runs in your browser along a fixed sequence — nothing is uploaded, nothing is sent and no language model is called.
- A message with a PDF attached would reach the order mailbox and be filed as a case, with sender and attachment kept unchanged.
- The system would open the attachment and read its text and layout, so nobody has to retype the document.
- The fields defined for this document type would be pulled from the page — sender, customer, order number, item, delivery address and contact.
- Every extracted field would run against your rule set and receive the marking certain or review.
- A responsible person would see the original beside the extracted fields, correct whatever needs correcting and grant approval.
- After approval the system would write the data into the system of record and record every step in the log with a timestamp and the person who acted.
Features
What the system would need to do.
Every line is a commitment about future work — not a description of something that already exists.
Field extraction against a schema
Each document type carries a schema stating which fields are pulled and what type they have; anything that does not fit that schema does not pass on.
Two-level recognition marking
Every extracted field carries one of two markings, certain or review, and only the second level forces a human to look at it.
Review screen with original
During review the extracted fields sit directly beside the original page, so a correction is possible without switching between programs.
Rule set per document type
Business rules such as mandatory fields, value ranges, duplicate and deadline checks are held as a readable rule set rather than scattered through program code.
Log for every processing step
For each document it remains traceable afterwards when each step ran, what the system decided and who granted approval.
Integration
What a system like this typically connects to.
Categories rather than vendor names — which product you run is decided by the system landscape you already have.
Email mailboxes and scan intake
DMS or central file storage
ERP or inventory management
CRM or sector-specific business software
Directory service for sign-in and roles
Architecture
How this would be built.
One example structure in layers. Not the only one possible — but one we can justify.
Intake
- Watcher for mailboxes and folders
- Unchanged storage of the original file
- Queue with retry on failure
Processing
- Text and layout recognition
- Classification by document type
- Field extraction against a schema
Decision
- Rule set per document type
- Review screen with approval
- Escalation on missing fields
Connection and evidence
- Connectors to the target systems
- Event log per document
- Role and permission model
Metrics
How success would be measured.
These are the figures that would be measured during a project. Deliberately no values are shown — there is no measurement they could come from.
Share of documents handled without manual intervention
would be taken as the ratio of documents approved without correction to all documents received
Turnaround time from intake to approval
would be calculated from the timestamps in the event log
Correction rate per field
would be taken from the changes made in the review screen
Share of fields marked review
would be counted per document type from the marking set by the rule check
Number of rejections from the target systems
would be captured through the error messages returned by the connectors
Expansion
Start small, then grow.
A project of this kind does not begin with the full build. It begins with the part that carries its weight soonest.
First stage
One document type, one intake channel, one target system — with the full review screen, so that the rules can be sharpened against real documents.
Second stage
Further document types and intake channels are added, the rule set grows, and approvals can be steered separately by responsibility and value.
Third stage
The accumulated stock becomes searchable, reporting on turnaround times and corrections is added, and adjacent processes are connected.
Do you recognise your own process?
If you recognise this process in your own organisation, we will walk through it in a first conversation using your own document types.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.