Auftragserfassung mit KI: vom E-Mail-Auftrag zum geprüften ERP-Vorgang

Eine Kundenbestellung, zwei Preise und eine offene Entscheidung

Der Vertriebsinnendienst eines fiktiven technischen Großhandels erhält eine E-Mail. Kunde K-210 bestellt unter seiner Referenz B-1042 zwölf Kartons des Artikels DR-08. Jeder Karton enthält 50 Dichtungsringe. In der E-Mail und im Bestellblatt stehen 0,80 Euro netto je Stück sowie der 23. Oktober 2026 als gewünschter Liefertermin.

Der hinterlegte Preis beträgt jedoch 0,85 Euro je Stück. Damit ist die Bestellung lesbar und rechnerisch verarbeitbar, aber noch nicht zur Anlage freigegeben. Genau diese Unterscheidung muss ein KI-Workflow beherrschen.

Die Automatisierung erfasst einen eingehenden Kundenauftrag und bereitet daraus einen Verkaufsauftrag vor. Der Wunschliefertermin bleibt zunächst ein Wunsch. Ob Ware verfügbar ist und welcher Termin zugesagt werden kann, ist eine zusätzliche fachliche Entscheidung. Das Beispiel beschränkt sich auf die Erfassung der Position; Versandkosten, Steuern und weitere Konditionen sind im dargestellten Warenwert nicht enthalten.

Wer zunächst einen geeigneten Einsatzbereich sucht, findet im Ratgeber zur KI-Automatisierung im Mittelstand die vorgelagerte Prozessauswahl. Hier verfolgen wir eine konkrete Kundenbestellung einschließlich ihrer Ausnahmen.

Welche Aufgabe übernimmt die KI im Ablauf?

Im Musterfall soll die KI die sprachlichen und dokumentbezogenen Angaben erschließen: Welche Nummer ist die Kundenreferenz? Bezieht sich der Preis auf einen Karton oder auf ein Stück? Wo steht das gewünschte Lieferdatum? Die Antwort wird als strukturierter Vorschlag gespeichert, zusammen mit der jeweiligen Fundstelle.

Eine rechnerisch oder fachlich bestimmte Prüfung gehört anschließend in nachvollziehbare Regeln. Zwölf mal 50 ergibt 600. Ob der Kunde diesen Artikel bestellen darf, welche Preise gelten und wer eine Abweichung bestätigen kann, entscheidet sich anhand der freigegebenen Unternehmensdaten und Zuständigkeiten.

Diese Arbeitsteilung hält den Ablauf überprüfbar. Ein gut formatiertes Ergebnis kann inhaltlich falsch sein. Auch ein hoher Konfidenzwert aus der Dokumentenerkennung ersetzt die Kontrolle einer geschäftskritischen Angabe nicht. Microsoft beschreibt Konfidenzwerte als Hilfsmittel für die Bewertung und empfiehlt, menschliche Prüfung passend in den Ablauf einzubeziehen. Für den eigenen Prozess sollten Prüfgrenzen anhand repräsentativer Dokumente getestet werden. Das ist unsere Anwendung auf den Musterfall; eine allgemeingültige Prozentgrenze lässt sich aus der Quelle nicht ableiten. [1]

Ein Beispiel: Erkennt das Modell 12 Stück, obwohl im Bestellblatt 12 Kartons stehen, kann die Ausgabe technisch gültig sein. Erst die Prüfung von Originaleinheit, Packungsgröße und Basismenge deckt den Fehler auf. Deshalb behalten wir im Datenmodell sowohl 12 Kartons als auch den abgeleiteten Wert 600 Stück.

Die Preisabweichung bleibt sichtbar, bis jemand sie klärt

Im Hauptfall berechnet der Workflow zwei Werte: 600 Stück zu 0,80 Euro ergeben einen vorgeschlagenen Warenwert von 480 Euro netto. Nach dem hinterlegten Preis wären es 510 Euro. Die Differenz beträgt 30 Euro. Die Aussage des Kunden, der Preis sei besprochen, ist zunächst eine Angabe aus der Bestellung.

Unsere Fallregel sieht vor, dass eine vertriebsverantwortliche Person die Abweichung entscheidet. Sie muss den vereinbarten Preis anhand eines gültigen Angebots oder einer anderen zulässigen Grundlage nachvollziehen können. Ein Kommentar wie „KI ist sich sicher“ genügt dafür nicht. Die Entscheidung wird mit Begründung und Bezug auf die geprüfte Auftragsfassung gespeichert.

Für den weiteren Lehrfall nehmen wir an, dass die zuständige Person den Preis von 0,80 Euro bestätigt. Diese konstruierte Entscheidung erklärt den folgenden Ablauf. Ein tatsächlich vorhandenes Angebot, eine reale Freigabe oder eine Produktfunktion wird damit nicht nachgewiesen.

Die Ausnahmebearbeitung braucht einen sichtbaren Ausgang: nachgeforderte Angabe, bestätigte Korrektur, begründete Ablehnung oder weiterhin offener Vorgang. Eine Meldung im technischen Protokoll reicht dem Vertriebsinnendienst nicht, wenn dadurch eine Kundenbestellung unbearbeitet liegen bleibt. In der Arbeitsliste sollten Grund, zuständige Person und nächster Schritt erkennbar sein.

Eine feste Regel zur Quellenpriorität kann sinnvoll sein, etwa wenn vertraglich ein bestimmtes Bestellformat vereinbart wurde. Sie muss fachlich festgelegt sein. Für unseren Musterfall gilt ausdrücklich: Widersprechen sich E-Mail und Anhang, wird die Bestellung geklärt. Die KI darf den Konflikt nicht still auflösen.

Ein ERP-Timeout darf keinen zweiten Auftrag erzeugen

Nach der Preisfreigabe ist der Auftrag fachlich vorbereitet. Nun muss die Systemübergabe funktionieren, auch wenn eine Antwort ausbleibt. Ein typischer Fehler entsteht, wenn das ERP einen Auftrag bereits angelegt hat, die aufrufende Anwendung die Bestätigung aber nicht erhält. Ein zweiter Anlageversuch könnte dann einen weiteren Auftrag erzeugen.

Für diesen Fall werden zwei Kennungen benötigt. Die fachliche Bestellreferenz verbindet Kunde K-210 und Bestellung B-1042. Sie hilft, wiederholte Eingänge oder Änderungen derselben Kundenbestellung zu erkennen. Eine technische Anfragekennung bezeichnet dagegen genau eine freigegebene Übertragungsoperation. Bei der Wiederholung dieser Operation bleibt sie unverändert.

Ob das Zielsystem eine solche Kennung unterstützt, muss an seiner konkreten Schnittstelle geprüft werden. Das Prinzip idempotenter Schnittstellen besteht darin, dass eine wiederholte Anfrage nicht erneut dieselbe beabsichtigte Wirkung auslöst. AWS erläutert dafür unter anderem vom Aufrufer vergebene Anfragekennungen und die Unterscheidung zwischen einer Wiederholung und einer neuen Absicht. [2]

Eine neue E-Mail ist ebenfalls nicht automatisch ein neuer Auftrag. Der Kunde könnte die Bestellung weiterleiten, sodass sich technische Nachrichtenkennung und Dateihash ändern. Die fachliche Referenz bleibt dieselbe. Ändert der Kunde hingegen zwölf auf 14 Kartons, entsteht eine Änderungsversion. Diese muss mit der bisherigen Fassung verglichen und erneut freigegeben werden. Für eine spätere Änderungsübertragung wird eine eigene technische Operation angelegt.

Das Journal verbindet Eingang, erfasste Daten, Prüfentscheidungen, freigegebene Fassung und ERP-Rückmeldung. Der Status „im ERP bestätigt“ wird erst gesetzt, wenn eine belastbare Bestätigung mit der entsprechenden Vorgangskennung vorliegt. Ein erfolgreicher Versand der Anfrage allein genügt dafür nicht.

Dokumentinhalt gibt keine Schreibrechte

E-Mails und Anhänge kommen von außen. Neben Bestelldaten können sie auch Text enthalten, der ein Sprachmodell zu anderen Aktionen auffordert, etwa eine Preisprüfung zu überspringen. Solche eingebetteten Anweisungen dürfen die vorgegebenen Prozessregeln nicht verändern. OWASP beschreibt dieses Problem als indirekte Prompt Injection, wenn manipulierte Inhalte über Dokumente oder andere externe Quellen in den Modellkontext gelangen. [3]

Für den beschriebenen Ablauf empfehlen wir eine technisch durchgesetzte Trennung: Die Extraktion erzeugt Datenvorschläge. Eine separate Komponente prüft Felder und Regeln. Ein nur dafür berechtigter Dienst überträgt die freigegebene Fassung an das ERP. Welche Aktion zulässig ist, entscheiden die Anwendung und ihre Rechteprüfung. Eine entsprechende Formulierung im Prompt ersetzt diese Grenzen nicht.

Die menschliche Freigabe muss ebenfalls an etwas Konkretes gebunden sein: an Datenstand, Aktion und Zielsystem. Wenn nach der Freigabe Menge, Preis oder Empfänger geändert werden, darf die alte Zustimmung die neue Fassung nicht automatisch abdecken. Eine erneute Entscheidung wird dann Teil des Ablaufs.

Im echten Betrieb kommen weitere Aufgaben hinzu: Anhänge sicher entgegennehmen, zulässige Dateitypen festlegen, Zugangsdaten schützen, Protokollzugriffe begrenzen und Aufbewahrung sowie Datenweitergabe passend zum Einsatz klären. Für die hier beschriebenen Tests sind Kunden und Adressen vollständig synthetisch. Daraus folgt keine Aussage darüber, welche realen Daten eine bestimmte Installation an einen Modellanbieter übermitteln darf.

Vierzehn Prüffälle vor dem ersten produktiven Auftrag

Eine Vorführung mit einem gut lesbaren Bestellblatt zeigt nur einen kleinen Ausschnitt. Die Abnahme muss auch Fälle enthalten, die offenbleiben oder bewusst gestoppt werden sollen. Für unseren Musterfall sind deshalb 14 Prüfungen vorbereitet. Sie beschreiben Eingaben, erwartetes Verhalten und erforderliche Nachweise. Ihre tatsächlichen Ergebnisfelder bleiben leer.

Die vollständigen Unterlagen ergänzen unter anderem widersprüchliche Mengen, einen unbekannten Artikel, eine unberechtigte Freigabe, eine geänderte Bestellung und fehlende Pflichtangaben. Zu jedem ausgeführten Test gehören die tatsächlich eingesetzte Anwendungsversion, Modellkonfiguration, Datenbasis und prüfende Person. Diese Angaben machen spätere Fehler nachvollziehbar.

Für den Vergleich braucht der Fachbereich einen eigenen Referenzbestand. Er sollte unterschiedliche Kundenformate, Scanqualitäten, Artikelbezeichnungen, Packungseinheiten und echte Ausnahmearten enthalten. Vorher festgelegte Soll-Ergebnisse helfen zu erkennen, ob ein vermeintlich besseres Modell an anderer Stelle neue Fehler erzeugt. Ein bestandener kleiner Musterfall allein belegt noch keine zuverlässige Verarbeitung des gesamten Bestelleingangs.

Nach Änderungen am Modell, Extraktionsschema, Stammdatenabgleich oder Regelwerk werden die betroffenen Fälle erneut ausgeführt. Dabei zählt auch, ob unzulässige Übertragungen zuverlässig unterbleiben und ob offene Vorgänge bei der richtigen Person landen.

Freie Bearbeitungszeit und eingesparte Ausgaben getrennt rechnen

Die Wirtschaftlichkeit hängt vom gesamten Vorgang ab. Eine schnelle Erfassung kann durch aufwendige Korrekturen wieder aufgezehrt werden. Unser Rechenbeispiel berücksichtigt deshalb eine Grundprüfung bei jeder Bestellung und zusätzliche Arbeit bei Ausnahmen.

Bei diesen Annahmen benötigt der neue Ablauf durchschnittlich 2 + 0,25 × 6 = 3,5 Minuten pro Bestellung. Gegenüber acht Minuten sind das 4,5 Minuten weniger. Bei 800 Bestellungen ergibt sich eine rechnerisch frei werdende Kapazität von 60 Stunden im Monat. Die sechs Ausnahmeminuten kommen zur Grundprüfung hinzu.

Wird eine Stunde mit 40 Euro bewertet, entspricht die Kapazität einem Modellwert von 2.400 Euro monatlich. Nach angenommenen laufenden Kosten von 600 Euro verbleiben 1.800 Euro. Bei 18.000 Euro einmaligem Aufwand ergäben sich rechnerisch zehn Monate, bis dieser Aufwand durch den angesetzten Nutzen gedeckt wäre. Das gilt nur, wenn die freie Kapazität tatsächlich entsprechend genutzt oder in vermeidbare Ausgaben übersetzt werden kann.

Bei 50 Prozent Ausnahmeanteil steigt die durchschnittliche Bearbeitung auf fünf Minuten. Es werden noch 40 Stunden frei. Bei unverändertem Bewertungsansatz bleiben nach laufenden Kosten 1.000 Euro monatlicher Kapazitätswert; die rechnerische Deckung des Einmalaufwands läge bei 18 Monaten. Diese Sensitivität ist eine Planungshilfe. Sie ersetzt keine Messung.

Vor einem Ausbau sollten deshalb vergleichbare Aufträge mit und ohne Unterstützung ausgewertet werden: Bearbeitungszeit einschließlich Prüfung, notwendige Nacharbeit, offen gebliebene Vorgänge und unzulässige Mehrfachanlagen. Für die Aufwandsschätzung gehören auch Schnittstellenarbeit, Stammdatenpflege, Betrieb und erneute Abnahmetests auf die Liste.

Mit einem begrenzten Kundenformat anfangen

Ein sinnvoller erster Umfang lässt sich fachlich beschreiben: eine Gruppe bekannter Kunden, klar zuordenbare Artikel, definierte Einheiten und ein bestimmter Weg in das ERP. In diesem Rahmen werden zuerst Vorschläge erzeugt und mit der bisherigen Bearbeitung verglichen. Danach kann die Übertragung unter den vereinbarten Freigaberegeln hinzukommen.

Diese Form der KI-Prozessautomatisierung liefert konkrete Entscheidungen für den weiteren Ausbau. Wenn beispielsweise die meisten Rückfragen aus fehlenden Verpackungseinheiten entstehen, liegt der nächste Arbeitsschritt in den Stammdaten oder im Bestellformat. Ein anderes Sprachmodell löst dieses Problem nicht automatisch.

Für strukturierte Bestellungen aus einem Portal oder einem vorhandenen elektronischen Datenaustausch (EDI) kann der bestehende regelbasierte Import ausreichen. Der Nutzen sprachlicher KI liegt eher bei variierenden Formulierungen und Dokumentlayouts, deren Angaben anschließend überprüft werden können. Die Entscheidung sollte am tatsächlichen Eingangsmaterial hängen.

Für einen Pilot gehören in die Unterlagen: repräsentative Bestellungen einschließlich Ausnahmen, zulässige Kunden- und Artikeldaten, verbindliche Prüfregeln, Rollen, Schnittstellenbeschreibung und fachliche Soll-Ergebnisse. Ein eigener Klärungsweg für offene Vorgänge gehört von Anfang an dazu.

Wie T-NEX einen solchen Ablauf einordnen kann

T-NEX beschreibt Workflow-Automatisierung für Unternehmen als Verbindung von Eingängen, Zuständigkeiten, Freigaben und bestehenden Systemen. Die Dokumenten-KI ergänzt die Erfassung und Prüfung von Angaben aus Dokumenten. Für den hier beschriebenen Fall wären beide Aufgaben gemeinsam mit der konkreten ERP-Schnittstelle zu planen. [4]

Der Musterfall beschreibt einen möglichen Projektumfang. Er belegt keine fertige Standardanbindung an ein bestimmtes ERP und keine bereits erreichte Automatisierungsquote. Vor einer Umsetzung werden die verfügbaren Schnittstellen, benötigten Felder, Rollen und Regeln des Unternehmens geprüft.

Musterfall und Arbeitsunterlagen

Die Unterlagen enthalten die Beispiel-E-Mail, das Bestellblatt, die Feldzuordnung, sieben Entscheidungsregeln und sämtliche 14 Abnahmetests. Die bearbeitbare Arbeitsmappe ergänzt eine Kalkulation mit veränderbaren Annahmen. Die Lesefassung stellt den Fall auch ohne Tabellenkalkulation bereit.

Alle im Fall genannten Preise und Aufwände sind frei gewählte Rechenwerte. Die vorgesehenen Tests stehen auf „Nicht durchgeführt“. Eigene Messwerte, Prüfbelege und Freigaben werden erst bei einer tatsächlichen Erprobung eingetragen.

Fragen aus der Umsetzung

Kann die KI Kundenbestellungen direkt im ERP anlegen?

Eine Anwendung kann nach den vereinbarten Prüfungen einen Auftrag über eine geeignete Schnittstelle anlegen. Voraussetzung sind ein begrenzter Rechteumfang, eindeutige Freigaberegeln und ein Umgang mit Fehlern und Wiederholungen. Im Musterablauf entsteht zunächst ein Vorschlag; eine offene Preisabweichung verhindert die Übertragung.

Was passiert mit handschriftlichen oder schlecht gescannten Bestellungen?

Solche Eingänge gehören in den eigenen Testbestand. Unlesbare Pflichtangaben bleiben ungeklärt und lösen eine Rückfrage aus. Ob die eingesetzte Erkennung diese Dokumente ausreichend verarbeitet, lässt sich nur anhand repräsentativer Beispiele und der tatsächlichen Feldfehler bewerten.

Wie unterscheidet man ein Duplikat von einer Auftragsänderung?

Zunächst werden Kunde und fachliche Bestellreferenz zugeordnet. Anschließend werden die relevanten Inhalte mit der vorhandenen Fassung verglichen. Eine identische Wiederholung wird zugeordnet; geänderte Mengen, Preise oder Empfänger erzeugen einen prüfpflichtigen Änderungsfall. Nachrichtenkennung oder Dateihash allein reichen dafür nicht aus.

Ab welcher Menge lohnt sich die Automatisierung?

Eine feste Anzahl lässt sich ohne Aufwand und Fehlerprofil nicht nennen. Entscheidend sind Zeitgewinn nach Prüfung und Nacharbeit, Ausnahmequote, Schnittstellenaufwand und laufende Kosten. Die beigefügte Kalkulation macht diese Annahmen veränderbar und trennt Kapazitätsgewinn von zahlungswirksamer Einsparung.

Quellen und fachliche Einordnung

Stand der Quellenprüfung: 16. Oktober 2026. Technische Quellen stützen die jeweils bezeichneten Prinzipien. Der Musterprozess, die Entscheidungsregeln und die Rechenannahmen sind redaktionelle Vorschläge. Podcastpassagen werden sinngemäß wiedergegeben; die Übertragung auf den Musterfall ist jeweils als unsere Einordnung erkennbar.

1. Microsoft Learn: Dokumentenerkennung, Konfidenzwerte und fachliche Prüfung. Grundlage für die Einordnung von Erkennungssicherheit und eigenen Prüfgrenzen.
2. Amazon Builders’ Library: Making retries safe with idempotent APIs. Grundlage für wiederholbare Systemaufrufe und eindeutige Anfragekennungen.
3. OWASP Cheat Sheet Series: LLM Prompt Injection Prevention Cheat Sheet. Risiken durch Anweisungen in externen Inhalten und Grenzen der Modellsteuerung.
4. T-NEX: Workflow-Automatisierung und Dokumenten-KI. Anbieterangaben zum Leistungsumfang; die konkrete Umsetzung wird je Vorhaben geprüft.
5. Der Industrie Podcast des VDMA: Struktur schlägt Hype: Der wahre Erfolgsfaktor für KI im Maschinenbau, 14.04.2026. Verwendete Passage mit Christoph Haß: 13:47–15:45. Sinngemäße Wiedergabe auf Grundlage einer Transkription der Episode.
6. DigiCast, Mittelstand-Digital Zentrum Handwerk: Folge 47: 1000 Rechnungen mit KI im Griff - Von der Handarbeit zu Automatisierung, 15.10.2025. Verwendete Passage mit Heiko Süthoff: 20:37–25:35; 31:07–34:27. Sinngemäße Wiedergabe auf Grundlage einer Transkription der Episode.
7. AI FIRST, Felix Schlenther: Agentic AI im ERP: Wie BLP 300 Agenten in Kernprozesse bringt, 14.08.2026. Verwendete Passage mit Tim Beck: 42:07–46:03. Sinngemäße Wiedergabe auf Grundlage einer Transkription der Episode.