In many companies, employees manually open emails, download attachments, copy information from invoices, contracts, delivery notes, and forms, and then enter it into a CRM, ERP, accounting platform, or internal system.

This work appears simple but creates persistent cost and risk:

• employees spend hours on repetitive data entry;
• documents are routed to the wrong person;
• dates, amounts, and account details are copied incorrectly;
• information is stored in several locations;
• approvals are delayed;
• management cannot see the current document status;
• quality depends on the attention of one employee.

AI can reduce a significant part of this work. However, document automation is not simply a matter of uploading a PDF to a language model and trusting the response.

A working system must be able to:

1. receive the document;
2. determine its type;
3. extract the required fields;
4. validate the data;
5. apply business rules;
6. route uncertain cases to an employee;
7. write the result into the correct system;
8. maintain a complete activity history.

The correct question is not:

“Can AI read our documents?”

It is:

“Which part of the process can be automated reliably, what does it currently cost, and which decisions must remain under human control?”

What is intelligent document processing?

Intelligent Document Processing combines several technologies:

• OCR for printed and handwritten text;
• page-layout analysis;
• document classification;
• field and table extraction;
• data validation;
• business rules;
• integrations;
• human-in-the-loop review;
• quality analytics.

Modern document-processing services can extract text, tables, structure, and key-value pairs and can use prebuilt or custom-trained models for particular document types.

For example, a system may identify an uploaded file as an invoice, locate its number, date, supplier, currency, total, and line items, and then pass the structured data to an accounting system.

Text recognition is only the first stage. The business does not need raw text from a PDF. It needs the correct action to be performed using that text.

How does OCR differ from complete automation?

OCR converts an image or scan into machine-readable text.

It may detect:

• words;
• lines;
• paragraphs;
• element positions;
• printed text;
• in some cases, handwriting.

Specialised platforms can also extract forms, tables, signatures, and specific queried values.

However, basic OCR does not know:

• which document type it is reading;
• which fields matter;
• whether an amount is valid;
• whether the supplier exists in the master data;
• whether the document has already been processed;
• whether approval is required;
• whether a payment may be created automatically;
• who owns an exception.

A complete system must therefore be designed around the entire business process rather than a single recognition model.

What does the processing workflow look like?

1. Document intake

A document may arrive through:

• email;
• website form;
• mobile application;
• messaging bot;
• cloud folder;
• scanner;
• CRM;
• partner API;
• internal system.

The original file, source, receipt date, and relationship with a customer, order, or supplier should be preserved.

When documents continue to arrive in employees’ personal conversations, automation cannot cover the complete flow.

2. Preprocessing

Before recognition, the system may:

• split a multi-document file;
• rotate an image;
• deskew the page;
• improve contrast;
• detect language;
• remove empty pages;
• assess readability;
• reject damaged files.

Image quality directly affects the result. Blur, cropped edges, shadows, very small type, and complex backgrounds increase the probability of error.

3. Classification

The system identifies the document type:

• invoice;
• completion certificate;
• contract;
• delivery note;
• identity document;
• CV;
• application;
• power of attorney;
• transport document;
• internal report.

Classification matters because each document type requires a different extraction schema and validation process.

Some platforms can split a PDF containing several separate documents and classify each part independently.

4. Data extraction

After classification, the system extracts the required values.

For an invoice, these may include:

• number;
• date;
• supplier;
• tax identifier;
• bank details;
• currency;
• line items;
• quantities;
• prices;
• tax;
• total amount.

For a contract:

• parties;
• subject;
• term;
• value;
• liabilities;
• termination conditions;
• expiry date;
• signature presence;
• related appendices.

Prebuilt models are suitable for common formats. A custom model and schema can be created for internal or industry-specific documents using the company’s examples.

5. Normalisation

Extracted data must be converted into consistent formats.

For example:

• 01.07.2026, 1 July 2026, and 2026-07-01 become one date;
• 12 500,00, 12,500.00, and 12500 become one numeric value;
• variations of a company name map to one supplier record;
• currencies use standard codes;
• addresses and phone numbers are cleaned.

Without normalisation, a system may treat equivalent values as different.

6. Validation and business rules

A field being extracted does not mean it is correct.

The system may verify:

• whether line items add up to the total;
• whether the supplier exists;
• whether the contract matches the purchase order;
• whether the expiry date has passed;
• whether the document is a duplicate;
• whether mandatory details are present;
• whether a limit has been exceeded;
• whether the currency matches;
• whether a signature is present;
• whether the supplier is approved.

At this stage, deterministic rules are often more important than generative AI.

When an amount must exactly match a purchase order, the system should compare the two values directly rather than ask a model whether the document “looks correct”.

7. Confidence assessment

Document-processing models commonly return confidence scores for detected elements.

There is no universal threshold such as “anything above 90% is safe”.

The threshold should depend on:

• the field;
• the cost of error;
• document quality;
• measured test performance.

For example:

• a free-text note may accept a lower score;
• a bank account, total amount, and customer identifier require strict validation;
• a change in payment details may always require manual confirmation.

AWS recommends using confidence scores and adjusting process sensitivity to the specific use case.

8. Human review

Employees should receive exceptions rather than every document:

• a field is missing;
• values conflict;
• image quality is poor;
• a new format is detected;
• the amount exceeds a limit;
• the supplier cannot be found;
• the document may be a duplicate;
• the operation is high risk.

The review interface should show:

• the original document;
• the extracted value;
• its location on the page;
• the reason for review;
• the proposed value;
• change history.

The objective is to turn hours of manual entry into minutes of informed review, not to remove people from every stage.

9. Downstream delivery

Validated data may be sent to:

• CRM;
• ERP;
• accounting software;
• document-management system;
• storage;
• spreadsheet;
• approval queue;
• internal portal;
• analytics platform.

The system may then:

• create a record;
• attach the original;
• assign an owner;
• begin approval;
• send a notification;
• update a status;
• create a task;
• return the result to the sender.

Where is automation most useful?

Invoices and accounting documents

The system may extract details, amounts, and line items, validate the supplier, detect duplicates, and create a draft transaction.

Microsoft, for example, provides a specialised invoice model that extracts key fields and line items from scans, photographs, and digital PDFs.

Final payment execution should not depend only on model output.

Delivery notes and completion certificates

The system may validate:

• order number;
• parties;
• dates;
• quantities;
• value;
• signature presence;
• differences from a contract or order.

Contracts

AI can help:

• classify an agreement;
• extract critical terms;
• identify dates and values;
• detect missing sections;
• compare the file with a template;
• create expiry reminders;
• route the document to the appropriate legal specialist.

A disputed legal provision should not be evaluated entirely by a model.

Logistics

Automation can be applied to:

• transport documents;
• packing lists;
• customs forms;
• delivery confirmations;
• acceptance records;
• route documentation.

It becomes particularly valuable when the same information is repeatedly entered into several systems.

HR processes

A system may process:

• CVs;
• applications;
• questionnaires;
• identity documents;
• agreements;
• timesheets;
• certificates;
• leave requests.

Decisions affecting recruitment or employee status require additional rules for oversight, access, and explanation.

Customer applications

Free text and attachments may be used to extract:

• contact details;
• request type;
• product;
• amount;
• region;
• deadline;
• attached documents;
• missing information.

The application can then be classified and routed to the responsible department.

Archives

OCR and classification can convert an old archive into a searchable dataset.

Before large-scale processing, determine:

• which documents are genuinely needed;
• which data should be extracted;
• how long originals must be retained;
• who may access them;
• whether a legally significant original is required.

When does automation pay off?

A project is more likely to be justified when:

• document volume is meaningful;
• documents repeat by type and structure;
• employees enter the same fields repeatedly;
• manual processing delays the next stage;
• errors create financial or operational loss;
• data must already enter a digital system;
• validation rules can be defined;
• the process has an owner;
• quality can be measured.

The number of manual actions matters more than the number of pages.

One hundred short, consistent invoices may be a better automation candidate than one thousand rare and highly individual contracts.

When is the project premature?

Low document volume

When an employee processes only a few files each week, development and maintenance may cost more than the savings.

Every document is unique

Lower repetition makes it harder to define a stable extraction schema and validation rules.

The process changes constantly

Automating an undefined process is risky.

First define the stages, owners, required data, exceptions, and final outcome.

Input quality is poor

When most files are unreadable photographs, improve the intake channel and quality requirements before building advanced automation.

There is no destination system

Extraction has limited value when employees must still copy the output manually into several applications.

No one owns exceptions

New layouts and failures will always occur.

It must be clear who reviews them, within what time, how corrections are stored, and who updates the rules.

How should the business case be calculated?

Current process cost

Calculate:

• documents per month;
• average handling time;
• fully loaded employee cost;
• secondary review time;
• number of corrections;
• cost of delay;
• cost of errors;
• number of returned documents;
• approval duration.

New system cost

Include:

• process analysis;
• representative document preparation;
• extraction-schema development;
• integrations;
• review interface;
• testing;
• infrastructure;
• per-page processing fees;
• storage;
• monitoring;
• support;
• model and rule updates.

Simplified formula

Monthly effect = labour saved + losses prevented + additional processing capacity − monthly system cost.

Payback period = initial investment / monthly net effect.

Example

Assume:

• 6,000 documents per month;
• three minutes of manual handling per document;
• fully loaded employee cost of $9 per hour;
• 70% of documents are processed automatically;
• the rest require one minute of review;
• monthly infrastructure and support cost $1,200;
• implementation costs $24,000.

Current workload:

6,000 × 3 minutes = 18,000 minutes, or 300 hours.

After automation, approximately 30 hours of manual review remain.

Potential labour saving:

270 hours × $9 = $2,430 per month.

After monthly system cost, the net saving is approximately $1,230, before prevented errors and faster cycle times are considered.

This is why a claim that the system “will pay for itself in a few months” is meaningless without operating data.

Which metrics should be monitored?

Straight-through processing rate

The percentage of documents completed without human intervention.

It should not be increased at the cost of hidden errors.

Field accuracy

Measure individual fields separately:

• dates;
• amounts;
• account details;
• identifiers;
• table rows;
• free text.

Average document accuracy may hide poor performance on one critical field.

Exception rate

Track both the number and causes of documents sent to review:

• poor image;
• new layout;
• missing field;
• conflicting data;
• integration error.

End-to-end processing time

Measure the time from receipt to successful delivery into the target system, not OCR speed alone.

Cost per document

Include:

• API usage;
• infrastructure;
• manual review;
• support;
• error correction.

Corrections after automatic acceptance

When employees repeatedly correct documents after they have been accepted, a high automation rate creates false confidence.

Security and data control

Documents may contain:

• personal data;
• financial information;
• contractual terms;
• trade secrets;
• identity information;
• bank details.

Before selecting a platform, determine:

• where files are stored;
• in which region they are processed;
• whether data is sent to an external model;
• whether it is used for training;
• how it is encrypted;
• who has access;
• how activity is audited;
• when originals are deleted;
• how employee and contractor access is removed.

Official platform guidance also notes that financial, medical, personal, and other sensitive documents require attention to relevant regional and industry requirements.

When generative models are used, risks involving inaccurate content, privacy, and information security should be managed throughout the system lifecycle.

Off-the-shelf service or custom system

An off-the-shelf service is suitable when

• documents are common and standard;
• standard extraction is sufficient;
• integrations are simple;
• volume remains modest;
• the business needs to test the hypothesis quickly;
• the provider’s interface is acceptable.

A custom system is justified when

• the process is business-critical;
• several document types are involved;
• complex validations are required;
• several internal systems must be integrated;
• a dedicated review interface is needed;
• special access rules apply;
• a complete audit trail is required;
• automation becomes part of the core product.

A hybrid architecture is often optimal: an established OCR or Document AI service is used as infrastructure, while business rules, validation, review, and integrations are developed for the company.

How should implementation proceed?

1. Select one document type

Do not begin with every invoice, contract, application, and archive at once.

A strong first candidate:

• occurs frequently;
• has a recognisable structure;
• contains repeated fields;
• requires substantial manual work;
• produces a measurable result.

2. Collect a representative dataset

Do not include only perfect files.

Include:

• different suppliers;
• scans;
• phone photographs;
• digital PDFs;
• poor quality;
• multiple languages;
• long tables;
• missing fields;
• incorrect documents.

3. Establish ground truth

Correct values should be manually recorded for the test dataset.

Without ground truth, quality cannot be measured objectively.

4. Separate fields by risk

For example:

• low risk — comment;
• medium risk — date;
• high risk — amount, account number, identifier, and payment details.

Each group receives its own automatic-acceptance rules.

5. Run a pilot

The pilot should test the complete workflow:

• intake;
• recognition;
• extraction;
• validation;
• review;
• integration;
• audit.

A demonstration using ten perfect PDFs does not prove production readiness.

6. Use shadow mode

Initially, the system can process real documents in parallel with employees without executing irreversible actions.

This allows results to be compared and thresholds to be adjusted safely.

7. Automate only validated cases

Begin by automatically processing only simple, reliable documents.

Other cases continue to go to an employee.

Expand the boundaries after collecting evidence, not based on vendor promises.

What should you ask a contractor?

1. Which document type will be automated first?
2. Which fields must be extracted?
3. Which fields are critical?
4. How will accuracy be measured?
5. Which documents are included in testing?
6. What happens when confidence is low?
7. How does human review work?
8. How are duplicates detected?
9. Which business rules are applied?
10. Where is the result delivered?
11. How are documents and personal data protected?
12. Where are audit logs stored?
13. What is the processing cost per page?
14. Who updates the model and rules?
15. What happens when the AI service is unavailable?

Conclusion

AI can substantially reduce manual document processing, but value is not created by text recognition alone.

A working system combines:

• a reliable intake channel;
• classification;
• data extraction;
• deterministic validation;
• confidence thresholds;
• human review;
• integrations;
• audit;
• continuous quality measurement.

Removing humans completely should not be the objective. The objective is to process clear, low-risk cases automatically and leave exceptions and accountable decisions to employees.

Assess the potential of document automation

Describe the document types, monthly volume, current workflow, and the systems into which employees manually enter the data.

The Prodexa team will help you:

• select the strongest first use case;
• calculate the current processing cost;
• define fields and validation rules;
• design human review and integrations;
• run a pilot before a larger implementation.