E-Mail-Bestellungen automatisch ins ERP übernehmen

In vielen mittelständischen Unternehmen gibt es keinen „sauberen digitalen Bestellkanal”. Es gibt einen Posteingang.

Dort landen Bestellungen nebeneinander:

• als E-Mail mit Freitext
• als PDF-Anhang
• als Excel-Liste
• weitergeleitet aus dem Außendienst
• mit Rückfragen und Änderungen im gleichen Thread
• und nicht selten in Formulierungen, die nur langjährige Mitarbeitende richtig deuten können

Genau deshalb bleibt der Bestelleingang oft manuell. Nicht, weil das Problem unbekannt wäre, sondern weil viele Unternehmen zu Recht skeptisch sind:

Lässt sich so etwas wirklich robust automatisieren – ohne Chaos im ERP zu erzeugen?

Ja. Aber nicht als Zaubertrick, sondern als sauber aufgebauter Prozess mit Validierung, Ausnahmebehandlung und klarer Verantwortung.

Dieser Artikel zeigt Ihnen, wie E-Mail-Bestellungen realistisch ins ERP übernommen werden:

• ohne Big-Bang-Projekt
• ohne Zwang für Ihre Kunden, ihr Bestellverhalten zu ändern
• und ohne die Illusion, dass ab Tag 1 jeder Sonderfall vollautomatisch durchläuft

Er ist der technische Anschluss an den Überblicksartikel Auftragseingang automatisieren im Mittelstand und zeigt konkret, wie der Weg von der Mailbox ins ERP funktioniert.

Woran Sie merken, dass Ihr E-Mail-Bestelleingang zum Engpass geworden ist

Nicht jede manuelle Erfassung ist sofort ein Automatisierungsfall. Kritisch wird es, wenn mehrere dieser Symptome zusammenkommen:

Dann haben Sie kein Personalproblem im engeren Sinn. Dann haben Sie ein Architekturproblem im Bestelleingang.

Warum E-Mail-Bestellungen operativ so teuer werden

Die eigentliche Arbeit beginnt selten beim Tippen. Sie beginnt davor.

Ein Mitarbeiter muss typischerweise:

• prüfen, ob die E-Mail überhaupt eine Bestellung ist
• den richtigen Kunden zuordnen
• relevante Anhänge öffnen
• Artikel und Mengen aus Text oder PDF herauslesen
• kundenspezifische Bezeichnungen auf interne Artikelnummern abgleichen
• Lieferadressen, Wunschtermine und Sonderhinweise prüfen
• Unklarheiten mit Stammdaten oder bestehenden Vorgängen abgleichen
• und erst dann den Auftrag sauber im ERP anlegen

Das Problem ist also nicht nur Dateneingabe. Das Problem ist Kontextarbeit.

Je stärker dieser Prozess auf Einzelwissen beruht, desto teurer und fragiler wird er:

• Urlaubs- und Krankheitsausfälle wirken sofort durch
• neue Mitarbeitende brauchen lange Einarbeitung
• Fehler entstehen oft nicht beim Schreiben, sondern bei der Interpretation
• der Prozess skaliert nur mit zusätzlichem Personal

Wenn täglich viele E-Mail-Bestellungen eingehen, ist das kein reines Backoffice-Thema mehr. Dann ist es ein Architekturthema.

Welche Eingänge sich zuerst eignen – und welche nicht sofort

Nicht jede E-Mail ist gleich gut für einen Einstieg geeignet.

1. Gut automatisierbare Fälle

Dazu zählen zum Beispiel:

• immer ähnliche Bestellmails bestimmter Kunden
• PDFs mit wiederkehrendem Layout
• Excel-Dateien mit stabiler Spaltenstruktur
• E-Mails mit klaren Positionsdaten und bekannten Artikelreferenzen

Das sind fast immer die besten Pilotfälle. Der technische Aufwand bleibt überschaubar und die Trefferquote wird schnell hoch.

2. Automatisierbare Fälle mit Prüfstrecke

Dazu zählen:

• Freitext-E-Mails mit Anhängen
• Kunden mit eigenen Artikelbezeichnungen
• wechselnde PDF-Layouts
• Bestellungen mit Kommentaren, Alternativpositionen oder Sonderwünschen

Auch diese Fälle lassen sich gut abdecken – aber meist nicht ohne Validierung, Freigabe und ein klares Ausnahmemodell.

3. Schwierige Fälle

Dazu zählen:

• schlechte Scans
• Fotos von Bestellzetteln
• E-Mail-Threads mit vielen Rückfragen und Änderungen
• unvollständige Bestellungen ohne klare Mengen, Termine oder Artikelbezüge

Diese Fälle sind kein Grund, das Projekt nicht zu starten. Sie sind nur meist nicht der richtige Startpunkt.

So läuft der Prozess technisch wirklich ab

Wenn jemand sagt: „Wir lesen Bestellungen aus E-Mails aus und schreiben sie ins ERP”, klingt das simpel. In der Praxis besteht ein belastbarer Ablauf aus mehreren Schritten.

1. Mailbox überwachen

Am Anfang steht ein definierter Eingang: ein gemeinsames Bestellpostfach, bestimmte Alias-Adressen oder ein klar abgegrenzter Teil eines bestehenden Shared-Inbox-Setups. Zugegriffen wird je nach Mailsystem über IMAP oder eine API (etwa Microsoft Graph oder Gmail API).

Wichtig ist nicht die Tool-Frage, sondern die Prozessfrage: Wo kommen relevante Bestellungen verlässlich rein?

2. Erkennen, was überhaupt eine Bestellung ist

Nicht jede Nachricht im Posteingang ist ein Auftrag. Das System muss zuerst unterscheiden:

• Bestellung
• Rückfrage
• Änderung zu bestehendem Auftrag
• Reklamation
• interne Weiterleitung

Schon an dieser Stelle wird klar, warum reine „PDF-Extraktion” zu kurz greift. Vor dem Auslesen steht die richtige Einordnung.

3. Inhalte aus E-Mail, PDF oder Excel extrahieren

Je nach Eingang werden Daten aus unterschiedlichen Quellen gelesen: aus dem Mailtext, aus PDF-Anhängen, aus Excel-Dateien, in manchen Fällen aus Bildern oder Scans.

Relevante Felder sind typischerweise:

• Kunde
• Bestellnummer oder Referenz
• Lieferadresse
• Artikel, Bezeichnung, SKU
• Menge und Einheit
• gewünschter Termin
• Hinweise zu Teillieferung, Verpackung oder Kommission

4. Daten normalisieren und auf ERP-Felder mappen

Hier beginnt die eigentliche Systemarbeit. Denn Bestellungen kommen selten in der Form an, in der Ihr ERP sie erwartet. Werte müssen übersetzt werden:

• Kundencode des Kunden → interne Kundennummer
• Kundenartikel → interne Artikelnummer
• freie Mengeneinheit → gültige ERP-Einheit
• abweichende Adressschreibweise → saubere Lieferadresse
• Wunschdatum im Freitext → strukturierter Terminwert

Ohne dieses Mapping entsteht keine Automatisierung, sondern nur ein schönerer Zwischenschritt.

5. Gegen Stammdaten validieren

Ein robuster Prozess prüft vor dem ERP-Eintrag zum Beispiel:

• Ist der Kunde eindeutig?
• Gibt es die Artikel?
• Sind die Mengen plausibel?
• Ist die Einheit zulässig?
• Ist die Lieferadresse bekannt oder freizugeben?
• Passt die Bestellung zu einer bestehenden Preis- oder Konditionslogik?

Das ist der Unterschied zwischen „extrahiert” und „betriebsfähig”.

6. Ausnahmefälle in eine Prüfstrecke legen

Nicht jeder Fall darf automatisch durchlaufen. Gute Lösungen arbeiten deshalb mit einer klaren Ausnahmelogik:

• unklare Kundenzuordnung
• unbekannte Artikel
• fehlende Pflichtfelder
• widersprüchliche Angaben
• schwache Dokumentqualität

Statt solche Fälle still scheitern zu lassen, landen sie in einer Prüfmaske oder Warteschlange. Dort entscheidet ein Mitarbeiter schnell und nachvollziehbar.

7. Auftrag sicher ins ERP übergeben

Erst nach Extraktion, Mapping und Validierung wird der Auftrag ins Zielsystem geschrieben. Je nach ERP geschieht das per:

• API
• Datei-Import
• Middleware
• oder einem gezielten Adapter für ältere Systeme

8. Status, Freigaben und Rückmeldungen dokumentieren

Ein professioneller Prozess braucht Sichtbarkeit:

• Was wurde automatisch übernommen?
• Was musste geprüft werden?
• Wo traten Fehler auf?
• Welche Kundenformate verursachen besonders viele Ausnahmen?

Ohne diese Transparenz kann man den Prozess nicht sauber verbessern – und jeder Ausbau fühlt sich an wie Blindflug.

Was Ihr ERP dafür können muss – API, Import oder Middleware?

Viele Projekte blockieren unnötig an einer Frage:

„Unser ERP hat keine moderne API. Geht das dann überhaupt?”

Oft lautet die Antwort: Ja. Nur nicht immer auf demselben Weg.

API

Die komfortabelste Variante. Sinnvoll, wenn:

• das ERP gut dokumentierte Endpunkte bietet
• Aufträge sauber geschrieben und bestätigt werden können
• Rückmeldungen möglichst in Echtzeit gebraucht werden

Datei-Import

Oft unterschätzt, aber in vielen Mittelstandsprojekten absolut brauchbar. Sinnvoll, wenn:

• CSV-, XML- oder TXT-Importe stabil unterstützt werden
• das Zielsystem keine gute API hat
• der Prozess nicht zwingend in Echtzeit laufen muss

Middleware

Sinnvoll, sobald mehrere Systeme und Formate koordiniert werden müssen, zum Beispiel:

• ERP
• Shared Inbox / Maildienst
• Dokumentenverarbeitung
• Monitoring
• Freigabestrecke
• Auftragsbestätigung oder Folgesysteme

Middleware ist nicht automatisch besser. Aber sie wird oft sinnvoll, wenn mehrere Systeme, Formate und Regeln zusammenspielen müssen.

Individueller Adapter für ältere Systeme

Auch ältere ERP-Systeme lassen sich anbinden, wenn man ihre reale Integrationslogik versteht. Entscheidend ist nicht, ob etwas „modern” klingt, sondern ob der Datenfluss stabil und wartbar bleibt.

Eine tiefere Einordnung zu Kosten und Architekturwahl folgt im eigenen Artikel „ERP-Schnittstelle programmieren lassen” – die Kernfrage beim Bestelleingang ist ohnehin weniger, ob Sie eine API haben, sondern ob der Datenfluss bis in Ihr ERP belastbar wird.

So sieht Ausnahmebehandlung in der Praxis aus

Viele Projekte scheitern nicht an den Standardfällen, sondern an den Fällen, die nicht sauber durchlaufen. Typische Ausnahmen sind:

• ein Kunde verwendet eigene Artikelcodes
• eine Position ist im PDF mehrdeutig
• Mengen fehlen oder sind sprachlich formuliert
• dieselbe Bestellung wurde mehrfach weitergeleitet
• ein gewünschter Liefertermin ist nicht eindeutig
• im Anhang steckt ein Scan in schlechter Qualität
• der Kunde bestellt ein Produkt, das intern nur als Variante existiert

Der richtige Umgang damit ist nicht: „Dann machen wir eben alles manuell.” Der richtige Umgang ist:

• eindeutige Fälle automatisieren
• unklare Fälle strukturiert aussteuern
• Entscheidungen nachvollziehbar speichern
• aus wiederkehrenden Ausnahmen neue Regeln ableiten

Genau hier entsteht der wirtschaftliche Effekt. Nicht durch den Anspruch auf 100 Prozent Dunkelverarbeitung, sondern durch einen hohen Automatisierungsgrad bei kontrolliertem Risiko.

Ein realistischer Pilot sieht anders aus als ein Großprojekt

In vielen Mittelstandsprojekten ist dieser Weg realistischer als eine Komplettautomatisierung ab Tag 1:

Das Entscheidende: Sie müssen nicht alle Kundenformate gleichzeitig lösen. Sie müssen nur mit den Formaten anfangen, bei denen Volumen, Wiederholbarkeit und Klarheit hoch genug sind, damit der Pilot echte Zahlen liefert statt Demo-Screenshots.

Was Sie vor dem Start klären sollten

Bevor Sie E-Mail-Bestellungen automatisieren, sollten diese Punkte sauber beantwortet sein:

Gibt es ein klares Bestellpostfach?

Wenn Bestellungen über zehn persönliche Postfächer verteilt eingehen, ist Automatisierung unnötig schwer. Ein definierter Eingang ist kein Komfortthema, sondern eine Voraussetzung.

Sind Kunden- und Artikelstammdaten belastbar?

Automatisierung kann Zuordnungen erleichtern. Sie ersetzt aber keine dauerhaft chaotischen Stammdaten. Wenn ein Kunde fünf Schreibweisen hat und Artikelnummern historisch „so ungefähr” verwendet werden, wird der Prozess nicht stabil.

Wer entscheidet bei Ausnahmen?

Wenn unklar ist, wer fehlerhafte oder unvollständige Bestellungen prüft, verlagern Sie das Problem nur – statt es zu lösen.

Welche Rückmeldung soll ausgelöst werden?

Soll direkt eine Auftragsbestätigung rausgehen? Erst nach Freigabe? Oder nur bei eindeutigem Durchlauf? Diese Frage gehört in die Architektur, nicht erst in den Betrieb.

Wo lohnt der Einstieg wirtschaftlich zuerst?

Nicht immer dort, wo die meisten Beschwerden entstehen. Oft dort, wo Volumen, Wiederholbarkeit und Klarheit am höchsten sind.

Welche Fehler Sie vermeiden sollten

Fazit

E-Mail-Bestellungen automatisiert ins ERP zu übernehmen heißt nicht, alle Kunden zu einem neuen Bestellportal zu zwingen.

Es heißt zuerst:

• einen klaren Eingang definieren
• eindeutige Formate pilotieren
• Inhalte sauber auf Stammdaten mappen
• Ausnahmen kontrolliert behandeln
• und erst dort komplexere Technik einsetzen, wo sie nachweislich etwas verbessert

Der Mittelstand braucht dafür selten ein neues ERP oder ein millionenschweres Transformationsprojekt. Er braucht einen belastbaren Datenfluss zwischen Posteingang und bestehendem System – und die Bereitschaft, klein und realistisch zu starten.

FAQ zu E-Mail-Bestellungen ins ERP