See end-to-end automated process

Reminder note on problem statement

The issue relates to the reality that every bank has its specific documentation. Each receives an overwhelming amount of applications every day.

For the sample use case, the overall workflow is about 3,500 documents per day. The bank is assumed to have 278 employees who process claims daily.

However, it is not the number of papers that makes this work so difficult. The amount is only the first problem. All other issues are even more dramatic and demanding:

• Too many types of documents are in circulation—from various partners, in different languages, and on different schedules.

• Processing is usually time-consuming and prone to errors.

In the sample use case, the bank has five problems listed in the table below:

Variety	There are 11 document types in total: 8 document types are processed in daily review and 3 more document types are processed monthly.
Priorities	Of these documents, types #1, 5 and 6 make up 90% of the workflow.
Connections	Document types 1 and 8 are interconnected—it's necessary to validate the data extracted from document 8 against document 1.
Different vendors	There are 15 top vendors supplying invoices monthly.
Languages	Invoices come from 10 different countries in 5 languages (English, German, Japanese, Chinese, Spanish).

All these problems mean that a complex Business Process (BP) is required. Let's consider the case in terms of possibilities the Work.AI platform offers.

End-to-end automated solution

The collaboration between the data analyst (DA) and subject-matter expert (SME) helps streamline the document processing. Here is how the end-to-end automated solution can look.

Stage	Description	Problem solved
Input storage (multiple types of collaterals)	In the first step, there is a scheduled procedure that picks up new files in a shared folder or any other storage, sorted by the arrival date, document status, or anything else.
Labeling	Documents are passed over a dedicated BP for conversion from PDF into HTML or XML. Electronic documents go directly to the preprocessing step where their language is defined. All other document types (emails and attachments) go to the end of the workflow since they are handled in another BP.	Variety: after labeling and extracting all information from documents, only unformatted text is left.
Classification (language)	After OCR, documents are routed to the classification step: According to the current workflow, documents can come in English, Spanish, and Japanese. Three workflows are created—one for each language since separate models are required.	Language: the machine can process various languages simultaneously without compromising the quality.
Preprocessing (type definition)	Next, define the document type by its name: In Spanish, 5 document types are received. In English, 2 types. Each type is processed by a separate model. In Japanese, only invoices are received so that's one model.	Variety: this helps to sort documents by type.
ML 1 / 2 / 3 language top vendors	For model training, if possible, top vendors are defined per document type (or if there is a variety in layouts or something else). A dataset is collected per each model, and models are trained separately in the development phase. In production, the trained models extract values from incoming documents.	Different vendors: helps to determine the relationships between top vendors and document specifics.
Post processing	Raw extracted data may need conversion before being recorded into the database. For example, a value, which is a text string in a document, is stored as an alphanumeric code. Records that meet the requirements, for example, with all fields extracted, skip manual review and are pushed directly to the Data Store. That's straight-through processing (STP).	Variety: helps to unify values.
Manual review	Records that do not go to STP are reviewed before being pushed into the database. That won't necessarily imply a review of the entire document. Often, it's a small part of it that the model fails to process.	This part does not solve any particular problem but facilitates the resolution of every problem type above.
Push to Data Store	The decision is pushed through the system to the end user.