Jede Kanzlei, jede Buchhaltung, jeder Versicherungsmakler hat denselben Engpass: ein Mensch öffnet ein PDF, liest es, tippt zwölf Felder in ein anderes System ab, und legt es ab. Pro Dokument zwei bis zwanzig Minuten. Bei tausend Dokumenten im Monat sind das mehrere Vollzeitstellen, die nichts anderes tun, als Daten von einem Format ins nächste zu schieben.
Die naheliegende Lösung — “lass das doch eine KI machen” — funktioniert in der Praxis fast nie beim ersten Versuch. Nicht weil die Technik nicht reif ist. Sondern weil 95% Texterkennungsgenauigkeit für reale Geschäftsprozesse zu wenig ist, und weil die meisten Pipelines an drei Stellen brechen, die in den Tutorials nicht vorkommen.
Was hier folgt, ist die Architektur, die wir in einer aktiven Pipeline für einen Kunden einsetzen. Bearbeitungszeit pro Anfrage ist von 20 Minuten auf unter eine Minute gefallen. 94% der Dokumente laufen ohne menschlichen Eingriff durch.
Klassisches OCR — Tesseract, ABBYY, AWS Textract — extrahiert Pixel zu Text. Punkt. Was dabei rauskommt, ist eine lange Zeichenkette, in der “Rechnungsnummer 2024-08-1573” und “Lieferdatum 15.08.2024” und “23 % USt” als zusammenhängender Wortbrei stehen. Strukturiertes Wissen entsteht erst, wenn jemand — Mensch oder LLM — versteht, welche Zahl was bedeutet.
Drei Probleme machen reines OCR im Geschäftskontext unbrauchbar:
Layout-Verlust. Eine Rechnung ist tabellarisch organisiert. Tesseract liest aber Zeile für Zeile von links nach rechts. Wenn links “Rechnungsbetrag” steht und rechts “1.247,80 €” — was Tesseract daraus macht, hängt vom Spaltenabstand und der Schriftgröße ab. Manchmal bekommst du “Rechnungsbetrag 1.247,80 €”, manchmal die Spalten getrennt in zwei Absätzen.
Zeichenfehler bei deutschen Belegen. “ß” wird zu “B”, Umlaute zu Doppelbuchstaben, das österreichische Komma als Dezimaltrenner zum Punkt. “1.247,80” wird zu “1247.80” oder “1,247.80”. Ein Buchhaltungssystem, das auf strikte Formate angewiesen ist, verschluckt sich daran.
Keine Semantik. OCR weiß nicht, dass “UID ATU 12345678” eine Umsatzsteuer-Identifikationsnummer ist. Es weiß nicht, dass “20.05.2024” das Leistungsdatum ist und “31.05.2024” das Zahlungsziel. Diese Information liegt nicht im Text, sondern im Kontext — und Kontext versteht ein LLM, kein OCR-Engine.
Die produktiv eingesetzten Architekturen lassen sich auf zwei Muster reduzieren.
Ansatz A: Tesseract + LLM-Nachbearbeitung. Tesseract extrahiert den Rohtext, ein LLM (GPT-4o-mini, Claude Haiku oder Sonnet) bekommt diesen Text plus einen strukturierten Prompt: “Extrahiere folgende Felder im JSON-Format.” Vorteil: günstig (Tesseract ist kostenlos, LLM-Calls auf 2.000 Token kosten Cent-Bruchteile). Nachteil: alle Layout-Informationen sind verloren. Tabellen, Mehrspalten-Dokumente, handschriftliche Notizen funktionieren schlecht.
Ansatz B: GPT-4 Vision oder Claude Vision direkt. Das Bild oder PDF wandert ungefiltert ins Multimodal-Modell. Das Modell “sieht” Layout, Tabellenstruktur, Logos, Stempel. Vorteil: deutlich höhere Genauigkeit bei komplexen Belegen, weil das Modell semantischen und visuellen Kontext zusammen verarbeitet. Nachteil: 5–10× teurer pro Dokument, langsamer, und das Modell halluziniert gelegentlich Werte, die so im Bild nicht stehen.
In der Praxis kombinieren wir beides. Standard-Belege (digitale PDFs, klare Struktur) gehen über Ansatz A. Schwierige Fälle — gescannte Verträge, handschriftliche Anmerkungen, komplexe Tabellen — werden über einen Switch-Node in Ansatz B umgeleitet. Die Heuristik dafür ist trivial: liefert OCR weniger als 200 Zeichen verwertbaren Text, oder erkennt ein Pre-Check Tabellenstrukturen, geht das Dokument an Vision.
Bei einem unserer Kunden aus Wien R lief der Prozess vor der Automatisierung so: Kunden schickten Dokumente per E-Mail (Vertrag, Rechnung, Korrespondenz). Eine Sekretärin öffnete die Mail, lud die Anhänge runter, identifizierte den Dokumententyp, extrahierte relevante Daten und legte den Vorgang im System an. Pro Anfrage 15 bis 25 Minuten.
Die heutige Pipeline:
20 Minuten manuelle Arbeit werden zu unter einer Minute Durchlaufzeit. Die Sekretärin schaut nur noch auf die Review-Queue und arbeitet dort die ~6% der Fälle ab, in denen die Validierung gescheitert ist oder das Modell unsicher war.
Was ich in jedem Tutorial vermisse: ehrliche Aussagen darüber, wo solche Workflows in der Realität versagen. Drei Bruchstellen, die wir alle schmerzhaft gelernt haben.
Kunden schicken nicht das saubere Original-PDF. Sie schicken ein Handy-Foto vom abfotografierten Ausdruck einer eingescannten Kopie. Verzerrt, schief, mit halbem Schatten. OCR liefert Müll, Vision liefert Halluzinationen. Die produktive Lösung: ein vorgeschalteter Image-Preprocessing-Schritt, der Schiefstellung korrigiert, Kontrast normalisiert und einen Lesbarkeits-Score berechnet. Dokumente unter einem Schwellenwert gehen direkt zurück an den Mandanten mit einer höflichen Bitte um besseren Scan. Klingt banal, war aber der einzelne größte Hebel für die Straight-Through-Rate.
Anthropic, OpenAI, Google — alle drei haben pro Quartal ein bis zwei Stunden Outage. Wenn dein Workflow keinen Fallback hat, stapeln sich in dieser Zeit die Dokumente, der Outlook-Trigger läuft trocken, und am Ende steht der gesamte Posteingang still. Die Konsequenz: Jeder LLM-Call hat einen Try/Catch-Wrapper, eine Retry-Logik mit exponential backoff, und einen Fallback auf ein zweites Modell von einem anderen Anbieter. Wenn Claude nicht erreichbar ist, übernimmt GPT-4o. Bei einer Mandantenanfrage darf nichts verloren gehen.
Das tückischste Problem. LLMs füllen Felder aus, auch wenn die Information im Dokument fehlt. Du fragst nach der UID, das Dokument hat keine, das Modell schreibt eine plausibel aussehende Phantasie-UID hin. Wir sind drauf gestoßen, als ein Prozessbescheid mit der falschen Aktenzahl im System landete — die echte stand auf Seite 3, das Modell hatte aber die Aktenzahl aus dem Briefkopf der Korrespondenz extrahiert.
Die Gegenmaßnahme: jeder extrahierte Wert wird mit einer expliziten Quellenangabe (“Diese Information steht auf Seite X, Zeile Y”) angefordert, und ein zweiter Validierungs-Pass prüft, ob diese Stelle im OCR-Rohtext tatsächlich existiert. Findet sich der Wert nicht, geht das Feld auf null und das Dokument in die Review-Queue. Diese Halluzinations-Prüfung kostet zusätzliche Tokens, aber sie ist der Unterschied zwischen einer Demo, die in 95% der Fälle funktioniert, und einem Produktivsystem, dem ein Anwalt vertrauen kann.
Pro Dokument bei dem Wiener Kunden: rund 2.500 Input-Token (Dokument + Prompt), 400 Output-Token. Bei Claude Sonnet sind das etwa 1,2 Cent pro Anfrage. Bei 800 Anfragen pro Monat etwa 9,60 Euro API-Kosten. Die Sekretärin, deren Zeit damit auf Review-Arbeit reduziert wurde, hatte vorher rund 200 Stunden im Monat für reine Datenextraktion gebraucht.
Die Rechnung wird nur unangenehm, wenn man Vision-Modelle für jedes Dokument einsetzt. GPT-4o Vision liegt bei rund 15 Cent pro Dokument — bei 800 Anfragen plötzlich 120 Euro. Deshalb das Routing: Standard über günstig, Edge-Cases über teurer.
Wenn Sie OCR-Automatisierung im eigenen Unternehmen evaluieren, ist die wichtigste Frage nicht “welches Modell” oder “welche Plattform”. Sie ist: wie schlecht sind die Eingangsdokumente?
Wenn Sie hauptsächlich digitale PDFs aus Buchhaltungssystemen bekommen — sevdesk, lexoffice, BMD, FreeFinance — dann ist Ansatz A (Tesseract + LLM) in einer Woche umsetzbar und liefert >95% Accuracy. Wenn Mandanten oder Kunden Ihnen abfotografierte Belege schicken, brauchen Sie Vision-Modelle, Image-Preprocessing und eine ehrliche Review-Queue.
Und wenn jemand Ihnen verspricht, dass ein KI-System “alle” Dokumente “vollautomatisch” verarbeitet — dann hat dieses System entweder keine Halluzinations-Prüfung, oder es ist schlicht noch nicht im Produktivbetrieb gewesen. 94% Straight-Through ist nach unserer Erfahrung ein realistisches oberes Ende. Die letzten 6% sind kein Bug, sondern eine Designentscheidung: lieber ein Mensch klärt zwei zweifelhafte Beträge, als dass die Pipeline 800 Mal pro Monat erfundene UIDs ins Steuersystem schreibt.
Kostenlose Erstberatung · Antwort innerhalb 24 Std · Einstieg ab €1.000
Jetzt 60-Sekunden-Analyse startenKostenlos · unverbindlich · in 60 Sekunden Klarheit zu Ihrem Automatisierungs-Potenzial
Drei Pakete — vom schnellen Einstieg bis zur komplexen Integration
Alle Preise netto. Endgültige Konditionen nach individueller Analyse.
Kostenlose Erstberatung · Antwort innerhalb 24 Std · Einstieg ab €1.000
Jetzt 60-Sekunden-Analyse startenKostenlos · unverbindlich · in 60 Sekunden Klarheit zu Ihrem Automatisierungs-Potenzial
