Agentic Order Intake: B2B-Bestellungen aus E-Mail, PDF und Excel für ERP-Systeme vorbereiten

B2B-Bestellungen kommen selten in genau dem Format an, das ein ERP-System für eine saubere Weiterverarbeitung braucht. Ein Kunde schickt eine PDF-Bestellung per E-Mail, ein anderer exportiert Excel-Dateien aus dem eigenen Einkaufssystem. Dazu kommen CSV-Exporte, EDI-Nachrichten, Portale und individuelle APIs.

Agentic Order Intake beschreibt einen neuen Ansatz für diesen fragmentierten Bestelleingang: AI-Agenten helfen dabei, Bestellungen aus unstrukturierten, teilstrukturierten und anders strukturierten Quellen in ein einheitliches, maschinenlesbares Datenmodell zu überführen. Entscheidend ist dabei nicht nur das Auslesen einzelner Felder. Der eigentliche Hebel liegt im Strukturieren, Normalisieren, Anreichern, Mapping und in der kontrollierten Übergabe an bestehende ERP-Systeme. Dafür ist gutes Data Handling nötig, nicht nur Texterkennung oder klassische Automatisierung. 

Inhaltsverzeichnis:

• Der Offline-to-Order-Engpass: warum viele B2B-Bestellungen von Hand im ERP landen
• Was ist Agentic Order Intake, und wie unterscheidet er sich von OCR und EDI?
• Aus Bestellformaten werden maschinenlesbare Datenobjekte
• Welche Aufgaben übernehmen AI-Agenten im Bestelleingang?
• Strukturierung, Plausibilisierung und Validierung sind drei verschiedene Dinge
• Human Review verhindert Black-Box-Automatisierung
• ERP-neutral arbeiten: Die Zwischenschicht ist der eigentliche Hebel
• Gutes Data Handling entscheidet über die Qualität der Agenten
• Agentic Order Intake bereitet Agentic Commerce vor
• So kann ein Pilot für Agentic Order Intake aussehen
• Welche Kennzahlen zeigen Fortschritt?

Der Offline-to-Order-Engpass: warum viele B2B-Bestellungen von Hand im ERP landen

Der digitale Bestellprozess wächst, trotzdem läuft ein großer Teil der B2B-Bestellungen weiter über persönliche Kanäle. Laut McKinsey verteilt sich der B2B-Vertrieb etwa zu gleichen Teilen auf Vor-Ort-Kontakt, Remote-Kontakt und digitale Selbstbedienung. Nur rund ein Drittel der Kaufinteraktionen läuft damit über echte Selbstbedienung im Portal, der Rest über Menschen: Telefon, E-Mail, Außendienst.

Im B2B ist der Bestellkanal oft historisch gewachsen. Ein großer Kunde sendet seit Jahren seine PDF-Bestellung per E-Mail. Ein anderer exportiert wöchentlich eine Excel-Datei aus dem eigenen Einkaufssystem. Wieder andere Kunden nutzen EDI, Portale oder eigene Schnittstellen.

Auf den ersten Blick wirken diese Kanäle sehr unterschiedlich. In der Praxis haben sie aber dasselbe Problem: Die Bestellung liegt häufig nicht in der Struktur vor, die dein Zielsystem erwartet.

Das gilt nicht nur für Freitext-E-Mails oder gescannte PDFs. Auch EDI, CSV oder Excel können sauber strukturiert sein und trotzdem nicht zum internen Datenmodell passen. Feldnamen, Artikelnummern, Mengeneinheiten, Lieferadressen oder Kundenreferenzen folgen oft der Logik des sendenden Systems, nicht der Logik deines ERP.

Die Folge: Teams im Innendienst lesen, prüfen, suchen, kopieren, korrigieren und übertragen. Sie übernehmen damit Aufgaben, die eigentlich datengetrieben gelöst werden sollten.

Was ist Agentic Order Intake, und wie unterscheidet er sich von OCR und EDI?

Agentic Order Intake beschreibt den Einsatz von AI-Agenten im Bestelleingang. Diese Agenten erfassen Bestellungen aus verschiedenen Kanälen, interpretieren Inhalte, strukturieren Daten und bereiten sie für die Weiterverarbeitung in Zielsystemen vor.

Der Begriff ist bewusst breiter als OCR oder klassische Automatisierung. OCR erkennt Text. Agentic Order Intake arbeitet mit Kontext. Ein moderner Order-Intake-Prozess beantwortet deshalb nicht nur die Frage, was auf einem Dokument steht. Er prüft auch, ob es sich wirklich um eine Bestellung handelt, welche Zeilen echte Positionen sind, welche Kundenartikelnummer zu welcher internen Artikelnummer gehört und welche Felder für die Übergabe an das Zielsystem fehlen.

Warum OCR nur ein Baustein ist

Viele Automatisierungsprojekte starten trotzdem mit derselben Frage: Wie lassen sich PDFs automatisch auslesen? Das ist nachvollziehbar, greift aber zu kurz. Eine Bestellung ist mehr als Text auf einem Dokument. Sie ist ein Geschäftsobjekt mit Beziehungen zu Kunde, Artikel, Menge, Lieferadresse, Verfügbarkeit und Zielsystem.

Ein Beispiel: Ein Kunde schreibt in einer PDF-Bestellung:

„12 Kartons Filtermatten F7, wie zuletzt, Lieferung bitte an Werk 2.“

OCR kann diesen Satz lesbar machen. Für die Weiterverarbeitung reicht das nicht. Das System muss verstehen, welcher Kunde bestellt, welche interne Artikelnummer gemeint ist, wie viele Stück in einem Karton enthalten sind, welche Lieferadresse hinter „Werk 2“ steckt und ob „wie zuletzt“ auf eine frühere Bestellung verweist.

EDI liefert hochstrukturierte Daten, aber nur mit ERP-Anbindung

EDI löst das Strukturproblem an anderer Stelle. Zwei Systeme tauschen Bestellungen über einen festen Standard aus, zuverlässig und automatisiert. EDI-Nachrichten sind hochstrukturiert, greifen aber nur bei Partnern, die angebunden sind und den vereinbarten Standard sauber liefern. Viele kleinere und mittlere Kunden bestellen weiter per E-Mail, PDF oder Excel. Genau dort entsteht der manuelle Aufwand.

Agentic Order Intake ergänzt beide Ansätze. AI-Agenten können Freitext, PDFs, Excel-Dateien, CSVs oder EDI-Abweichungen in ein gemeinsames Order-Datenmodell überführen. Sie schlagen Mappings gegen Katalog, Stammdaten oder Regeln vor und prüfen, was sich aus verfügbaren Referenzdaten ableiten lässt. Konditionen, Bestände oder Sperrkennzeichen lassen sich erst dann sicher prüfen, wenn die entsprechenden Daten angebunden sind.

So entsteht aus verschiedenen Eingangsformaten kein fertiger Auftrag auf Knopfdruck, sondern ein strukturierter Auftragsvorschlag. Dieser Vorschlag kann automatisch weiterlaufen, in eine manuelle Prüfung gehen oder eine Rückfrage auslösen.

Aus Bestellformaten werden maschinenlesbare Datenobjekte

Der Kern von Agentic Order Intake ist ein neutrales Order-Datenmodell. Dieses Modell bildet die Bestellung so ab, dass sie unabhängig vom Eingangskanal weiterverarbeitet werden kann.

Dabei geht es nicht darum, aus jeder Nachricht sofort einen fertigen ERP-Auftrag zu machen. Das wäre in vielen Umgebungen fachlich zu weit gegriffen. Ohne Zugriff auf ERP-Daten wie Kundenstamm, Artikelstamm, Konditionen, Sperrkennzeichen oder Bestände kann eine Middleware keine vollständige ERP-Validierung leisten.

Realistischer und sauberer ist dieses Ziel:

Bestellungen werden strukturiert, normalisiert, angereichert, plausibilisiert und für die Übergabe an bestehende ERP-Systeme vorbereitet.

Ein solches Datenmodell kann zum Beispiel so aussehen:

Dieses Modell ist die Werkbank für den weiteren Prozess. Erst wenn die Daten darin sauber liegen, lassen sich Regeln anwenden, Mappings pflegen, Rückfragen auslösen oder Zielsysteme bedienen.

Welche Aufgaben übernehmen AI-Agenten im Bestelleingang?

AI-Agenten können im Order Intake verschiedene Rollen übernehmen. Entscheidend ist, dass sie nicht isoliert arbeiten. Sie greifen auf Dokumente, Mappings, Regeln, Referenzdaten und Review-Entscheidungen zu.

Intake-Agent: Was ist eingegangen?

Der Intake-Agent klassifiziert den Eingang. Er erkennt Kanal, Format und Absicht. Eine E-Mail kann eine Bestellung enthalten, aber auch eine Auftragsänderung, Rückfrage, Reklamation oder Dublette sein. Der Agent schafft die erste Ordnung im Eingangsstrom.

Extraction-Agent: Welche Informationen stehen in der Bestellung?

Der Extraction-Agent liest relevante Informationen aus dem Eingang aus. Dazu gehören Bestellnummer, Kundensignale, Lieferadresse, Positionen, Mengen, Einheiten, Artikelbeschreibungen, gewünschte Liefertermine und Hinweise. Wichtig ist dabei nicht nur der erkannte Wert, sondern auch die Feldsicherheit. Ein eindeutig erkanntes Datum ist anders zu behandeln als ein unscharfer Freitext.

Normalisierungs-Agent: Wie werden Daten vergleichbar?

Der Normalisierungs-Agent bringt Inhalte in ein einheitliches Format. Datumswerte, Währungen, Mengeneinheiten, Schreibweisen und Adressen werden bereinigt. Aus „KW 35“, „Ende August“ oder „Lieferung nächste Woche“ wird ein interpretierbarer Lieferzeitraum.

Mapping-Agent: Wie wird Kundensprache in Systemsprache übersetzt?

Der Mapping-Agent ist einer der wichtigsten Bausteine. Er übersetzt externe Bestelllogik in interne Systemlogik. Kundenartikelnummern werden internen Artikelnummern zugeordnet, Firmennamen einer Kundennummer, E-Mail-Domains einem Kundenkonto und Excel-Spalten passenden Zielfeldern. Gerade im B2B ist dieses Mapping oft der eigentliche Engpass.

Plausibilisierungs-Agent: Was kann vorab geprüft werden?

Der Plausibilisierungs-Agent prüft, ob die Bestellung formal und logisch weiterverarbeitet werden kann.

Sind Pflichtfelder vorhanden? Gibt es mindestens eine Position? Sind Mengen erkennbar? Ist der Confidence Score ausreichend? Für fachliche Prüfungen gegen Preise, Bestände oder Sperrkennzeichen braucht das System angebundene Referenzdaten.

Routing-Agent: Was passiert als Nächstes?

Der Routing-Agent entscheidet, welchen Weg ein Vorgang nimmt.

In der Praxis reichen meist vier Wege: Übergabe an das Zielsystem, Human Review, Rückfrage oder Ablehnung. Eine klare Bestellung läuft weiter. Ein unsicheres Artikelmapping landet im Review. Eine fehlende Lieferadresse löst eine Rückfrage aus. Eine Dublette wird protokolliert und gestoppt.

Strukturierung, Plausibilisierung und Validierung sind drei verschiedene Dinge

Im Auftragseingang werden diese Begriffe oft vermischt. Für eine tragfähige Architektur müssen sie getrennt werden.

Strukturierung bedeutet: Daten aus verschiedenen Quellen werden in ein einheitliches Modell gebracht. Aus E-Mail, PDF, Excel, CSV oder EDI entsteht ein Order-Objekt mit klaren Feldern.

Plausibilisierung bedeutet: Das System prüft, ob die Daten formal und logisch sinnvoll wirken. Fehlen Pflichtfelder? Sind Mengen erkennbar? Ist das Datum interpretierbar? Gibt es Widersprüche?

Validierung bedeutet: Die Daten werden gegen fachliche Referenzdaten geprüft. Dafür braucht das System Zugriff auf Kundenstamm, Artikelstamm, Konditionen, Bestände oder ERP-Regeln.

Diese Trennung schützt vor falschen Erwartungen. Agentic Order Intake kann schon ohne tiefe ERP-Integration viel leisten. Der Prozess wird aber stärker, sobald Referenzdaten angebunden sind.

Praxis-Tipp: Definiere für deinen Bestelleingang drei Prüfklassen. Klasse A bedient eine formale Prüfung ohne Referenzdaten. Klasse B prüft mit angebundenen Stammdaten. Klasse C ist eine ERP-nahe Prüfung mit Preis-, Bestands- und Geschäftslogik.

So kannst du klar entscheiden, welche Vorgänge automatisiert weiterlaufen und welche bewusst geprüft werden.

Human Review verhindert Black-Box-Automatisierung

Agentic Order Intake sollte nicht bedeuten, dass jede Bestellung blind an das ERP übergeben wird. Im B2B sind die Folgekosten falscher Aufträge zu hoch.

Ein guter Review-Prozess verändert die Rolle des Menschen. Beschäftigte im Innendienst tippen Standardaufträge nicht mehr vollständig ab. Sie prüfen Ausnahmen, bestätigen Vorschläge und klären Fälle, bei denen der Agent keine ausreichende Sicherheit hat.

Der Review sollte zeigen:

• welche Felder extrahiert wurden
• welche Felder unsicher sind
• welche Mapping-Kandidaten geprüft wurden
• warum der Agent den Vorgang nicht automatisch weitergeben will
• welche Aktion empfohlen wird
• welche Entscheidung zuletzt getroffen wurde

Das ist ein zentraler Vertrauenshebel. Gerade im Mittelstand zählt nicht nur Automatisierung, sondern Nachvollziehbarkeit.

ERP-neutral arbeiten: Die Zwischenschicht ist der eigentliche Hebel

Viele Unternehmen wollen ihr ERP nicht ersetzen. Das ist auch nicht nötig. Das ERP bleibt das Rückgrat für Auftragsanlage, Bestandsführung, Rechnungsstellung, Konditionen und Logistikprozesse.

Das Problem liegt häufig davor. Bestellungen erreichen das Unternehmen in Formaten, die für das ERP nicht direkt verarbeitbar sind.

Eine Agentic-Order-Intake-Middleware sitzt genau zwischen diesen Ebenen:

Der Vorteil dieser Architektur liegt in der Entkopplung. Jeder neue Eingangskanal muss nicht direkt an jedes Zielsystem angebunden werden. Stattdessen laufen Bestellungen zunächst durch ein gemeinsames Datenmodell, werden dort strukturiert und dann passend an das Zielsystem übergeben.

So entsteht kein weiterer Integrationskleber zwischen einzelnen Systemen. Es entsteht eine steuerbare Datendrehscheibe für den Bestelleingang.

Gutes Data Handling entscheidet über die Qualität der Agenten

AI-Agenten wirken schnell beeindruckend, wenn sie aus einem PDF einzelne Felder erkennen. Im produktiven Betrieb entscheidet aber die Datenbasis.

Ohne saubere Mappings entstehen falsche Artikel. Ohne stabile Referenzdaten entstehen unsichere Kundenzuordnungen. Ohne klare Regeln landen zu viele Vorgänge im Review. Ohne Audit Log fehlt die Nachvollziehbarkeit.

Der Schlüssel liegt in gutem Data Handling:

• ein belastbares Order-Datenmodell
• gepflegte Feldmappings
• klare Eigentümerschaft für Referenzdaten
• nachvollziehbare Transformationsregeln
• Confidence Scores je Feld
• Review-Entscheidungen als Lernsignal
• Versionierung von Regeln und Mappings
• Protokollierung jeder Übergabe

AI ist in diesem Prozess kein Ersatz für Datenarchitektur. Sie arbeitet auf der Datenarchitektur.

Agentic Order Intake bereitet Agentic Commerce vor

Agentic Commerce beschreibt Szenarien, in denen digitale Agenten stärker an Einkaufs- und Verkaufsprozessen teilnehmen. Auf Kundenseite könnten Einkaufsagenten künftig Produktdaten, Preise, Verfügbarkeiten und Konditionen abfragen. Auf Lieferantenseite müssen Systeme solche Anfragen verstehen, beantworten und in Folgeprozesse überführen.

Dafür reichen PDFs, Freitext und manuelle Klärungen nicht aus. Systeme brauchen maschinenlesbare Datenobjekte, klare Schnittstellen und nachvollziehbare Regeln.

Agentic Order Intake ist ein pragmatischer Zwischenschritt. Bestehende Bestellkanäle müssen nicht sofort verschwinden. Sie werden schrittweise in maschinenlesbare Prozesse überführt. Der PDF-Anhang bleibt für den Kunden möglich. Intern entsteht daraus aber ein strukturiertes Datenobjekt, das geprüft, gemappt, angereichert und an Zielsysteme übergeben werden kann. 

Ob Mensch, Einkaufssystem oder AI-Agent bestellt, die Anforderungen an die empfangende Seite bleiben ähnlich: Daten müssen eindeutig, anschlussfähig und erklärbar sein.

So kann ein Pilot für Agentic Order Intake aussehen

Ein guter Einstieg beginnt nicht mit dem schwierigsten Sonderfall. Starte mit wiederkehrenden Bestellungen, bekannten Kunden und Formaten, die häufig genug vorkommen.

Ein sinnvoller Pilot kann so aufgebaut sein:

1. Bestelleingänge sichten und Kanäle clustern
   Welche Bestellungen kommen per E-Mail, PDF, Excel, CSV, EDI oder Portal?
2. Wiederkehrende Muster erkennen
   Welche Kunden, Formate und Positionstypen kommen regelmäßig vor?
3. Ziel-Datenmodell definieren
   Welche Felder braucht dein ERP oder Zielsystem für die Weiterverarbeitung?
4. Mappings aufbauen
   Welche Kundenartikelnummern, Einheiten, Adressen und Feldnamen müssen übersetzt werden?
5. Prüfklassen festlegen
   Was kann formal geprüft werden, was braucht Referenzdaten, was muss im ERP validiert werden?
6. Human Review gestalten
   Welche Unsicherheiten sollen Menschen prüfen, bevor Daten weitergegeben werden?
7. Übergabe stabilisieren
   Welche Zielsysteme erhalten welche Daten, in welchem Format und mit welchem Status?

Praxis-Tipp: Beginne mit einem kontrollierten Teilprozess. Lieber einige gut verstandene Formate sauber verarbeiten als alle Kanäle gleichzeitig abdecken.

Welche Kennzahlen zeigen Fortschritt?

Agentic Order Intake sollte messbar eingeführt werden. Dafür brauchst du Kennzahlen, die nicht nur Automatisierung, sondern auch Qualität und Kontrollaufwand abbilden.

Geeignete KPIs sind:

• Anteil automatisch vorbereiteter Bestellungen
• Anteil der Vorgänge mit Human Review
• Anteil der Rückfragen an Kunden oder Vertrieb
• durchschnittliche Zeit vom Eingang bis zur Zielsystemübergabe
• Trefferquote beim Kundenmapping
• Trefferquote beim Artikelmapping
• Anteil fehlender Pflichtfelder
• Fehlerquote bei Zielsystemübergaben
• Anteil der Dubletten oder nicht verarbeitbaren Eingänge

Hublify als neutrale Daten- und Mapping-Schicht 

Hublify passt in diesen Kontext zuerst als neutrale Daten- und Mapping-Schicht zwischen Bestellkanälen und Zielsystemen. Bestellungen aus E-Mail, PDF, Excel, EDI, Portalen oder APIs können in ein einheitliches Datenmodell überführt werden. Danach lassen sie sich normalisieren, anreichern, mappen, plausibilisieren und kontrolliert an bestehende ERP-Systeme oder Schnittstellen übergeben.

Der Vorteil liegt im Einstieg: Bestehende Systeme bleiben erhalten. Unternehmen müssen ihr ERP nicht sofort austauschen und Kunden nicht auf neue Bestellkanäle zwingen. Der Bestelleingang wird zuerst dort geordnet, wo die Reibung entsteht.

Der größere Hebel entsteht, wenn dieselbe Plattform später auch Zielsystem für einzelne Daten- und Prozessbereiche werden kann. Dann müssen Bestelldaten nicht nur von einem Format in ein anderes übersetzt werden. Sie können Schritt für Schritt in einer Umgebung weiterverarbeitet werden, die Produktdaten, Kundendaten, Bestände und Auftragslogik zusammenführt.

Mit Hublify PIM, Hublify Order Management, Hublify CDM oder Hublify Warehouse lassen sich solche Bausteine gezielt ergänzen. Produktdaten können im PIM gepflegt werden. Kundendaten lassen sich im CDM strukturieren. Lager- und Bestandsprozesse können über Hublify Warehouse laufen. Bestellungen können im Hublify Order Management weiterverarbeitet werden, wenn dieser Schritt zum Prozess passt.

So bleibt der erste Schritt klein, aber der Ausbaupfad offen. Hublify kann zunächst Fugenkitt zwischen gewachsenen Bestellkanälen und bestehenden ERP-Prozessen sein. Mit zunehmender Reife kann daraus ein gemeinsames Datenfundament für weitere B2B-Prozesse entstehen.

Lass uns gerne darüber sprechen. Lass dir Hublify zeigen!