Document Classification Before OCR: How to Route Files to the Right Extraction Workflow

Overview

Sending every file through the same OCR workflow is simple, but it often produces inconsistent results. An invoice may need line-item and tax extraction, while a receipt needs merchant, date, total, and payment fields. A passport requires identity-field handling and different validation rules; a contract may need searchable text rather than a fixed set of fields.

Document classification solves this routing problem. The classifier assigns an incoming file to a document type, such as invoice, receipt, form, contract, identity document, or unknown. A routing layer then selects the correct OCR API, extraction schema, validation rules, storage destination, and human-review path.

Classification can use several signals:

• Source and metadata: upload channel, sender, mailbox, folder, creation date, file type, and page count.
• Filename patterns: supplier names, document numbers, dates, or terms such as “invoice” and “receipt.”
• Visual and text features: page layout, logos, headings, tables, keywords, barcodes, and repeated field positions.
• Rules or machine learning: deterministic conditions for predictable sources and AI classification for variable layouts.
• Extraction feedback: whether the selected workflow finds the fields and structural patterns expected for that class.

A practical system does not treat classification as a one-time prediction. It records the predicted class, confidence, routing decision, extraction result, and any correction made by a reviewer. That audit trail helps teams identify new document types and improve routing over time.

For implementation context, see the guidance on building an OCR API pipeline for scanned PDFs and images and the OCR API integration guide for reliable error handling.

Checklist by scenario

Invoices

• Look for invoice labels, supplier details, billing information, purchase-order references, payment terms, tax identifiers, and line-item tables.
• Route to an invoice OCR or document extraction schema that supports header fields, totals, tax, currency, and line items.
• Check that subtotal, tax, discounts, and total have the expected relationships before releasing the data to accounting systems.
• Send low-confidence totals, unreadable supplier details, and unusual multi-page layouts to review rather than forcing a match.

Receipts

• Identify short-format documents with merchant information, transaction date, purchased items, payment details, and a final total.
• Use a receipt-specific workflow because receipts often contain skew, shadows, narrow columns, faded print, and photographs taken at an angle.
• Validate the total and date, then apply receipt-specific rules for missing tax, tips, refunds, or multiple totals.
• Keep receipts separate from invoices even when both contain a merchant name and total. Their fields and review rules are usually different.

The article Receipt OCR Data Validation provides a useful companion checklist for field validation and human review.

Forms and applications

• Detect recurring form titles, known question labels, checkboxes, signature areas, and fixed field positions.
• Route recognized form versions to version-specific schemas when field locations or question wording change.
• Distinguish blank forms from completed forms. A blank template may need archiving or template matching rather than value extraction.
• Flag pages with handwritten answers, crossed-out values, or missing pages for a workflow that can handle those conditions.

Contracts and correspondence

• Classify these documents primarily by purpose, title, sender, recipient, and page structure rather than by isolated keywords.
• Route them to a general document text extraction workflow when the goal is searchable text, indexing, or review.
• Preserve page order and, where required, create a searchable PDF instead of reducing the document to unstructured text.
• Use a separate review queue for documents containing attachments, exhibits, schedules, or mixed document types.

For the output side of this workflow, review how to create searchable PDFs with OCR.

Identity documents

• Use visual indicators such as document title, portrait placement, machine-readable zones, country or issuing-authority patterns, and security-layout cues.
• Route passports, identity cards, and other identity documents to an identity-document workflow with the appropriate field schema and validation steps.
• Do not treat a failed identity-document classification as an ordinary OCR failure. Send uncertain cases to a restricted review path and avoid exposing extracted personal data in general logs.
• Validate document type and field presence before using the result in an onboarding or verification process.

See the ID and passport OCR API integration guide for a more focused treatment of fields, validation, and data handling considerations.

Unknown or mixed batches

• Assign an unknown class when evidence is insufficient. Do not default every uncertain file to the most common category.
• Split mixed batches by page or document boundary when the intake format combines several documents in one PDF.
• Preserve the original file and record why classification failed, such as low image quality, unsupported language, missing pages, or an unrecognized template.
• Use a fallback workflow for general OCR and searchable output only when it is safe for the use case.

What to double-check

Decision tree for routing

1. Is the file readable? Check whether it is corrupted, password-protected, empty, or too low quality to process. Quarantine technical failures before classification.
2. Can the source be trusted? Apply known sender, mailbox, folder, or upload-channel rules, but treat them as signals rather than proof.
3. Does the document match a known type? Combine metadata, filename, visual layout, and extracted text instead of relying on one keyword.
4. Is confidence above the routing threshold? Send high-confidence files to automated extraction and uncertain files to review or a safer general workflow.
5. Did extraction confirm the class? Check required fields and structural expectations. A predicted invoice with no supplier, total, or line-item evidence may be misclassified.
6. Is the output safe to release? Apply validation, duplicate checks, permissions, and approval requirements before writing data to a business system.

Routing matrix

Filename and metadata rules

Use filenames and metadata as early routing hints, not as authoritative classification. A practical rule set can normalize case, remove punctuation, identify dates, and match controlled terms such as inv, invoice, receipt, or passport. Record the matched rule and its source so an operator can explain why a file was routed.

Prefer stable metadata over user-entered filenames when available. For example, a dedicated invoice mailbox may be a useful prior, while a filename typed by an end user may contain a spelling error. Keep rules narrow enough to avoid routing unrelated files based on a common word.

Confidence and fallback handling

Set thresholds according to the cost of an error. A low-risk archive may tolerate more automatic general OCR. A workflow that posts accounting entries or processes identity data should use stricter thresholds and stronger field validation. Define at least three outcomes: automatic routing, review required, and technical failure.

Log the class, confidence, selected workflow, extraction status, validation errors, and reviewer correction. Then use those records to test classification on representative documents, as described in this OCR accuracy testing framework.

Common mistakes

• Using one OCR schema for every file: General text extraction does not replace field-specific workflows for invoices, receipts, or identity documents.
• Classifying from a single keyword: “Total,” “date,” and “name” appear across many document types. Combine multiple signals.
• Ignoring page boundaries: A multi-page PDF may contain several documents or an attachment that requires separate handling.
• Routing every failure to a default class: This hides classification problems and can create incorrect records. Use an explicit unknown state.
• Confusing OCR confidence with classification confidence: Text may be read clearly even when the document type is wrong, and vice versa.
• Skipping post-extraction checks: Required fields, arithmetic relationships, dates, and document-specific patterns should confirm the route.
• Failing to preserve the original: Keep the source file and processing metadata so results can be reproduced or corrected.
• Overlooking operational changes: New suppliers, form versions, languages, scanners, and upload channels can change the document mix.

When comparing an OCR API or document AI service, evaluate classification, extraction, fallback behavior, integration effort, and observability together. Accuracy alone does not describe whether a workflow is reliable in production. The OCR API comparison checklist can help organize that review.

When to revisit

Review document classification before seasonal planning cycles, when workflows or tools change, and whenever misrouted files begin to increase. A useful recurring checklist is:

1. Sample recently processed files from every document class, including automatic successes and manual reviews.
2. Measure unknown, misclassified, technically failed, and manually corrected documents separately.
3. Check whether new suppliers, countries, languages, templates, scanners, or upload channels have appeared.
4. Review confidence thresholds against the business impact of false routes and missed automation opportunities.
5. Retest fallback workflows, page splitting, duplicate handling, and permissions after API or OCR software changes.
6. Update filename rules, classification examples, schemas, and routing documentation only after testing them on representative files.

Start with a small labeled sample, document the expected route for each file, and run the sample through the complete intake-to-release process. This makes it easier to determine whether a problem belongs to file quality, classification, OCR, field extraction, validation, or downstream integration. Repeating that exercise when inputs or tools change keeps OCR workflow automation dependable without requiring every document to follow the same path.