OCR + KI: Dokumente automatisiert auslesen — und warum 95 % Genauigkeit nicht reichen

Jede Kanzlei, jede Buchhaltung, jeder Versicherungsmakler kennt denselben Engpass: Ein Mensch öffnet ein PDF, liest es, tippt ein Dutzend Felder in ein anderes System ab und legt es ab. Bei vielen Dokumenten im Monat bindet das spürbar Arbeitszeit, die nichts anderes tut, als Daten von einem Format ins nächste zu schieben.

Die naheliegende Lösung — „lass das doch eine KI machen“ — funktioniert selten beim ersten Versuch. Nicht, weil die Technik nicht reif wäre, sondern weil eine Texterkennung, die nur in den meisten Fällen stimmt, für echte Geschäftsprozesse zu wenig ist, und weil viele Pipelines an drei Stellen brechen, die in Tutorials kaum vorkommen.

Was hier folgt, ist eine bewährte Architektur für solche Pipelines. Wie stark sich die Bearbeitungszeit verkürzt und welcher Anteil ohne menschlichen Eingriff durchläuft, hängt vor allem von der Qualität der Eingangsdokumente ab.

OCR allein reicht nicht

Klassisches OCR wie Tesseract extrahiert in erster Linie Pixel zu Text. Was dabei herauskommt, ist eine lange Zeichenkette, in der „Rechnungsnummer 2024-08-1573“, „Lieferdatum 15.08.2024“ und „20 % USt“ als zusammenhängender Wortbrei stehen. Spezialisierte Dienste wie Amazon Textract oder ABBYY erkennen zusätzlich Tabellen und Formularfelder; strukturiertes Wissen entsteht aber erst, wenn jemand — Mensch oder Sprachmodell — versteht, welche Zahl was bedeutet.

Drei Probleme machen reines OCR im Geschäftskontext schwierig:

Layout-Verlust. Eine Rechnung ist tabellarisch organisiert. Tesseract liest aber Zeile für Zeile von links nach rechts. Steht links „Rechnungsbetrag“ und rechts „1.247,80 €“, hängt das Ergebnis vom Spaltenabstand und der Schriftgröße ab: Manchmal steht beides zusammen, manchmal landen die Spalten in getrennten Absätzen.

Zeichenfehler bei deutschsprachigen Belegen. „ß“ wird zu „B“, Umlaute zu Doppelbuchstaben, das 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, und nicht, dass „20.05.2024“ das Leistungsdatum und „31.05.2024“ das Zahlungsziel ist. Diese Information liegt nicht im Text, sondern im Kontext — und Kontext versteht ein Sprachmodell, keine OCR-Engine.

Zwei Ansätze, die heute funktionieren

Produktiv eingesetzte Architekturen lassen sich auf zwei Muster reduzieren.

Ansatz A: Texterkennung + Sprachmodell. Tesseract extrahiert den Rohtext, ein kleines, günstiges Sprachmodell bekommt diesen Text plus einen strukturierten Prompt: „Extrahiere folgende Felder im JSON-Format.“ Vorteil: günstig, Tesseract ist kostenlos, und ein kurzer Aufruf eines kleinen Modells kostet Bruchteile eines Cents. Nachteil: Layout-Informationen gehen verloren. Tabellen, mehrspaltige Dokumente und handschriftliche Notizen funktionieren schlecht.

Ansatz B: Vision-Modell direkt. Das Bild oder PDF geht direkt an ein Vision-fähiges Modell. Das Modell „sieht“ Layout, Tabellenstruktur, Logos und Stempel. Vorteil: deutlich höhere Genauigkeit bei komplexen Belegen, weil semantischer und visueller Kontext zusammen verarbeitet werden. Nachteil: teurer pro Dokument, langsamer, und das Modell erfindet gelegentlich Werte, die so im Bild nicht stehen.

Sinnvoll ist die Kombination. Standardbelege (digitale PDFs, klare Struktur) gehen über Ansatz A. Schwierige Fälle — gescannte Verträge, handschriftliche Anmerkungen, komplexe Tabellen — werden über einen Switch-Node zu Ansatz B umgeleitet. Die Regel dafür kann einfach sein: Liefert OCR sehr wenig verwertbaren Text oder erkennt eine Vorprüfung Tabellenstrukturen, geht das Dokument an das Vision-Modell.

Beispielhafter Workflow: Mandantenanfrage in einer Kanzlei

In einer typischen Kanzlei läuft der Prozess ohne Automatisierung so: Mandantinnen und Mandanten schicken Dokumente per E-Mail (Vertrag, Rechnung, Korrespondenz). Jemand im Sekretariat öffnet die Mail, speichert die Anhänge, erkennt den Dokumenttyp, überträgt die relevanten Daten und legt den Vorgang im System an.

Eine mögliche Pipeline:

1. Eingang. Ein Outlook-Trigger in n8n erkennt eingehende Mails im dafür vorgesehenen Postfach. Anhänge werden abgelegt, der E-Mail-Text bleibt als Kontext erhalten.
2. Klassifikation. Ein erster Aufruf eines kleinen Modells bekommt das Dokument und die Anweisung: „Welcher Dokumenttyp? Vertrag, Rechnung, Schriftverkehr, Kontoauszug, sonstiges.“ Antwort als JSON, Temperatur 0.
3. Routing. Je nach Typ wird ein anderer Extraktions-Prompt aktiviert. Ein Vertrag braucht andere Felder als eine Rechnung.
4. Extraktion. Ein leistungsfähigeres Modell bekommt das Dokument und den typspezifischen Prompt mit klaren Feldvorgaben. Ergebnis: striktes JSON mit allen Feldern, fehlende Werte ausdrücklich als null.
5. Validierung. Plausibilitätsprüfungen: IBAN-Prüfziffer, UID-Format, Datumsformat, Beträge in realistischer Größenordnung. Schlägt eine Prüfung fehl, geht das Dokument in eine Review-Queue.
6. Ablage. Geprüfte Daten landen im CRM bzw. in der Kanzleisoftware, das Originaldokument im DMS beim richtigen Akt.

Das Sekretariat arbeitet dann vor allem die Review-Queue ab: die Fälle, in denen die Validierung gescheitert ist oder das Modell unsicher war.

Datenschutz und Verschwiegenheit. Gerade in Kanzleien gehen hier vertrauliche Mandatsdaten durch die Pipeline. Dazu gehören ein Auftragsverarbeitungsvertrag mit jedem eingesetzten Dienst, wo möglich Verarbeitung in der EU bzw. Zusagen ohne Datenspeicherung beim Modellanbieter, Datenminimierung (nur die nötigen Seiten und Felder) und die Prüfung, ob der Einsatz mit der Verschwiegenheitspflicht nach § 9 RAO vereinbar ist. Wo das nicht gelingt, ist ein lokal betriebenes Modell eine Alternative.

Die drei Stellen, an denen Pipelines reißen

Was in vielen Tutorials fehlt, sind ehrliche Aussagen darüber, wo solche Workflows in der Realität versagen. Drei Bruchstellen treten in der Praxis immer wieder auf.

1. Schlechte Scans

Nicht jedes Dokument kommt als sauberes Original-PDF. Häufig ist es ein Handyfoto vom Ausdruck einer eingescannten Kopie: verzerrt, schief, mit halbem Schatten. OCR liefert dann unbrauchbaren Text, ein Vision-Modell erfindet Werte. Abhilfe schafft ein vorgeschalteter Bildaufbereitungs-Schritt, der Schiefstellung korrigiert, Kontrast normalisiert und einen Lesbarkeitswert berechnet. Dokumente unter einem Schwellenwert gehen mit einer höflichen Bitte um einen besseren Scan zurück. Das klingt banal, ist aber oft der größte Hebel für den Anteil der Dokumente, die ohne Nacharbeit durchlaufen.

2. API-Ausfälle

Auch große KI-Anbieter haben immer wieder Ausfälle. Hat der Workflow keinen Plan B, stapeln sich in dieser Zeit die Dokumente, und im schlimmsten Fall steht der gesamte Posteingang still. Deshalb bekommt jeder Modellaufruf eine Fehlerbehandlung, eine Wiederholungslogik mit wachsenden Wartezeiten und einen Fallback auf ein Modell eines anderen Anbieters. Bei einer Mandantenanfrage darf nichts verloren gehen.

3. Erfundene Pflichtfelder

Das tückischste Problem: Sprachmodelle füllen Felder aus, auch wenn die Information im Dokument fehlt. Fragt man nach der UID und das Dokument hat keine, schreibt das Modell unter Umständen eine plausibel aussehende, aber erfundene UID hin. Ein typisches Beispiel: Ein Bescheid landet mit der falschen Aktenzahl im System, weil das Modell die Zahl aus dem Briefkopf der Begleitkorrespondenz übernommen hat statt der richtigen auf Seite 3.

Die Gegenmaßnahme: Jeder extrahierte Wert wird mit einer ausdrücklichen Quellenangabe („steht auf Seite X, Zeile Y“) angefordert, und ein zweiter Prüfdurchgang kontrolliert, ob diese Stelle im OCR-Rohtext tatsächlich existiert. Findet sich der Wert nicht, wird das Feld auf null gesetzt und das Dokument in die Review-Queue gelegt. Diese Prüfung kostet zusätzliche Tokens, ist aber der Unterschied zwischen einer Demo und einem Produktivsystem, dem man vertrauen kann.

Was das kostet

Die laufenden Kosten hängen vor allem vom Modell und vom Umfang der Dokumente ab. Bei Ansatz A mit einem kleinen Modell liegen sie meist bei Bruchteilen eines Cents bis wenigen Cent pro Dokument. Vision-Verarbeitung kostet pro Dokument in der Regel mehr als reine Textverarbeitung, vor allem bei mehrseitigen Scans. Deshalb das Routing: Standardfälle über den günstigen Weg, schwierige Fälle über das Vision-Modell.

Teurer als die Modellaufrufe ist fast immer die Arbeitszeit, die heute in der manuellen Erfassung steckt. Wie viel davon sich einsparen lässt, zeigt sich erst mit den eigenen Dokumenten.

Wo Sie anfangen sollten

Wenn Sie OCR-Automatisierung im eigenen Unternehmen bewerten, ist die wichtigste Frage nicht „welches Modell“ oder „welche Plattform“, sondern: Wie gut oder schlecht sind die Eingangsdokumente?

Kommen hauptsächlich digitale PDFs aus Buchhaltungssystemen wie sevdesk, Lexware Office, BMD oder FreeFinance, ist Ansatz A vergleichsweise schnell umsetzbar und liefert meist hohe Erkennungsraten. Schicken Ihnen Kundinnen und Kunden abfotografierte Belege, brauchen Sie Vision-Modelle, Bildaufbereitung und eine ehrliche Review-Queue.

Und wenn Ihnen jemand verspricht, dass ein KI-System „alle“ Dokumente „vollautomatisch“ verarbeitet, hat dieses System entweder keine Prüfung auf erfundene Werte, oder es hat den Produktivbetrieb noch nicht erlebt. Eine vollständige Dunkelverarbeitung ist unrealistisch; ein Rest an Fällen gehört bewusst in eine Review-Queue. Das ist kein Fehler, sondern eine Designentscheidung: Lieber klärt ein Mensch zwei zweifelhafte Beträge, als dass die Pipeline erfundene UIDs ins Buchhaltungssystem schreibt.

Sie überlegen, wie ein solcher Ablauf in Ihrem Betrieb aussehen könnte? Kontaktieren Sie Goma-IT — wir sehen uns Ihren Anwendungsfall an und sagen Ihnen ehrlich, ob sich eine Umsetzung lohnt.