What document classification is: the first gate that splits a merged file into units of work

Document classification determines which form an arriving file is, splits it into separate documents when several have been merged into one, assigns a type to each piece, and hands them on to the processing that follows.

Why document classification is needed

One file is not one document.

Most discussions about document automation open on recognition accuracy. Open an actual intake queue, though, and a different problem sits in front of that one. A single file arriving by fax holds an application form, a copy of an ID, a bank passbook, and a certificate, stitched together in no particular order. Before reading any value, the operator opens the file and works out by eye where the application ends and the passbook copy begins. One financial institution measured between two and four minutes per case spent on that checking and sorting alone.

However accurate the recognition model, automation does not start without this step. Until you know which form you are looking at, there is nothing to decide what should be extracted. Classification is not an accessory to automation; it is the entrance.

What document classification actually is: how it differs from recognition

Recognition and classification across three axes

First, the target differs. Recognition works on the characters and tables inside a page. Classification works on the boundaries between pages and on the impression the page as a whole gives. Logos, form titles, table arrangement, and printed instructions — elements that are not values at all — become the basis for the decision.

Second, the objective differs. Recognition aims to transcribe the content accurately. Classification aims to decide how many documents this file contains and which type label belongs on each. Facing the same page, recognition answers what is written; classification answers what document this is.

Third, the metric differs. Recognition is measured on character or field accuracy. Classification is measured on whether the type judgment was correct, and real validations have produced 97 percent on one financial document set and 89.1 percent on a public-sector set. The granularity of the type scheme and the similarity between forms move this figure considerably.

The two are not alternatives. A wrong classification means extraction begins holding the wrong field list, so the more accurate the recognition, the more plausible the resulting error. Keeping the order is safer.

Five conditions for putting classification into production

Five conditions that hold in real operations

First, it has to find document boundaries by itself. Where several forms arrive merged into one PDF, splitting the file into pieces comes before typing them. Labelling page by page scatters multi-page documents into loose sheets, so the system also has to judge whether consecutive pages belong to the same document.

Second, the type scheme has to be designed on business criteria. One card issuer's automation organised an initial set of 46 document types and built a classification code scheme of 747 entries before moving to extraction. Too coarse a scheme groups different forms into one type and misaligns the extraction fields; too fine a scheme raises the difficulty of the judgment and lowers accuracy.

Third, forms that look alike have to be told apart. New enrolment and change-of-details applications share nearly the same layout and differ by a few characters in the title, and pairs like that are common in real operations. Judging on overall impression alone concentrates errors there, so the design has to include decisive cues such as the form title and document number.

Fourth, it has to handle revised forms. Government and financial forms are revised on a cycle. A structure that retrains the model on every new form accumulates operational burden indefinitely. Managing type definitions as data and versioning the changes lowers the cost of ownership.

Fifth, undecidable cases have to be pulled aside. Forcing every file into some type lets errors flow quietly downstream. Leaving low-confidence cases unclassified and routing them for review is what preserves trust in the automation as a whole.

How classification is applied in practice

Design backwards from the intake channel

Classification design starts at the intake path, not at the model. Whether documents arrive by electronic fax, are scanned at a branch, or come in as mobile photographs changes the condition of the files entirely.

The operational flow runs: electronic fax intake, merged PDF splitting, document classification, field extraction, post-processing, validation, storage in the document management system, integration with an automation tool, registration in core systems. Classification is the third link, and a case mistyped there carries its error through every stage that follows. Preparing an operating environment where classification results can be checked and corrected on screen is therefore worth doing alongside.

Keep classification and extraction separate

Combining classification and extraction into one process means rebuilding everything each time a form is added. Split into two stages, the classification scheme is updated by editing type definitions and extraction by editing the per-type field schema.

On method, a model that interprets the page's visual information and context together holds the advantage. Reading a title at a fixed position by rule fails immediately when the scan is skewed or the top is cropped. Real intake documents include cases where a black band from a page folded during scanning has swallowed the form title.

Manage the classification code scheme as a document

The type scheme should not be buried inside the model; it needs to be a document that operators can read and edit. Once types reach the scale of several hundred, which code refers to which form becomes business knowledge in its own right.

Record for each code the form name, the issuing body, a representative sample file, and the list of fields to extract from that type. Where similar forms exist, state explicitly what distinguishes them. With that document in place, the scheme survives staff changes and there is a basis for deciding whether a newly arrived form belongs to an existing type or needs a new one.

Classification in the Korean environment

Fax remains part of the intake path in Korean financial and public operations. Documents retransmitted several times stack different date formats on the same line and lose enough resolution that the strokes of a form title smear. Judging a type under those conditions requires synthesising cues from the whole document rather than reading one heading.

Format is a condition as well. Korean word processor files, scanned PDFs, and image files coexist within a single workflow, each needing different preprocessing. The multi-level tables and circled line numbers peculiar to government forms act as both cue and obstacle in the type judgment.

Frequently asked questions