Intelligent Document Processing: Vom Dokument zum verlässlichen Datensatz

Intelligent Document Processing, also intelligente Dokumentenverarbeitung, lohnt sich dann, wenn es das Abtippen erspart und zugleich fehlerhafte Daten aus den Systemen fernhält. Der Ablauf umfasst 4 Aufgaben: Dokumente klassifizieren, Felder auslesen, Werte prüfen und unklare Fälle zur manuellen Prüfung weiterleiten, bevor etwas abgelegt oder gebucht wird.

Für Verantwortliche im operativen Geschäft oder im Finanzbereich ist das erste sinnvolle Ergebnis ein geprüfter Datensatzentwurf mit angehängtem Quelldokument. Automatische Zahlungen, die Auslegung von Verträgen und die Freigabe von Lieferanten sind eigenständige Entscheidungen. Der Einstieg sollte bei der Arbeit liegen, die täglich Zeit kostet: Anhänge lesen, Felder übertragen und den richtigen Ordner finden.

Funktionen und Grenzen wurden am 26. Oktober 2026 anhand der Herstellerdokumentation geprüft. Der folgende Pilot ist ein Vorschlag für ein Bewertungsverfahren, kein Produktbenchmark.

Wie funktioniert Intelligent Document Processing?

IDP bezeichnet einen Workflow, der Dokumente in nutzbare Datensätze überführt und unsichere Fälle zur Prüfung weitergibt. Das lässt sich mit einer Sachbearbeitung nach Checkliste vergleichen: den Eingang zuordnen, relevante Informationen übertragen, mit den Vorgaben abgleichen und ungeklärte Vorgänge an eine entscheidungsbefugte Person übergeben.

Am Anfang steht etwa ein strukturiertes Formular mit festen Eingabefeldern, eine teilstrukturierte Rechnung mit je nach Lieferant wechselndem Layout oder eine unstrukturierte E-Mail. Als Ziel kommen das Buchhaltungssystem, ein Vertragsregister oder eine Warteschlange in der Fallbearbeitung infrage. Die IDP-Übersicht von AWS beschreibt Klassifizierung, Extraktion, Validierung und Integration als Bestandteile dieses umfassenderen Prozesses.

Ein sinnvoller Rechnungsworkflow sieht so aus:

1. Klassifizieren. Feststellen, ob der Anhang eine Rechnung, Gutschrift, einen Kontoauszug oder etwas anderes enthält. Eine Sammeldatei vor dem Auslesen der Felder in ihre Einzeldokumente zerlegen.
2. Extrahieren. Lieferant, Rechnungsnummer, Datumsangaben, Währung, Gesamtbeträge und Rechnungspositionen auslesen. Die Originaldatei sowie die Seite oder den Bereich aufbewahren, der den jeweiligen Wert belegt.
3. Validieren. Pflichtfelder, Berechnungen, Dubletten und den Lieferantenstammsatz prüfen. Ein gut lesbarer Gesamtbetrag kann trotzdem zur falschen Rechnung gehören.
4. Weiterleiten. Einen akzeptierten Datensatz im dafür freigegebenen Zielsystem ablegen. Eine fehlende Bestellung, einen widersprüchlichen Gesamtbetrag oder eine unsichere Klassifizierung einer namentlich zuständigen Prüfperson zuweisen.

Diese Aufgaben müssen im Prozess vorgesehen werden; sie gehören nicht automatisch zum Funktionsumfang jeder Extraktions-API. Eine API ist die Schnittstelle, über die Software einen Dienst anfragt. Sie kann Felder zurückgeben, ohne die internen Freigaberegeln zu kennen.

Die Dateikennung muss über den gesamten Ablauf mit dem Datensatz verbunden bleiben. Andernfalls kann selbst eine korrekte Extraktion im Betrieb scheitern, weil sich das zugrunde liegende Dokument nicht mehr finden lässt.

Was verändern LLMs und Bildmodelle gegenüber OCR?

Der entscheidende Unterschied: Bei der Extraktion können Bedeutung und Seitenkontext berücksichtigt werden, statt sich allein an der Position eines Feldes zu orientieren. Die optische Zeichenerkennung, kurz OCR, liest Zeichen aus Bildern. Ein vorlagenbasierter Extraktor sucht anschließend an bekannten Positionen oder folgt Layoutregeln. Ein großes Sprachmodell, auch Large Language Model oder LLM, interpretiert Sprache; ein Vision-Language-Modell verarbeitet zusätzlich Bilder als Eingabe.

Ein Lieferant könnte beispielsweise den „Zahlbetrag“ von der rechten unteren Ecke in einen Übersichtsblock am Seitenanfang verschieben. Eine Regel mit fester Position muss dann angepasst werden. Ein Modell mit dem Auftrag, den zu zahlenden Gesamtbetrag zu finden, kann die Beschriftung und ihren Kontext heranziehen. Den falschen Betrag auszuwählen, bleibt dennoch möglich.

Der Custom Extractor von Google Document AI unterstützt die Extraktion mit Basismodellen anhand eines vorgegebenen Schemas, also der benannten Felder, die zurückgegeben werden sollen. Dafür gibt es Zero-Shot- und Few-Shot-Optionen: Die Verarbeitung erfolgt ohne aufgabenspezifische Beispiele oder mit einer kleinen Auswahl davon. Verwaltete Extraktionsdienste gehen damit bereits über den früheren, rein vorlagenbasierten Ansatz hinaus. Die Dokumentation zu Googles Custom Extractor erläutert die verfügbaren Verfahren.

Strukturierte Ausgaben lösen ein anderes Problem: Sie halten die Antwort in der benötigten Datenstruktur. Eine Zeichenfolge im Datumsfeld oder ein numerischer Gesamtbetrag lässt sich von Software leichter verarbeiten. Das Format belegt jedoch nicht, dass der Wert an der richtigen Stelle ausgelesen wurde. Schemavalidierung, die die Struktur prüft, und fachliche Validierung, die die Zulässigkeit eines Werts prüft, sollten getrennt bleiben.

Wo lässt sich intelligente Dokumentenverarbeitung einsetzen?

Für den ersten Workflow zählt, wie eindeutig sich ein korrektes Ergebnis definieren lässt. Eine klar begrenzte Extraktionsaufgabe lässt sich leichter bewerten als der Auftrag, „unseren gesamten Papierkram zu erledigen“.

In der Kreditorenbuchhaltung können aus Rechnungen Entwürfe für Eingangsrechnungen entstehen, Lieferanten zugeordnet und Dubletten markiert werden. Änderungen der Bankverbindung sollten von der automatischen Annahme ausgeschlossen bleiben, selbst wenn die gedruckte Kontonummer einwandfrei lesbar ist.

Bei Verträgen lassen sich Vertragsparteien, ausdrücklich genannte Datumsangaben und die Passage zur Verlängerung extrahieren. Eine Kündigungsfrist zu übernehmen ist etwas anderes, als ihre Geltung über mehrere Nachträge hinweg zu beurteilen. Mit dem ersten Ergebnis lässt sich im operativen Geschäft ein Register vorbereiten; das zweite erfordert eine verantwortliche Prüfperson.

Bei Formularen werden maschinenschriftliche Einträge und Auswahlmarkierungen erfasst und anschließend auf Vollständigkeit geprüft. Fehlt auf einem Onboarding-Formular eine vorgeschriebene Unterschrift, muss es unvollständig bleiben, statt durch eine erschlossene Antwort ergänzt zu werden.

Bei E-Mails geht es darum, das Anliegen zu erkennen und mit den Anhängen zu verknüpfen. Bei einer Nachricht wie „Bitte verwenden Sie die überarbeitete Rechnung“ muss der Workflow diesen Zusammenhang erhalten. Es reicht nicht, beide Anhänge auszulesen und dadurch doppelte Datensätze anzulegen.

Nach demselben Muster lassen sich auch die Erfassung von Schadensmeldungen, Versandunterlagen oder Personalakten unterstützen. Die Prüfung bleibt konkret: Welcher Wert wird benötigt, wo ist er belegt und wer klärt Widersprüche?

Software zur Dokumentenverarbeitung: kaufen oder selbst entwickeln?

Bei Standardaufgaben bietet sich ein fertiger Workflow an; wenn vor allem die eigenen Regeln und Zielsysteme besonders sind, lohnt sich eine Lösung auf Basis von Extraktionsdiensten. Entscheidend ist, wie viel Verantwortung für Eingang, Validierung, Prüfung und Integration im eigenen Unternehmen bleiben soll.

Ein verwalteter Dienst ist ein Baustein und nicht automatisch ein einsatzbereiter Finanzworkflow. Umgekehrt bedeutet „individuell“ nicht, ein Modell von Grund auf zu trainieren. Auch um einen gehosteten Extraktor lässt sich ein eigener Eingangs- und Prüfprozess aufbauen.

Für die Kaufentscheidung ist eine Vorführung besonders aufschlussreich: Die spätere Prüfperson bearbeitet einen Ausnahmefall und sieht dabei das Originaldokument direkt neben dem Datensatz. Eine gelungene Upload-Animation verrät wenig darüber, wie viel Arbeit danach übrig bleibt.

IDP-Anbieter und LLM-basierte Workflows im Vergleich

Die Ansätze sollten anhand des eigenen Dokumentmixes, der Anforderungen an Belege und des Prüfaufwands verglichen werden. Die folgenden Beschreibungen geben die dokumentierten Herstellerfunktionen wieder. Die Einschätzungen zur Eignung sind Empfehlungen, keine Rangliste nach Genauigkeit.

Google Document AI: spezialisierte Prozessoren und generative Extraktion

Google Document AI ist der Dokumentenverarbeitungsdienst von Google Cloud. Zum Prozessorkatalog gehören OCR, Invoice Parser, Custom Extractor, Custom Classifier und Custom Splitter. Invoice Parser extrahiert Kopf- und Positionsdaten; Klassifizierung und Aufteilung bestimmen Dokumenttyp und Dokumentgrenzen. Googles Prozessorkatalog erläutert die unterschiedlichen Aufgaben.

Als Einstieg eignet sich der passende vorgefertigte Prozessor. Deckt er die benötigten Felder oder Dokumenttypen nicht ab, lässt sich anschließend Custom Extractor evaluieren. Dessen generativer Ansatz unterstützt schemagesteuerte Extraktion sowie optional Beispiele oder Fine-Tuning. Google bietet für die Evaluation außerdem exakte und unscharfe Vergleiche. Deshalb sollte vor dem Ergebnisvergleich feststehen, welche Normalisierungen zulässig sind. Dokumentation zu Custom Extractor.

Die Grenze liegt bei der Verantwortung für den Workflow: Ein zurückgegebener Rechnungsbetrag ordnet noch keinen Lieferanten zu, setzt keine internen Vorgaben durch und erledigt keinen Ausnahmefall. Vor dem Pilot muss geprüft werden, welche Sprachen, Regionen und Dokumente die gewählte Prozessorversion unterstützt.

Azure AI Document Intelligence: vorgefertigte und eigene Modelle

Azure AI Document Intelligence ist Microsofts Dienst zur Dokumentenextraktion. Zu den dokumentierten Optionen zählen Read und Layout, vorgefertigte Modelle für Rechnungen und Belege, benutzerdefinierte vorlagenbasierte und neuronale Extraktion sowie benutzerdefinierte Klassifizierung. Microsoft beschreibt eigene Vorlagen als Ansatz für statische Layouts und neuronale Modelle für variantenreichere Dokumente. Microsofts Modellübersicht.

In einem operativen System auf Azure-Basis bietet sich zunächst das zum Dokument passende vorgefertigte Modell an. Enthalten eingehende Dokumentpakete unterschiedliche Klassen, kann eine benutzerdefinierte Klassifizierung ergänzt werden. Weichen die benötigten Felder ab, ist eine eigene Extraktion zu prüfen.

Die Grenze liegt in der Annahme, mit der Layouterkennung sei der fachliche Datensatz bereits vollständig. Layout kann Text, Tabellen und Auswahlmarkierungen erkennen; die Anwendung muss die Ausgaben weiterhin auf das Zielsystem abstimmen. Microsoft beschreibt in der Layout-Dokumentation ausdrücklich, wie sich seitenübergreifende Tabellen durch Nachverarbeitung zu einer Tabelle zusammenführen lassen.

Intelligente Dokumentenverarbeitung auf AWS: Amazon Textract

Amazon Textract ist der Dienst von Amazon Web Services zur Extraktion von Text und Daten aus Dokumenten. AWS dokumentiert Texterkennung, Formular- und Tabellenextraktion sowie spezialisierte Verarbeitung von Rechnungen und Belegen. Die Analyse von Ausgabenbelegen kann Felder wie Rechnungsdatum, Rechnungsnummer und Gesamtbetrag ohne lieferantenspezifische Vorlagen auslesen. Textract-Dokumentation zu Rechnungen und Belegen.

Textract ist ein sinnvoller erster Kandidat, wenn die umgebende Anwendung bereits auf AWS läuft und die Dokumentfelder zu seinen Operationen passen. Dabei sollte die passende Operation gewählt werden, statt jedes Dokument als reinen Text zu behandeln.

Die Grenze liegt in der Annahme, ein Konfidenzwert könne eine fachliche Entscheidung ersetzen. AWS empfiehlt, Schwellenwerte an der Sensibilität der Anwendung auszurichten und unsichere Ergebnisse prüfen zu lassen. Außerdem weist AWS auf uneinheitliche Extraktion bei verbundenen Zellen und unregelmäßigen Tabellen hin. Bewährte Verfahren für Textract.

Der LLM-basierte Ansatz: Modell, Schema und Prüfwarteschlange

OpenAI API ist ein dokumentiertes Beispiel für den LLM-basierten Ansatz: Eine Anwendung sendet ein Dokument an ein Modell und fordert Felder in einer festgelegten Struktur an. Bei PDFs stellt der Eingabepfad für bildfähige Modelle sowohl extrahierten Text als auch Seitenbilder bereit. Dokumentation zu Dateieingaben.

Die Anwendung legt die Felder fest, verlangt Verweise auf Belegstellen und bestimmt den Umgang mit fehlenden Werten. Dafür sollte es einen eigenen Status mit einer Begründung wie „nicht vorhanden“ oder „unleserlich“ geben. Das Modell darf nicht gezwungen werden, jede Lücke zu füllen. Belegverweise müssen mit der Originaldatei abgeglichen werden; eine generierte Seitenangabe ist nicht automatisch korrekt.

OpenAI dokumentiert die Einhaltung des Schemas für unterstützte strukturierte Ausgaben, weist aber ausdrücklich darauf hin, dass Werte weiterhin falsch sein können und Ablehnungen oder unvollständige Antworten behandelt werden müssen. Dokumentation zu Structured Outputs. Unser Leitfaden zu strukturierten Ausgaben erläutert den Schnittstellenvertrag zwischen Modell und Anwendung.

Dieser Ansatz passt, wenn kontextbezogene Extraktion die fehlende Fähigkeit ist und jemand den Workflow dauerhaft betreuen kann. Die Grenze liegt im Betrieb: Ein Prompt und eine JSON-Antwort lassen die Verantwortung für Evaluation, Wiederholungsversuche, Prüfung, Speicherung und sicheres Schreiben ins Zielsystem bei der eigenen Anwendung.

Dext: auf die Buchhaltung ausgerichtet

Dext ist eine Anwendung zur Belegerfassung für die Buchhaltung. Sie ist dann relevant, wenn sich Belege und Rechnungen stapeln. Laut Dokumentation werden Lieferant oder Kunde, Datumsangaben, Gesamtbeträge, Steuern und Rechnungsnummern extrahiert und in einer Detailansicht zur Prüfung, Bearbeitung und Übergabe an angeschlossene Buchhaltungssoftware bereitgestellt. Dext-Leitfaden zur Extraktion.

Für Finanzverantwortliche, deren Aufgabe mit einem geprüften Buchhaltungsdatensatz endet, ist das der passendere Einstieg als die Beauftragung eines universellen Dokumentensystems. Diese Empfehlung gilt nicht für die Auslegung von Verträgen oder die Steuerung beliebiger Formular- und E-Mail-Prozesse. Geht es um die Auswahl der Buchhaltungsanwendung selbst, hilft der Vergleich von KI-Buchhaltungssoftware.

Ein Pilot, der zuerst die Feldwerte prüft

Bevor ein Workflow auf Werte reagieren darf, muss gemessen werden, ob die fachlich benötigten Angaben stimmen. Ein scheinbar korrekt übertragenes Dokument kann ausgerechnet den entscheidenden Fehler enthalten: die falsche Währung, den falschen Lieferanten oder den falschen Zahlbetrag.

1. 1

   Eine Dokumentklasse und ihre Pflichtfelder festlegen

   Der Einstieg sollte eine klar begrenzte Aufgabe sein, etwa Lieferantenrechnungen in Entwürfe für Eingangsrechnungen zu überführen. Jedes Pflichtfeld, seine Quelle und die dadurch zulässige Aktion müssen benannt werden. Extrahierte und abgeleitete Werte sind zu trennen: Ein angegebenes Fälligkeitsdatum und ein aus Zahlungsbedingungen berechnetes Fälligkeitsdatum sind unterschiedliche Ergebnisse.

2. 2

   Menschlich geprüfte Referenzantworten erstellen und Testdaten zurückhalten

   Eine repräsentative Auswahl historischer Dokumente zusammenstellen, darunter unbekannte Lieferanten, schlechte Scans, Gutschriften und schwierige Tabellen. Ground Truth bezeichnet die von Menschen festgelegten korrekten Antworten. Mehrdeutige oder kritische Referenzwerte sollten von einer weiteren Person geprüft werden. Die Evaluationsdokumente müssen getrennt von den Beispielen bleiben, mit denen Prompts angepasst oder der Extraktor trainiert wird. Das gilt auch für nahezu identische Dokumente desselben Geschäftsvorgangs.

3. 3

   Vergleichsregeln vor der Ergebnissichtung vereinbaren

   Unbedenkliche Abweichungen wie führende oder abschließende Leerzeichen oder ein bekanntes Datumsformat normalisieren. Für Geldbeträge, Kontokennungen und Rechnungsnummern dürfen keine großzügigen Textähnlichkeitsregeln gelten. Währung und Bedeutung der Dezimalstellen müssen erhalten bleiben. Bei Rechnungspositionen zählen sowohl die Werte als auch ihre Zuordnung zur richtigen Zeile: Ein korrekter Betrag an der falschen Position ist ein Fehler.

4. 4

   Alle Kandidaten mit denselben unveränderten Dokumenten prüfen

   Jede Rohantwort vor manuellen Korrekturen speichern, ebenso die Modell- oder Prozessorversion, die Prompt- und Schemaversion, Verarbeitungsfehler und den Quellenverweis. Unlesbare Dateien, Zeitüberschreitungen und leere Extraktionsergebnisse gehören in die Betriebsauswertung. Sie dürfen nicht stillschweigend aus dem Nenner entfernt werden.

5. 5

   Ausnahmen zuweisen und parallel zum bestehenden Prozess testen

   Der vorgeschlagene Workflow erstellt zunächst Entwürfe neben dem laufenden Verfahren. Korrekturen und Prüfzeit werden gemessen. Die automatische Annahme darf nur für eine Dokumentteilmenge aktiviert werden, deren Ergebnisse auf zurückgehaltenen Testdaten die vorab vom Prozessverantwortlichen festgelegten Schwellenwerte erfüllen. Folgenreiche Aktionen behalten ihre eigene Freigabe.

Feldwerte, vollständige Datensätze und unbemerkte Fehler getrennt messen

Ein einzelner Durchschnittswert verdeckt, wo Fehler auftreten und welche Folgen sie haben. Eine Auswertung sollte die Ergebnisse für jedes Feld und jede schwierige Dokumentgruppe gesondert ausweisen.

Fehlende optionale Felder sollten separat ausgewiesen werden, damit Hunderte korrekt leerer Felder das Ergebnis nicht künstlich verbessern. Wird zusätzlich Recall berichtet, ist er als korrekt erfasste Pflichtwerte geteilt durch alle Pflichtwerte zu definieren. Dokumentklassifizierung und die Aufteilung von Dokumentpaketen sind getrennt zu bewerten: Auch eine perfekte Extraktion aus dem falschen Dokument ergibt einen fehlerhaften Datensatz.

Rechenbeispiel zur Veranschaulichung, keine gemessene Produktleistung: Angenommen, 200 Rechnungen benötigen jeweils 8 Felder. Daraus ergeben sich 1,600 erwartete Werte. Sind 1,590 Werte korrekt, während die übrigen 10 jeweils Zahlbeträge auf unterschiedlichen Rechnungen sind, sind nur 190 Rechnungen vollständig korrekt. Ein guter Gesamtwert über alle Felder reicht nicht aus, um sämtliche Rechnungen freizugeben.

Unbemerkte Fehler lassen sich durch die Kontrolle jener Datensätze messen, die der Workflow angenommen hätte. Nur die Prüfwarteschlange zu untersuchen, reicht dafür nicht. Zu Beginn sollte jede Pilotausgabe geprüft werden; spätere Stichproben müssen repräsentativ für die angenommenen Datensätze bleiben. Wurde kein Datensatz automatisch angenommen, ist die Fehlerquote undefiniert und kein perfektes Ergebnis. Dasselbe gilt für die Präzision, wenn kein Feld befüllt wurde.

Der Nutzen der Dokumentenautomatisierung: eingesparte Arbeit messen

Der betriebliche Nutzen liegt darin, mit weniger Zeitaufwand zu einem korrekten Datensatz zu gelangen. Deshalb muss die manuelle Bearbeitung mit dem gesamten vorgeschlagenen Prozess verglichen werden: Eingang, Modellverarbeitung, Korrektur, Prüfung, Export und Nacharbeit. Zusätzlich zählen Durchlaufzeit und Alter des ältesten ungeklärten Ausnahmefalls. Eine schnelle Extraktion mit wachsender Warteschlange verlagert den Rückstand lediglich.

Prüfpersonen benötigen die Quellseite, nach Möglichkeit hervorgehobene Belegstellen, den extrahierten Wert, die verletzte Regel und das Zielsystem. Korrektur und Begründung sollten protokolliert werden. Der Leitfaden zu Human-in-the-Loop-KI behandelt Zuständigkeiten für Warteschlangen und Eskalation. Festzulegen, wer Ausnahmefälle klärt, gehört zur Einführung des Workflows.

Wo IDP an Grenzen stößt: Handschrift, Tabellen und Scans

Schwierige Eingaben gehören bewusst in den Pilot. Eine Evaluation nur mit sauberen digitalen Rechnungen sagt wenig darüber aus, wie der Workflow mit einem Handyfoto, einem handschriftlich ergänzten Formular oder einer Tabelle über mehrere Seiten umgeht.

Handschrift braucht eine eigene Testgruppe. Durchgestrichene Beträge, Notizen in Schreibschrift und überlappende Stempel schaffen Mehrdeutigkeit, selbst wenn ein Produkt Handschrift unterstützt. Auch die Sprache kann entscheidend sein: Amazon Textract dokumentiert die Erkennung handschriftlicher Zeichen ausschließlich für Englisch. Grenzen von Textract. Eine unklare handschriftliche Korrektur muss zur Prüfung gehen, statt unbemerkt einen gedruckten Betrag zu ersetzen.

Bei mehrseitigen Tabellen muss der Zusammenhang geprüft werden. Ein Seitenumbruch kann eine Zeile trennen, eine Kopfzeile wiederholen oder eine Zwischensumme einführen, die wie eine Rechnungsposition aussieht. Zeilenanzahl, fortgesetzte Beschreibungen und Summen müssen über das gesamte Dokument hinweg geprüft werden. Microsofts Layout-Dokumentation behandelt ausdrücklich die Nachverarbeitung mehrerer Seiten zu einer Tabelle. Das ist ein Grund, das gewählte Modell und die Logik zum Zusammenführen zu testen. Es bedeutet nicht, dass jedes Modell an jeder mehrseitigen Tabelle scheitert.

Für schlechte Scans braucht es einen Weg zur erneuten Erfassung. Unschärfe, abgeschnittene Ränder und Kompression können Informationen entfernen, die ein Modell nicht zuverlässig wiederherstellen kann. AWS empfiehlt hochwertige Bilder, idealerweise mit mindestens 150 DPI, und rät davon ab, bereits unterstützte Dateien herunterzuskalieren. Bewährte Verfahren für Textract. Das Original bleibt erhalten; ist die Belegstelle unlesbar, muss eine deutlichere Kopie angefordert werden.

Auch fehlende Seiten und zusammengefasste Dokumentpakete gehören in den Test. Ein Datensatz kann jede Prüfung des Feldformats bestehen und trotzdem unvollständig sein. Fehlende Belege sollten einen eigenen Ausnahmegrund erhalten und nicht nur als allgemeiner Verarbeitungsfehler erscheinen.

Welche Erwartungen an IDP sind überzogen?

„Liest Dokumente“ bedeutet nicht „kann den Geschäftsvorgang sicher abschließen“. Drei Annahmen führen zu vermeidbaren Fehlern.

Erstens: Eine strukturierte Ausgabe ist keine geprüfte Ausgabe. Ein vorgegebenes Antwortschema kann nicht belegen, dass das extrahierte Bankkonto zum freigegebenen Lieferanten gehört.

Zweitens: Ein Konfidenzwert ist keine allgemeingültige Annahmeregel. Der Score eines Dienstes, die vom Modell selbst angegebene Sicherheit und die gemessene Korrektheit auf den eigenen Dokumenten sind verschiedene Dinge. Die Annahmeregel muss anhand zurückgehaltener Testdaten und möglicher Fehlerfolgen kalibriert werden. Eine vom Modell erzeugte Konfidenzzahl darf nicht als gemessene Wahrscheinlichkeit gelten.

Drittens: Gespeicherte Korrekturen trainieren das Modell nicht zwangsläufig neu. Sie sollten helfen, Fehlerursachen zu erkennen und Regeln, Prompts oder Trainingsdaten zu verbessern. Vor der Einführung muss die Änderung erneut evaluiert werden. Ein Regressionstestbestand, also eine feste Sammlung bereits geprüfter Dokumente, verhindert, dass eine Verbesserung für einen Lieferanten einen Fehler bei einem anderen verdeckt.

Wer sollte jetzt starten, abwarten oder beim bisherigen Verfahren bleiben?

Ein Einstieg lohnt sich, wenn wiederkehrende Dokumenteingänge ein klares Ziel, überprüfbare Felder und eine zuständige Person für Ausnahmen haben. Für Verantwortliche im operativen Geschäft besteht der nächste Schritt darin, eine repräsentative Stichprobe zusammenzustellen und die Pflichtfelder zu benennen. Im Finanzbereich sollten zunächst Datensatzentwürfe entstehen; die Zahlungsfreigabe bleibt getrennt.

Bei der Entwicklung sollte der einfachste passende Extraktor den Anfang machen. Wer allein eine technische Lösung entwickelt, kann ein verwaltetes Modell und einen LLM-basierten Ansatz mit derselben zurückgehaltenen Stichprobe vergleichen. IT-Verantwortliche im Mittelstand sollten Belegverweise, klare Prüfzuständigkeiten, Aufbewahrungsregeln und eine wiederholbare Evaluation verlangen, bevor der Workflow mit produktiven Datensätzen verbunden wird. Dokumenttext bleibt Eingabedaten: Er darf die Anweisungen oder Berechtigungen der Anwendung nicht verändern können.

Mit einer Anschaffung sollte gewartet werden, wenn niemand einen korrekten Datensatz definieren oder die Prüfwarteschlange verantworten kann. Wer ein finanziertes Start-up führt und vor dieser Lücke steht, sollte zunächst die Prozessverantwortung zuweisen, bevor eine individuelle Automatisierung beauftragt wird. Ein Team, dessen bestehendes Vorlagenverfahren stabile Formulare zuverlässig verarbeitet, muss es nicht allein wegen der Verfügbarkeit von Bildmodellen ersetzen.

Am Montag lässt sich mit einer Dokumentklasse beginnen: historische Beispiele sammeln, gemeinsam mit der Prüfperson die Annahmeregeln aufschreiben und den vorgeschlagenen Workflow zunächst Entwürfe erzeugen lassen. Eine Ausweitung ist erst sinnvoll, wenn die Feldergebnisse und der verbleibende Arbeitsaufwand sie rechtfertigen.

Häufige Fragen zur intelligenten Dokumentenverarbeitung

Was ist intelligente Dokumentenverarbeitung?

Sie bezeichnet einen Workflow, der Dokumente klassifiziert, Informationen extrahiert und validiert sowie die entstandenen Datensätze oder Ausnahmefälle weiterleitet. Das nützliche Ergebnis sind geprüfte Daten mit nachvollziehbarer Quelle.

Was unterscheidet OCR von intelligenter Dokumentenverarbeitung?

OCR liest Text aus einem Bild. IDP umfasst zusätzlich die Klassifizierung, Feldextraktion, Prüfungen und Weiterleitung, die nötig sind, um diesen Text in einem Geschäftsprozess zu nutzen. OCR kann ein Bestandteil davon sein.

Welche Software für intelligente Dokumentenverarbeitung ist die beste?

Entscheidend sind die Aufgabe und die Arbeit, die für Prüfpersonen übrig bleibt. Bei Belegen und Rechnungen bietet sich zunächst eine Buchhaltungsanwendung wie Dext an. Für individuelle Eingangsprozesse sollten ein verwalteter Extraktor oder ein LLM-Workflow anhand derselben menschlich geprüften Dokumente evaluiert werden.

Zählt IdP als KI?

Intelligente Dokumentenverarbeitung nutzt häufig KI für Klassifizierung und Extraktion, ergänzt um herkömmliche Geschäftsregeln. In anderen Zusammenhängen steht IdP für Identity Provider, also Identitätsanbieter. Das ist ein anderes Konzept.

Welche wichtigen IDP-Anbieter gibt es?

Google Document AI, Azure AI Document Intelligence und Amazon Textract sind die hier behandelten verwalteten Dienste. Verglichen werden Funktionen, nicht Marktanteile oder Genauigkeitsrangplätze. Die Eignung hängt von den Dokumenten und dem Workflow ab.

Welche KI eignet sich am besten für die Dokumentenverarbeitung?

Der beste Kandidat erfüllt die Annahmekriterien für Pflichtfelder und vollständige Datensätze bei einem überschaubaren Prüfaufwand. Ein Modell, das ungewöhnliche Layouts gut liest, kann trotzdem zusätzliche Kontrollen für Tabellen und fehlende Felder benötigen.

Gibt es eine bessere KI als ChatGPT?

Für wiederkehrende Dokumenteingänge sollte ein umgesetzter Workflow mit dem bisherigen Prozess verglichen werden. Eine einzelne Chatantwort reicht als Maßstab nicht aus. Unabhängig vom Modell braucht es vorhersehbare Felder, Quellenbelege, eine Behandlung von Ausnahmefällen und ein kontrolliertes Zielsystem.

Was kostet Document AI?

Die Preise von Google Document AI hängen vom Prozessor und vom Volumen ab. Maßgeblich ist die offizielle Preisseite für den Prozessor, der im Pilot eingesetzt werden soll.

Nutzt Google Docs eigene Texte für das KI-Training?

Für Google Workspace erklärt Google, Kundendaten ohne Erlaubnis nicht zum Training generativer KI-Modelle außerhalb der Domain des Kunden zu verwenden. Welche Regelung für das jeweilige Konto und die Funktion gilt, lässt sich in den Datenschutzrichtlinien für Workspace-KI prüfen. Google Docs ist vom hier besprochenen Dienst Document AI zu unterscheiden.

Praxisleitfäden zum Einsatz von KI in Geschäftsprozessen gibt es im Newsletter.