Dokumentenverarbeitung mit KI: PDFs, Rechnungen und E-Mails automatisieren

Mit einer wiederkehrenden Aufgabe beginnen

Geeignete Einstiege sind Eingangsrechnungen mit klaren Pflichtfeldern, Bestellungen mit wiederkehrenden Positionen oder Lieferscheine mit einer eindeutigen Zuordnung. Ein Dokumenttyp, ein Eingangskanal und ein Zielsystem lassen sich eher belastbar prüfen als der gesamte Posteingang.

Bei geringem Volumen und kurzen manuellen Abläufen kann eine vorhandene Buchhaltungsfunktion oder ein einfacher Import wirtschaftlicher sein. Verträge mit Auslegungsfragen und Dokumente mit weitreichenden Entscheidungen brauchen andere Kontrollen als das Erfassen eines Rechnungsdatums.

Parser, OCR und Vision-Modelle nach Datenlage wählen

OCR bedeutet optische Texterkennung: Zeichen in einem Bild werden als Text erkannt. Ein Vision-Language-Modell verarbeitet Bild- und Sprachinformationen zusammen und kann Daten im visuellen Kontext zuordnen. Ein Parser liest die Struktur eines Dateiformats. Diese Verfahren sind kombinierbar; spezialisierte OCR-Modelle können selbst VLMs sein.

Ein digitales PDF mit Text-Layer braucht nicht automatisch Vision. Ein vorhandener Text-Layer kann aber fehlerhafte Reihenfolgen oder unbrauchbare Tabellen liefern. Prüfen Sie daher die Ausgabe, bevor daraus Geschäftsfelder entstehen. Für strukturierte Rechnungsdaten ist Formatvalidierung meist der sinnvollere erste Schritt als erneute Texterkennung.

Klassifikation und Extraktion enden bei einem Vorschlag

Klassifikation ordnet das Dokument einer vorgegebenen Klasse zu. Extraktion überführt relevante Angaben in ein festes Schema. Zu jedem kritischen Feld sollten Originalwert, normalisierter Wert und Fundstelle erhalten bleiben. Unbekannte Klassen und nicht erkennbare Werte bekommen einen eigenen Status.

Ein gültiges JSON beweist keine richtige Rechnung. Fachliche Prüfungen vergleichen Pflichtfelder, Beträge, Währungen, Rundungen, Steuerzeilen und freigegebene Stammdaten. Summenprüfungen sind wichtig, können aber gemeinsam falsch erkannte Zahlen nicht sicher erkennen. Die Steuerbehandlung muss zum konkreten Fall passen und gegebenenfalls fachlich geprüft werden.

Beispiel: Auf einer Rechnung stehen Brutto 120,00 Euro und nach einer Teilzahlung noch 80,00 Euro offen. Werden 80,00 Euro als Rechnungsbetrag übernommen, ist die Ausgabe formal plausibel und fachlich falsch. Der Feldcontract muss Bruttobetrag und Restzahlungsbetrag unterscheiden.

Unsicherheit braucht einen sichtbaren Prüfweg

Human-in-the-loop bedeutet eine technisch vorgesehene menschliche Prüfung. Die Oberfläche zeigt Original und Vorschlag, markiert fehlende oder widersprüchliche Felder und erklärt den Prüfgrund. Korrektur und Freigabe beziehen sich auf eine konkrete Revision; nach einer Änderung wird erneut freigegeben.

Konfidenzwerte sind Signale, keine Garantie. Eine vom LLM selbst behauptete Sicherheit ist keine kalibrierte Fehlerwahrscheinlichkeit. Prüfen Sie Schwellen mit eigenen Referenzfällen und messen Sie sowohl übersehene Fehler als auch unnötige Eskalationen. Im ersten Pilot ist die Prüfung aller Vorschläge die sinnvollere Ausgangsbasis.

Neue Geschäftspartner, geänderte Kontoverbindungen, unklare Währungen und fachliche Abweichungen bleiben gesonderte Kontrollgründe. Automatische Zahlungen sind ein eigener, wesentlich folgenreicherer Scope und gehören nicht stillschweigend zum Auslesen.

ERP, CRM und DMS über kontrollierte Schnittstellen anbinden

Das Zielsystem bleibt führend für seine Stammdaten und fachlichen Regeln. Ein Adapter übersetzt freigegebene Dokumentdaten in dessen dokumentierten API- oder Importcontract. Ein neues JSON-Format allein ist keine fertige Integration. Verfügbare Schnittstellen, Schreibrechte, Rate-Limits und Fehlerverhalten werden vor der Extraktionsentwicklung geprüft.

Bei einem Timeout kann der Datensatz bereits angelegt worden sein. Dauerhafte Vorgangskennungen, Idempotenz oder ein Abgleich über eine eindeutige externe Referenz verhindern blindes erneutes Schreiben. Unklare Übertragungszustände brauchen eine separate Klärung. Dubletten sind zusätzlich fachlich über Mandant, Aussteller und Rechnungsnummer zu prüfen.

Ein DMS speichert Dokumente und Versionen; ein ERP verarbeitet Geschäftsvorgänge; ein RAG-System erschließt Wissen für Fragen mit Quellen. Diese Ziele haben unterschiedliche Qualitätskriterien. Eine gut beantwortete Dokumentfrage beweist keine korrekte ERP-Buchung.

Datenflüsse und Betrieb konkret festlegen

Dokumente können personenbezogene und vertrauliche Daten enthalten. Erfassen Sie den gesamten Datenfluss: Postfach, Speicher, Parser, Modellanbieter, Prüfoberfläche, Zielsystem, Backups und Logs. EU-Hosting oder lokale Inferenz allein belegen keine Datenschutzkonformität. Verträge, Zweck, Zugriffsrechte, Aufbewahrung und Löschung müssen zur tatsächlichen Verarbeitung passen.

Dokumentinhalte dürfen keine Systemanweisungen werden. Begrenzen Sie Dateigrößen und Formate, isolieren Sie Parser, behandeln Sie unbekannte Eingaben sicher und halten Sie ERP-Zugangsdaten außerhalb des Modells. Auch menschliche Freigaben und Wiederholungen brauchen Mandanten- und Berechtigungsprüfungen.

Document-AI-Kosten am fertigen Vorgang vergleichen

Die Gesamtkosten umfassen Einrichtung, Integration, Software oder API-Verbrauch, Speicher, Betrieb, Evaluation und menschliche Prüfung. Anbieter rechnen je nach Verfahren beispielsweise pro Seite, Dokument, Token oder Kapazität ab. Lesen Sie den konkreten Tarif: OCR-Preis und vollständige Datenextraktion sind unterschiedliche Leistungen.

Für eine Entscheidung zählen Kosten pro fertig bearbeitetem Vorgang und aktive Prüfzeit. Wiederholungen, schwierige Dokumente und neue Layouts gehören in die Rechnung. Zeitentlastung wird erst dann zu finanzieller Einsparung, wenn sie tatsächlich Kosten senkt oder wirtschaftlich nutzbare Kapazität schafft.

Rechenbeispiel, keine Messung: Bei 1.000 Dokumenten und 40 Euro internen Stundenkosten verursacht jede verbleibende Minute Prüfung rund 667 Euro im Monat. Eine scheinbar günstige Extraktion kann deshalb teurer sein als ein Verfahren mit weniger Korrekturen. Der technische Leitfaden zeigt eine vollständige, ausdrücklich hypothetische Pilotkalkulation.

Kaufen, integrieren oder selbst entwickeln

Prüfen Sie zuerst, ob das vorhandene Buchhaltungs-, ERP- oder DMS-System die Aufgabe ausreichend löst. Vergleichen Sie dann einen spezialisierten Dienst mit einem schmalen eigenen Workflow an denselben Fällen. Ein eigener Foundation-Model-Build ist für diesen Einstieg normalerweise keine notwendige Voraussetzung.

Den Dokumentenprozess selbst bewerten

Halten Sie die folgenden Angaben in einer kurzen Prozessnotiz fest. Damit können Sie vorhandene Funktionen oder Produkte vergleichen, bevor Sie eine individuelle Umsetzung beauftragen. Vertrauliche Originalbelege sollten nicht ungeprüft an Anbieter geschickt werden.