E-Mail → PDF → ERP: Dokumentenprozesse zuverlässig automatisieren

Ein Lieferant schickt eine Rechnung als PDF. Jemand öffnet den Anhang, sucht die Bestellung, prüft Beträge und erfasst den Beleg im ERP. Die Automatisierung muss diesen gesamten Übergang abbilden: Eine plausible JSON-Antwort allein erledigt den Vorgang noch nicht.

Kurzantwort: Halten Sie Eingang, Validierung, Freigabe und Systemzugriff in einem festen Workflow. Nutzen Sie Parser, OCR und gegebenenfalls ein Sprach- oder Vision-Modell für die Extraktion. Schreiben Sie nur freigegebene, fachlich geprüfte Daten ins ERP und behandeln Sie Wiederholungen über dauerhafte Vorgangskennungen.

Dieser Guide beschreibt eine Referenzarchitektur, keine bereits ausgelieferte ERP-Integration und keine BelegHelfer-Funktion. Für die Auswahl zwischen PDF-Parsern, spezialisierter Dokument-OCR und allgemeinen Vision-Modellen erläutert der OCR-/VLM-/Parser-Benchmark die offiziellen Vergleichsdaten und deren Grenzen. Die Entscheidungshilfe zur KI-Dokumentenverarbeitung ordnet geeignete Dokumente, Betriebsmodelle und Kaufen-vs.-Bauen ein.

Ein Ablauf mit kontrollierten Übergängen

Vom Posteingang zum bestätigten ERP-Vorgang

1. 01

   Eingang

   Anhang isolieren, Dateityp prüfen, Original und Vorgangskennung speichern.

2. 02

   Parsing / OCR

   Strukturierte Daten und Text-Layer zuerst; Seitenbilder nur bei Bedarf lesen.

3. 03

   Extraktion

   Dokumentklasse, Felder und Fundstellen als versionierten Vorschlag erzeugen.

4. 04

   Validierung

   Schema, Beträge, Pflichtfelder, Stammdaten und Dubletten prüfen.

5. 05

   Freigabe

   Abweichungen mit Original zeigen; Entscheidung und Version festhalten.

6. 06

   Systemintegration

   Freigegebene Version idempotent übertragen und ERP-ID bestätigen.

7. 07

   Logging

   Status, Fehler, Versionen, Laufzeit und Kosten über den gesamten Ablauf erfassen.

Logging begleitet alle Schritte. Es beginnt nicht erst nach der ERP-Übergabe. Originaldatei, extrahierter Vorschlag, fachlich korrigierte Version und ERP-Ergebnis bleiben getrennte Artefakte mit gemeinsamer Vorgangskennung.

1. Eingang: E-Mails sind keine vertrauenswürdige Datenquelle

Ein festgelegtes Postfach oder ein Upload begrenzt den Eingang. Speichern Sie Anhänge zunächst isoliert. Prüfen Sie tatsächlichen Dateityp, Größen- und Seitenlimits sowie erlaubte Formate. Dateiendungen allein reichen nicht. Verschlüsselte, beschädigte oder nicht unterstützte Dateien erhalten einen sichtbaren Fehlerstatus. Ein Virenscan und ein begrenzter Parser-Prozess gehören zum Schutzkonzept.

Eine Message-ID hilft beim Wiedererkennen derselben Nachricht. Ein Hash der Originaldatei erkennt identische Anhänge. Beide ersetzen keine fachliche Dublettenprüfung: Eine Rechnung kann unter anderem Dateinamen erneut eintreffen, während eine Weiterleitung die Mailkennung verändert.

Dokumenttext bleibt Eingabedaten. Eine Anweisung im PDF, die Bankverbindung zu ersetzen oder Daten an eine andere URL zu senden, darf weder Regeln noch Tool-Rechte verändern. Das Modell bekommt keinen direkten Schreibzugriff aufs ERP. Das entspricht den Schutzprinzipien der OWASP-Anleitung zu Prompt Injection.

2. Parsing und OCR: das einfachste brauchbare Verfahren zuerst

Prüfen Sie zuerst, ob maschinenlesbare strukturierte Daten vorliegen. Bei XML-Rechnungen ist ein passender Parser mit Formatvalidierung sinnvoller als das Abfotografieren und erneute Erraten derselben Werte. Ein digitales PDF kann einen Text-Layer enthalten. Dessen Vorhandensein garantiert allerdings weder korrekte Lesereihenfolge noch vollständig extrahierte Tabellen.

Scans brauchen Texterkennung oder ein bildverarbeitendes Verfahren. OCR erkennt Text aus Bildern. Ein Vision-Language-Modell (VLM) verarbeitet Bilder zusammen mit Sprachinformationen und kann Felder in ihrem visuellen Kontext zuordnen. Die Kategorien überlappen: Auch spezialisierte OCR-Systeme können VLMs verwenden. Parser bezeichnet die Verarbeitung einer Dateistruktur; eine PDF-Pipeline kann Parsing, Layoutmodelle und OCR kombinieren.

Docling dokumentiert unterschiedliche OCR-Engines und VLM-Pipelines. Daraus folgt keine allgemeine Qualitätsrangfolge. Entscheidend ist der Test mit den eigenen Dokumentklassen, einschließlich abgeschnittener Seiten, rotierten Scans und wiederholter Tabellenköpfe.

3. Extraktion: enge Aufgabe, nachprüfbare Ausgabe

Definieren Sie einen Ausgabecontract, bevor Sie einen Prompt schreiben. Für Rechnungen kann er Dokumenttyp, Aussteller, Rechnungsnummer, Datum, Währung, Bruttobetrag und Steuerzeilen umfassen. Aufträge brauchen andere Felder und Zuordnungsregeln. Unbekannte Werte bleiben ausdrücklich leer; ein Modell darf Pflichtfelder nicht durch plausible Ergänzungen erfüllen.

Ein Feld benötigt neben seinem normalisierten Wert eine Fundstelle: beispielsweise Seite und Textausschnitt oder Bildregion. Die Google-Document-AI-Referenz beschreibt Text- und Seitenanker als mögliche Herkunftsangaben. Ob der eingesetzte Dienst diese für jedes benötigte Feld liefert, muss separat geprüft werden.

Mehrstufige Extraktion ist eine zu testende Architekturvariante, kein automatischer Qualitätsgewinn. Wenn die richtige Währung bereits extrahiert wurde und ein nachgelagerter Assembler sie durch EUR ersetzt, liegt der Fehler im Contract. Ein größeres Modell behebt diese Ursache nicht.

4. Validierung: syntaktisch gültig ist fachlich noch nicht richtig

Betragskonsistenz beweist keine inhaltliche Richtigkeit: Auch aus falsch erkannten Zahlen kann eine passende Summe entstehen. Neue Lieferanten, geänderte Bankdaten und ungeklärte Dokumenttypen bleiben deshalb eigene Freigabegründe. Der Ablauf ersetzt keine steuerliche oder rechtliche Beurteilung.

5. Freigabe: Korrekturzeit ist Teil der Produktqualität

Eine brauchbare Prüfoberfläche zeigt Original und Vorschlag nebeneinander, hebt fehlende oder widersprüchliche Felder hervor und nennt den Grund für die Prüfung. Sie speichert, wer welche Version korrigiert und freigegeben hat. Ändert sich danach der Inhalt, wird die Freigabe ungültig und muss neu erfolgen.

Ein vom LLM selbst ausgegebener Wert wie „confidence: 0.99“ ist keine gemessene Fehlerwahrscheinlichkeit. Microsoft erläutert, wie Konfidenzwerte interpretiert und mit eigenen Dokumenten geprüft werden sollten. Kombinieren Sie solche Signale mit fachlichen Regeln und gemessenen Fehlern. Im ersten Pilot werden alle Vorschläge geprüft; automatische Freigaben brauchen einen separat belegten, eng begrenzten Scope.

6. ERP-Übergabe: Dubletten und Retries zusammen lösen

Ein Timeout bedeutet nicht, dass das ERP nichts gespeichert hat. Wiederholt ein Worker die Anfrage blind, kann eine zweite Rechnung entstehen. Eine robuste Integration speichert deshalb den Übertragungsauftrag dauerhaft und ordnet ihm einen stabilen Idempotenzschlüssel zu. Eine mögliche Kennung verbindet Mandant, Vorgang und freigegebene Revision.

Unterstützt das ERP Idempotenzschlüssel, verwenden Sie dessen dokumentierten Contract. Andernfalls braucht es eine eindeutige externe Referenz und eine Abfrage zum Abgleich. Lässt sich nach einem Timeout weder Erfolg noch Misserfolg sicher feststellen, geht der Vorgang in „Übertragung unklar“ und wird abgeglichen, bevor erneut geschrieben wird. Eine lokale Sperre allein garantiert keine einmalige Ausführung im entfernten System.

Eine transaktionale Outbox kann den lokalen Freigabestatus mit dem Übertragungsauftrag verbinden. Auch damit muss der Zieladapter die oben beschriebenen unklaren Remote-Zustände behandeln. Ein LLM sollte weder Ziel-URL noch Datenbankbefehle oder frei gewählte ERP-Aktionen bestimmen.

7. Logging: diagnostizierbar bleiben, Datenmenge begrenzen

Pro Vorgang sind Statuswechsel, technische Fehlerklasse, Pipeline-/Modell-/Schema-Version, Freigaberevision, ERP-Referenz, Laufzeit und Verbrauch hilfreich. Sensible Belegtexte, API-Keys und vollständige Providerantworten gehören nicht ungeprüft in Standardlogs. Originale und geschützte Diagnoseartefakte brauchen eigene Zugriffs- und Löschregeln.

Drei getrennte Zeiten verhindern irreführende Erfolgsmeldungen: Verarbeitungszeit der Maschine, aktive menschliche Prüfzeit und gesamte Durchlaufzeit einschließlich Warteschlangen. Eine schnellere Extraktion kann insgesamt schlechter sein, wenn mehr Korrekturen notwendig werden.

Wirtschaftlichkeit: Kosten pro fertig bearbeitetem Vorgang

Rechenbeispiel, keine Messung und kein Preisangebot: 1.000 Vorgänge pro Monat kosten bei vier Minuten manueller Bearbeitung und 40 Euro internen Stundenkosten rund 2.667 Euro. Nach Automatisierung ergeben angenommene 1,5 Minuten Prüfung 1.000 Euro; mit zusätzlich 200 Euro Technik und 400 Euro Betrieb bleiben rund 1.067 Euro rechnerische Entlastung pro Monat. Bei angenommenen 6.000 Euro Einrichtung läge die rechnerische Amortisation bei rund 5,6 Monaten.

Bei drei Minuten verbleibender Prüfung blieben unter denselben Annahmen nur rund 67 Euro monatlich und etwa 90 Monate Amortisation. Das Beispiel zeigt, warum die gemessene Nacharbeit die Entscheidung kippen kann. Freie Arbeitszeit ist zudem nicht automatisch eingespartes Geld. Einmalige Umstellung, Schulung, Ausfälle und Opportunitätskosten müssen in einer vollständigen Rechnung ergänzt werden.

Die offiziellen Google-Preise unterscheiden Prozessorarten und Abrechnungseinheiten. Ein günstiger OCR-Seitenpreis ist kein Preis für den fertigen ERP-Prozess. Vergleichen Sie identische Aufgaben einschließlich Klassifikation, Extraktion, Wiederholungen, Review und Betrieb.

Ein begrenzter Pilot mit vorher festgelegtem Abbruch

Wählen Sie eine Dokumentklasse, einen Eingangskanal und ein Zielsystem. Erfassen Sie zunächst manuelle Bearbeitungszeit und häufige Ausnahmen. Eine vorgeschlagene Startstichprobe von 50 bis 100 repräsentativen Fällen kann häufige Probleme sichtbar machen; sie beweist keine seltene Fehlerrate. Trennen Sie Entwicklungsfälle von einer unangetasteten Testmenge und halten Sie Lieferantenlayouts nach Möglichkeit auseinander.

Vergleichen Sie einen einfachen Parser-/OCR-Pfad mit einer zusätzlichen KI-Variante. Gleiche Eingaben, Zielfelder und Bewertungsregeln sind Voraussetzung. Bewerten Sie Felder einzeln und anschließend den vollständigen Vorgang. Für variable Positionstabellen sind Precision, Recall und F1 geeigneter als eine pauschale „Accuracy“; die Google-Evaluationsdokumentation erklärt diese Unterscheidung.

Beispielhafte Pilotkriterien, vor Beginn an den Prozess anzupassen: keine ungeprüften ERP-Schreibvorgänge; keine zweite Anlage beim Wiederholen desselben freigegebenen Vorgangs; vollständige Fehlerzustände; mindestens 30 Prozent weniger aktive Bearbeitungszeit und positiver monatlicher Nettonutzen unter konservativen Annahmen. Das sind Zielwerte, keine erreichten Ergebnisse.

Abbruch oder engerer Scope: wenn Korrekturzeit den Nutzen aufzehrt, das ERP keine sichere Übergabe ermöglicht oder kritische Fehler nicht zuverlässig in die Prüfung gelangen. Zusätzliche Modelle oder Connectoren sind dann keine automatische Lösung.

Die passende nächste Entscheidung

Nutzen Sie die Bewertung des Dokumentenprozesses, um Dokumentklasse, Volumen, Nacharbeit und Integrationsgrenzen festzuhalten. Prüfen Sie bestehende Buchhaltungs-, ERP- oder DMS-Funktionen, bevor Sie einen eigenen Dienst entwickeln.

Für die übergeordnete Architekturentscheidung helfen KI-Agent vs. Workflow und KI-Pilot planen. Wenn Dokumente primär für Fragen und Wissenssuche erschlossen werden sollen, ist DMS an RAG anbinden die passende Vertiefung. Ein bereits vorhandener Prototyp lässt sich anhand der Production-Readiness-Kriterien prüfen.

Für österreichische EPU mit Belegvorbereitung als eigenem Problem ist BelegHelfer ein Produktansatz zum Kennenlernen. Öffentlicher Stand am 11. Oktober 2026: Pre-Launch mit Voranmeldung, kein sofortiger App-Zugang, Preis und Starttermin noch offen. Die Seite zeigt eine Designvorschau mit Beispieldaten; direkte DATEV-, BMD- oder ERP-Anbindungen sind nicht zugesagt. Der hier beschriebene ERP-Workflow ist keine verfügbare BelegHelfer-Funktion.