IDP: When OCR Isn't Enough

"We scan the incoming mail and the rest runs automatically." The promise is old and in most mid-size companies still not delivered. The reason is rarely the scanner and almost never text recognition. It sits in the gap between reading letters and understanding documents.

What OCR can do - and where it ends

Tesseract, ABBYY or the OCR engine in your multifunction printer reliably deliver what they promise: text from an image or PDF. On a cleanly scanned standard letter this works beautifully.

Daily operations look different:

• Mixed layouts - invoice, delivery note and handwritten note on a single page.
• Tables without lines - humans see columns, OCR returns a string of letters.
• Form variants - the same form from ten suppliers, each with their own layout.
• Difficult sources - fax printouts, skewed scans, ballpoint pen pressed through the page.
• Multilingual content - German template, English stamps, Italian supplier name.

OCR returns text in all these cases. What's missing: nobody knows what text means what.

What Intelligent Document Processing adds

IDP builds on top of OCR and adds three layers:

1. Classification. What document type is this - invoice, dunning letter, contract, delivery note? With good models, a few examples per type are enough.
2. Extraction. Which information sits where - invoice number, recipient, IBAN, due date? Modern systems combine layout models (LayoutLMv3, Donut) with rule-based validation here.
3. Validation. Plausibility against master data, calculation check on invoices, reconciliation with ERP records. Without this layer every extraction is only a suggestion.

Only the combination of all three layers separates "text recognized" from "case closed".

Where IDP really delivers in mid-size companies

Three fields where the effort almost always pays off:

• Incoming invoices. Classification, extraction of mandatory fields, pre-coding, reconciliation with orders. Saves measurable minutes per document and reduces booking errors.
• Mail intake in law firms or medical practices. Assignment to case files or patient records, clean documentation of arrival date, automatic follow-ups.
• Supplier and customer forms. Master data maintenance without a typing layer, with a clean audit trail.

In all three cases IDP doesn't replace clerical staff, it removes the mechanical preliminary work that costs hours today.

Four points that decide the outcome

Four points that decide every IDP project:

1. Real documents beat any demo dataset. Models tested on sample invoices fall apart on the first real fax copy. The first 200 production documents belong in evaluation.
2. Local models have grown up. Layout models like Donut or LayoutLMv3 run on a GPU in the server room and deliver results on par with cloud services for German standard documents - without client mail leaving the building.
3. Validation is mandatory, not optional. An extracted IBAN without a checksum is a risk. An invoice amount without a calculation check against line totals is one too.
4. Humans in the loop remain valuable. The last 5 % of edge cases cost more in full automation than they save. A clear handover point to clerical staff is part of good design.

When to start

Rule of thumb from practice: at around 100 comparable documents per day or a clearly recurring incoming stream (mail intake at a law firm, invoice flow in purchasing, application forms in administration), an IDP setup pays off noticeably.

A pilot with two or three document types, real documents and honest success metrics shows within weeks whether the leverage is there. Only then does it make sense to discuss scaling, ERP or DMS integration and operating mode.

Conclusion

OCR is a component, not a process. Anyone who wants to automate incoming documents needs classification, extraction and validation as a connected system - evaluated with real documents and cleanly connected to ERP or DMS. The effort is manageable, the daily leverage high.