Document processing with AI: classify, extract, validate

What AI document processing is and why it matters#

AI document processing is the process in which a system automatically recognizes the type of a document, pulls out the relevant data, and checks whether that data is correct and complete before it enters a business system. It consists of three steps: classification, extraction and validation. In practice this means contracts, invoices, delivery notes, applications, forms and correspondence are no longer retyped by hand. Instead, the system sorts each document by type, reads the key fields and checks them against rules the client defines before the data reaches an ERP, CRM or document system.

In organizations with more than a million euros in annual revenue, documents rarely stay within a single department. They move through procurement, finance, legal, HR or production, and each department applies its own rules and enters the data into its own system. When that path is manual, delays, duplicate entry and transcription errors follow. AI document processing does not replace human judgment; it takes over repetitive reading and data entry so people can focus on reviewing exceptions and making decisions.

Epix builds software that applies AI over internal data, documentation and business processes on projects such as Kwizmo, where we built a solution with AI agents, semantic search (RAG), document processing and integrations into existing systems. We deliver this kind of work within Epix and our specialist partner network, assembling AI and data specialists, integration architects and business analysts as a project requires.

The rest of this article covers what a client needs to decide before starting an AI document processing project: how documents are classified, which data is extracted, how it is validated before entering business systems, how the solution connects to an existing ERP, CRM or document system, and how security, testing and post-launch support are organized.

Classifying documents: what needs to be defined#

Classification is the first step in AI document processing: the system sorts a document into the right category before it reads anything from it. Without clearly defined categories, the system has no rules to follow when it later extracts and validates data. The first task on any project is therefore to list the types of documents entering or leaving the organization and define what distinguishes them from one another — by content, origin, format or how they will be used further down the process.

How classification is set up determines how reliably the system later tells similar documents apart, for example different contract types, or an invoice from a credit note. Categories that are too broad increase the share of documents a person has to review; categories that are too narrow increase the number of exceptions that need manual handling. The right balance is set based on how the data from each category will later be used in the business process.

Mapping categories and rules is not a one-off task. When new contract types, forms or suppliers enter the business, classification rules need updating, otherwise the system misclassifies new documents or flags them as exceptions. We build in a mechanism for adding new categories and for tracking the share of documents the system fails to classify reliably, since that share shows where rules need refining or the model needs further training.

Defining categories and rules is the client's responsibility, since the client understands the content and purpose of its own documents, while the contractor turns those rules into a working system. On larger projects this is coordinated with a project lead who determines who on the client side approves categories and who owns rule changes once the solution is in production.

• the document types the system will handle and their expected share of overall volume
• the channels documents arrive through (email, scanning, portal, system transfer)
• the languages the documents are written in
• how standardized the document format is (fixed templates or free-form attachments)
• rules for edge cases the system cannot reliably classify
• the departments or systems each document category is routed to

Extracting data from documents#

Extraction is the step where the system pulls concrete data out of an already classified document — amounts, dates, tax numbers, line items, customer names or product codes — and writes it into a structured format ready for further processing. Whether this is straightforward depends on the document: standardized forms with a fixed layout are easier to read than free-form documents such as contracts or letters, where a field has to be found by meaning rather than by position on the page.

Which fields to extract, and to what accuracy, is determined by where the data will go next. If extracted data is written directly into an ERP or CRM, it has to match the existing fields and formats of those systems, otherwise import errors or duplicate records follow. Before extraction begins, we agree with the client on the list of target fields, their format, and the system each field is written into, along with what happens when a field is missing or unreadable.

For every extracted field, the system also calculates how confident it is in the result. When confidence falls below an agreed threshold, the document is not entered automatically; it goes into a queue for manual review. Where to set that threshold is the client's decision, weighed against how costly a wrong entry would be compared with the time an employee spends reviewing it. Financial and contractual data typically gets a stricter threshold than general reference data.

We build extraction using natural language processing and text recognition for scanned documents within Epix and our specialist partner network, drawing on staff experienced in sectors such as banking, insurance, the public sector and healthcare — industries where document volume is usually highest.

• the list of fields to extract from each document type
• the expected format of each field (date, amount, code, etc.)
• the target system each extracted field is written into (ERP, CRM, document system)
• the confidence threshold below which a field is flagged for manual review
• how missing or unreadable data is handled
• the link between extracted data and existing records, such as a customer or order

Validating and checking extracted data#

Validation is the final step before data from a document becomes part of a business record. The system compares extracted data against rules the client defines — for example, whether an invoice amount matches the purchase order, whether a tax number has a valid format, whether a date is not set in the future, and whether the document has already been processed. Only once a field passes these checks is it written automatically into an ERP, CRM or document system; otherwise the document is returned for review.

Which validation rules apply depends on how critical the data is to downstream operations. Financial documents such as invoices or payment orders typically carry stricter rules, including cross-checks against other records, while internal correspondence needs only basic format checks. The client and contractor agree together on which rules are mandatory, which are advisory only, and who signs off when the system cannot confirm a value automatically.

AI validation does not mean the system decides on the content of a document; it means a person receives a decision already prepared, with deviations clearly flagged. This works as decision support: an employee sees which value deviates from what was expected and why, instead of reviewing every document from scratch. Final sign-off stays with the employee or with whichever process the client puts in place for it.

For documents relevant to audit or compliance, it also has to be defined how the system records who reviewed, changed or approved a value, and how long that trail is kept. This matters in particular in the public sector and regulated industries, where it must be possible to trace at any time how a piece of data entered the system and who is responsible for it.

Connecting to existing systems: ERP, CRM, DMS, ECM#

AI document processing is not a standalone application; it has to connect to the systems a company already runs its business on. Before a project starts, it has to be clear which systems the solution needs to connect to — most often an ERP for finance and procurement, a CRM for customer data, and document (DMS) or archival (ECM) systems where documents are stored long-term. These connections are built through APIs, which means it has to be known what data is available through those interfaces and in what format.

The quality and scope of existing APIs directly affects how much integration work is needed. If a target system already exposes an API for writing records, extracted data can flow in almost directly. If no such interface exists, or it is limited, an extra step is needed to prepare the data for import, or the target system's own provider has to be involved in agreeing how data is exchanged. This has to be clarified before scoping the project, not during delivery.

For companies that already have a partly built document-processing solution or an unfinished integration project, we can take over the existing system after reviewing its source code, architecture, infrastructure and data. That review tells us which parts can be kept, which need adapting, and which are worth rebuilding, rather than starting the whole project from scratch without reason.

Source code and data remain the client's property in every case. Documentation, access rights and passwords are handed over at the end of a project or a given work package, so the client is never dependent on a single contractor for future changes or for switching support providers.

Data security and compliance#

Documents processed by an AI system often contain personal, financial or commercially sensitive data, so security has to be settled before rollout, not after. That means defining who has access to which document types, how data is protected in transit and at rest, and how the system responds to an unauthorized access attempt. Requirements are stricter in the public sector and regulated industries, where data protection requirements (GDPR) also have to be met.

For document-processing projects, we separate development, test and production environments, and real personal data is never used in the test environment — only substitute test records. This means classification, extraction and validation can be tested thoroughly without exposing real customer or employee documents to unnecessary risk, while still checking the system works before it processes real documents.

For projects where security is a core requirement, within Epix and our specialist partner network we assemble a team with expertise in security architecture, identity and access management (IAM) and vulnerability assessment, so security is built into the solution from the start rather than added later. This matters in particular for documents from banking, insurance or the public sector, where access control is a legal obligation, not just good practice.

• access rights to each document type based on an employee's role
• how data is protected in transit and at rest
• separation of development, test and production environments
• a log of who processed, reviewed or changed a document
• a response procedure for unauthorized access attempts
• alignment with data protection requirements (GDPR)

Testing and quality assurance#

Before a document-processing solution goes into production, it has to go through testing that checks whether classification, extraction and validation work correctly on a realistic — but not real — set of documents. Testing includes preparing test scenarios for typical and edge-case documents, manual review of results, and automated testing that reruns on every system change to confirm the change hasn't broken existing functionality.

The scope of testing is set according to how critical the data being processed is. For documents affecting payments, contractual obligations or statutory deadlines, it makes sense to include independent QA, separate from the development team, reviewing results from the client's perspective rather than the contractor's. For less critical documents, a narrower set of test scenarios and regular monitoring of the correctly-processed share after rollout is enough.

Acceptance criteria are agreed before development starts, not at the end of the project, so the client knows in advance what it will judge production readiness against. That includes agreeing what share of correctly processed documents is acceptable and how documents the system cannot reliably process are handled.

• preparing test scenarios for typical and edge-case documents
• manual review of classification, extraction and validation results
• automated testing rerun on every system change
• testing of connections to the ERP, CRM or document system via APIs
• regression testing to confirm a change hasn't broken existing functionality
• acceptance testing against criteria agreed before go-live

Maintenance, support and response times after rollout#

After a document-processing solution goes live, new document types appear, form templates change, and occasionally errors surface that testing could not anticipate. Before a project closes, it has to be defined who is responsible for monitoring operation, fixing issues, applying technical and security updates and continuing development, and what rules govern how requests are handled. This is set out in a support agreement that defines request classes and how each is handled.

Requests after rollout are sorted into classes based on their business impact. An outage means the system or a key part is not working and gets the highest priority. A disruption means the system works but a specific function does not. A defect is a minor issue with no business impact. A request is a change or enhancement that needs to be scoped and scheduled. Response time for each class is agreed in the support contract based on how critical the system is to the client.

Which SLA class a company needs depends on how dependent day-to-day operations are on document processing working correctly. Where a delay means a missed statutory deadline or halted production, strict agreed response times for outages make sense. For less critical processes, basic support with defects handled in regular release cycles is enough.

• Class 1 – outage: the system or a key part is not working; handled with the highest priority
• Class 2 – disruption: the system works, a specific function does not; handled by agreed priority
• Class 3 – defect: a minor issue with no business impact; scheduled into the next release
• Class 4 – request: a change or enhancement; scope is assessed and a timeline agreed

How the collaboration with a contractor works#

A client can hand an AI document-processing project to a contractor in full, or bring the contractor in for a single work package — for example, only extraction, while classification and ERP entry are already handled internally. Which option makes sense depends on how many existing systems are affected by the decision and how much in-house knowledge of those systems the company already has. This needs to be clarified early, since it shapes how the project is broken into work packages.

On larger projects spanning several departments and systems, we appoint a project lead and define team responsibilities, deadlines for each work package, and how the contractor and client communicate and report to each other. This matters most when individual departments — procurement, finance and legal, for example — have different expectations of the same solution that need to be reconciled before development starts.

Within Epix and our specialist partner network, we assemble a team based on what a given project needs — from AI and data specialists, business analysts and integration architects to QA engineers responsible for testing before go-live. Epix has operated since 2020, working in Slovenia, Serbia and the United States, and together with our partner network we have delivered more than 950 projects across different fields, including projects involving AI-based data and document processing.

What determines project scope and price#

Prices for AI document-processing projects vary by scope, so we do not quote them without first reviewing requirements. Instead, every project starts by defining what the scope actually includes: how many document types need handling, how many existing systems the solution has to connect to, what the security requirements are, and how much data, if any, needs migrating from an existing, partly built system.

Before scoping, we typically propose a short analysis that breaks the whole project into work packages, so each one can be estimated and delivered separately — for example, classification on its own, ERP integration on its own, and validation rules on their own. This lets the client decide which package to run first and which to defer, rather than having to sign off the entire project at once.

Only once the project is broken down this way can the effort for each package, and the order to run them in, be estimated — without the client taking on the risk of scope shifting significantly during delivery for no clear reason.

• the scope of functionality and the number of user roles in the solution
• how many existing systems need connecting and what their APIs support
• whether this is a new system or taking over and upgrading an existing one
• the volume and condition of data that needs migrating
• security, audit-trail and compliance requirements
• the scope of testing and whether independent QA is needed
• the level of post-launch support and agreed response times