Dunkelverarbeitung im Bestelleingang – warum 100 % nicht der Startpunkt sind

Dunkelverarbeitung klingt nach dem perfekten Ziel: Bestellungen kommen per E-Mail, PDF, Excel, Portal oder EDI rein, das System erkennt, prüft, ordnet zu, legt den Auftrag im ERP an. Niemand tippt mehr ab. Keine Rückfragen. Keine Warteschlange im Innendienst.

Das funktioniert. Bis es nicht mehr funktioniert.

Sobald ein Kunde mit alter Artikelnummer bestellt, ein Preis vom Vertrag abweicht, eine Lieferadresse fehlt oder ein Freitext eine Sonderanforderung enthält, entscheidet sich, ob die Automatisierung kontrolliert oder blind läuft. Wer hier sofort „alles dunkel" verarbeiten will, baut ein schnelles, aber riskantes System – und der Fehler landet direkt im ERP.

Die richtige Frage lautet deshalb nicht „Wie automatisieren wir 100 %?", sondern: Welche Bestellungen können wir sicher automatisieren – und welche müssen sichtbar geprüft werden?

Was Dunkelverarbeitung im Bestelleingang wirklich heißt

Dunkelverarbeitung bedeutet, dass eine Bestellung ohne manuellen Eingriff vollständig durchläuft: Daten erkennen, Kunde, Artikel, Preise, Mengen und Lieferinformationen prüfen, Auftrag ins ERP übergeben, Status dokumentieren. Nur Abweichungen erzeugen einen Prüffall.

„Im Dunkeln" heißt nicht unsichtbar. Im Gegenteil – gute Dunkelverarbeitung braucht mehr Transparenz als manuelle Bearbeitung. Wenn kein Mensch jede Bestellung ansieht, muss das System für jede Entscheidung beantworten können: Warum wurde diese Bestellung automatisch verarbeitet? Welche Daten wurden übernommen? Welche Regeln wurden geprüft? Welche Unsicherheiten gab es? Warum wurde ein anderer Auftrag angehalten?

Das ist nicht „KI liest Bestellungen". Das ist das Zusammenspiel aus Datenerfassung, Extraktion, Stammdatenabgleich, Mapping, Geschäftsregeln, Validierung, ERP-Übergabe, Protokollierung, Ausnahmebehandlung und Monitoring. Erst wenn diese Bausteine zusammenpassen, läuft ein Bestellvorgang wirklich ohne manuellen Eingriff.

Woran Sie merken, dass „100 %" das falsche Ziel ist

Nicht jede manuelle Tätigkeit im Bestelleingang ist sofort ein Automatisierungsfall – und nicht jede automatische Verarbeitung ist sofort eine sichere. Diese Symptome treten häufig zusammen auf:

Wenn mehrere davon zutreffen, ist der Engpass nicht eine fehlende Funktion. Er ist die fehlende Trennung zwischen sicheren und unsicheren Fällen.

Warum die letzten 20 % oft teurer sind als die ersten 80 %

Die ersten Automatisierungserfolge kommen aus wiederkehrenden, sauberen Fällen: Stammkunden mit bekannten Bestellformaten, klaren Mengenangaben, vollständigen Lieferadressen, gültigen Preisen. Diese Fälle lassen sich gut automatisieren.

Schwierig wird es bei Ausnahmen – Kunde mit alter Artikelnummer, fehlende Einheit, abweichender Preis, gesperrter Artikel, unvollständige Adresse, Position nur im Freitext, schlecht gescanntes PDF, gemischte Bestellung aus aktuellem und altem Sortiment, Sonderkonditionen, die nicht sauber im ERP gepflegt sind.

Wer diese Fälle sofort vollständig automatisieren will, kämpft an drei Stellen gleichzeitig.

Die Lösung wird unnötig komplex. Regeln, Workarounds und Sonderlogik wachsen schneller als das System wartbar bleibt. Nach einem halben Jahr kann niemand mehr erklären, warum eine bestimmte Bestellung so verarbeitet wurde, wie sie verarbeitet wurde.

Fehler werden direkt ins ERP übertragen. Manuelle Arbeit ist langsam, hat aber den Vorteil, dass Menschen offensichtliche Probleme erkennen, bevor sie im ERP landen. Eine schlecht geplante Automatisierung überspringt genau diese Schutzschicht. Ein falsches Mapping kann viele Aufträge betreffen, ein falsch interpretierter Preis kann wiederholt übernommen werden, eine fehlende Prüfung kann unbemerkt tausende Datensätze erzeugen. Ich habe das schon gesehen – einmal so eingerichtet, fällt es Wochen später bei einer Mahnung auf.

Die Organisation verliert Vertrauen. Wenn ein System zu früh zu viel automatisch macht, kontrolliert der Innendienst wieder alles manuell nach, Fachbereiche fordern zusätzliche Freigaben, das Projekt wird intern als „zu riskant" abgestempelt. Die Quote sinkt nicht offiziell – aber die Doppelarbeit dahinter steigt.

Ein sauberer Einstieg mit klarer Prüfstrecke erzeugt das Gegenteil: sichere Fälle laufen automatisch, unsichere Fälle bleiben sichtbar, das Team sieht warum, und Vertrauen wächst Schritt für Schritt.

Dunkelverarbeitung ist deshalb kein Schalter. Sie ist ein Reifegrad.

Drei Zonen statt zweier Schubladen: Grün, Gelb, Rot

Statt Bestellungen nur in „automatisch" und „manuell" einzuteilen, bringt ein Drei-Zonen-Modell mehr Klarheit.

Grün – automatisch verarbeiten. Kunde eindeutig erkannt, Bestellformat bekannt, Artikel sauber gemappt, Preise und Konditionen plausibel, Lieferadresse vollständig, keine Sperren, Auftragswert im erlaubten Bereich. Diese Fälle gehen ohne Eingriff ins ERP.

Gelb – vorbereiten und entscheiden lassen. Eine Position ist unklar, eine Kundenartikelnummer fehlt im Mapping, eine Preisabweichung liegt außerhalb der Toleranz, ein Lieferdatum ist ungewöhnlich, ein Freitext enthält eine mögliche Sonderanforderung. Das System bereitet den Auftrag auf, der Mitarbeitende entscheidet gezielt – nicht mehr „erfassen", sondern „freigeben oder korrigieren".

Rot – blockieren oder manuell bearbeiten. Kunde unbekannt, Dokument unlesbar, mehrere mögliche Debitoren, Dublettenverdacht, ungewöhnlich hoher Auftragswert, Exportprüfung erforderlich, Pflichtinformationen fehlen. Rot heißt nicht, dass die Automatisierung versagt hat. Rot heißt, dass das System verhindert hat, dass ein riskanter Vorgang automatisch ins ERP gelangt. Das ist ein Erfolg.

Zone	Entscheidung	Ziel
Grün	automatisch buchen	maximale Entlastung bei sicheren Fällen
Gelb	vorbereiten und prüfen	gezielte Klärung statt vollständiger Erfassung
Rot	blockieren oder manuell bearbeiten	Schutz vor falschen ERP-Aufträgen

Die Trennlinie zwischen den Zonen ist eine fachliche Entscheidung, keine technische. Wer sie nicht bewusst zieht, lässt das Tool entscheiden – und das endet selten gut.

Welche Bestellungen sich für Dunkelverarbeitung eignen

Nicht jede Bestellung hat dasselbe Automatisierungspotenzial. Geeignet sind Fälle, die fachlich stabil, wiederkehrend und eindeutig sind.

Wiederkehrende Kunden mit bekannten Formaten

Wenn ein Kunde regelmäßig in einem ähnlichen Format bestellt, kann das System viel lernen oder regelbasiert erkennen: Excel-Bestellliste mit festen Spalten, PDF aus demselben Kunden-ERP, E-Mail mit wiederkehrender Struktur, EDI-Datei mit stabilem Format, Portalbestellung mit Login und Kundenzuordnung. Je stabiler das Format, desto realistischer die Dunkelverarbeitung.

Eindeutige Artikelzuordnung

Die Zuordnung kann über interne Artikelnummer, Kundenartikelnummer plus Kunde, EAN/GTIN, Herstellerartikelnummer oder ein gepflegtes Mapping mit Ersatzartikel laufen. Wichtig: Sie darf nicht nur ungefähr passen. Für eine automatische ERP-Übergabe muss sie fachlich sicher sein. Wie diese Übersetzungsschicht in der Praxis aussieht, ist im Artikel Kundenartikelnummern automatisch zuordnen beschrieben.

Gültige Preise und Konditionen

B2B-Preise sind selten so einfach wie in einem Onlineshop: kundenspezifische Preislisten, Staffelpreise, Rahmenverträge, Rabattgruppen, Aktionspreise, Mindestmengen, Zuschläge. Dunkelverarbeitung funktioniert nur, wenn diese Logik sauber geprüft werden kann. In den meisten Fällen sollte das ERP führend sein: Das System übergibt Auftrag und Positionen, das ERP berechnet Preis und Verfügbarkeit, Abweichungen werden zurückgemeldet.

Klare Liefer- und Rechnungsinformationen

Eine Bestellung ist nicht nur eine Liste von Artikeln. Für die automatische Verarbeitung braucht es eindeutigen Kunden, Bestellnummer, Lieferadresse, gewünschtes Lieferdatum, Rechnungsadresse, ggf. Ansprechpartner oder Kostenstelle, Versandart und Steuerlogik. Fehlt davon etwas, ist meist ein Prüffall der bessere Weg.

Geringes fachliches Risiko

Selbst wenn die Daten technisch lesbar sind, gehört nicht jede Bestellung in die automatische Strecke: sehr hohe Auftragswerte, neue Kunden, abweichende Lieferadressen, Export- und Zollthemen, Gefahrgut, projektspezifische Artikel, kundenspezifische Fertigung, Preisabweichungen, gesperrte Kunden, ungewöhnliche Mengen. Das System kann diese Fälle vorbereiten – die finale Freigabe gehört aber an den Fachbereich.

Welche Fälle in die Prüfstrecke gehören – und wie sie aussehen müssen

Eine Prüfstrecke ist kein Zeichen schlechter Automatisierung. Sie ist der Sicherheitsmechanismus, der Automatisierung überhaupt skalierbar macht.

In die Prüfstrecke gehört alles, was nicht sicher genug entschieden werden kann: Kunde nicht eindeutig, Bestellnummer fehlt, Artikelnummer unbekannt, Kundenartikelnummer nicht gemappt, Beschreibung passt nicht zur Artikelnummer, Einheit fehlt oder weicht ab, Menge unplausibel, Preis weicht stark ab, Lieferadresse unvollständig, Lieferdatum außerhalb üblicher Regeln, Artikel gesperrt oder ausgelaufen, Mindestbestellmenge unterschritten, Bonitäts- oder Sperrkennzeichen aktiv, Dublettenverdacht, schlechte Dokumentqualität, Pflichtanhang fehlt, Sonderhinweis im Freitext.

Entscheidend ist die Form, in der ein Prüffall beim Mitarbeitenden ankommt. Eine Fehlermeldung allein ist keine Prüfstrecke. Sie ist eine versteckte Erfassungsaufgabe.

Nicht hilfreich:

„Fehler Artikelnummer."

Hilfreich:

„Kundenartikelnummer 4711 wurde für Kunde ABC nicht gefunden. Ähnliche Treffer: interner Artikel A-4711, A-4712. Einheit im Dokument: Karton. Letzte Bestellung des Kunden enthielt A-4711 mit Einheit Karton. Bitte zuordnen oder blockieren."

So wird aus einer technischen Ausnahme eine fachlich lösbare Aufgabe – mit erkannten Daten, unsicheren Daten, konkreter Ursache, Vorschlägen, Originaldokument, Entscheidungsmöglichkeiten und der Option, die Korrektur als Mapping für nächste Fälle zu speichern. Genau dieser letzte Punkt entscheidet darüber, ob die Quote über die Zeit steigt oder konstant bleibt.

Warum Datenqualität wichtiger ist als KI

Diskussionen über Dunkelverarbeitung landen schnell bei KI. Sie kann beim Auslesen von PDFs helfen, Tabellen erkennen, Dokumente klassifizieren, Artikelzuordnungen vorschlagen, Freitext interpretieren, Bestellmuster erkennen.

Aber KI löst keine schlechten ERP-Daten.

Wenn Artikelstammdaten veraltet sind, Kunden mehrfach angelegt wurden, Preislisten widersprüchlich sind oder Kundenartikelnummern nur in Excel-Dateien einzelner Mitarbeitender existieren, wird die Automatisierung unsicher – egal wie gut das Modell ist. Dunkelverarbeitung hängt deshalb stark von Stammdatenqualität ab: gepflegte Debitoren, gepflegte Lieferadressen, klare Kundenartikelnummern, aktuelle Preislisten, sauber abgegrenzte Ersatzartikel, dokumentierte Sperrkennzeichen.

Automatisierung bringt Stammdatenprobleme nicht zum Verschwinden. Sie macht sie sichtbarer. Das ist gut – wenn das Projekt darauf vorbereitet ist, sie auch zu bearbeiten. Welche Felder im Bestelleingang am häufigsten blockieren und wie ein pragmatischer Datencheck aussieht, ist Thema von Stammdatenqualität vor Automatisierung.

Welche Prüfregeln vor die ERP-Übergabe gehören

Die kritischste Stelle der Dunkelverarbeitung ist nicht die Erkennung. Es ist die Übergabe ins ERP. Vorher sollten Regeln prüfen, ob ein Auftrag fachlich sicher angelegt werden darf.

Kundenprüfung. Ist der Debitor eindeutig identifiziert und aktiv? Gibt es Sperren? Passt die Lieferadresse? Ist die Bestellung einer Niederlassung, Filiale oder Kostenstelle zugeordnet?

Dokumentprüfung. Ist eine Bestellnummer vorhanden? Wurde die Bestellung schon einmal verarbeitet (Dublette)? Gibt es mehrere Anhänge, und wurde die richtige Datei als Bestellung erkannt? Steht im E-Mail-Text eine Zusatzinformation, die die Position verändert?

Positionsprüfung. Sind alle Artikel erkannt, Einheiten eindeutig, Mengen plausibel? Gibt es unbekannte Kundenartikelnummern? Sind Artikel aktiv? Stimmt die Verpackungseinheit?

Preisprüfung. Gibt es einen gültigen ERP-Preis? Liegt die Abweichung innerhalb einer definierten Toleranz? Gilt ein Rahmenvertrag? Stimmt die Währung?

Lieferprüfung. Ist das gewünschte Lieferdatum möglich? Gibt es Teillieferwünsche? Sind Versandart und Lieferbedingung bekannt? Sind Export- oder Gefahrgutregeln zu beachten?

Risikoprüfung. Ist der Auftragswert ungewöhnlich hoch? Ist der Kunde neu? Greifen Bonitäts- oder Compliance-Prüfungen? Gibt es Dublettenverdacht?

Nicht alle Regeln müssen im ersten Pilot enthalten sein. Sie sollten aber bewusst entschieden werden. Eine einfache Regel ist besser als eine unausgesprochene Annahme.

Architektur: Erkennung, Entscheidung und ERP-Übergabe trennen

Eine robuste Architektur trennt drei Dinge, die in vielen Tools verschmelzen: was erkannt wurde, ob es fachlich gilt, und wie es ans ERP geht.

Die Reihenfolge ist immer dieselbe: Eingangskanal → Extraktion → Normalisierung in ein einheitliches internes Bestellformat → Kunden- und Artikelmapping → fachliche Validierung → Ampelentscheidung → ERP-Übergabe für grüne Fälle, Prüfansicht für gelbe, Blockierung für rote – und am Ende Protokollierung, Monitoring und eine Lernschleife für neue Regeln.

Die Normalisierung ist der unterschätzte Baustein. Egal ob die Bestellung aus E-Mail, PDF, Excel, Portal oder EDI kommt, nach der Extraktion sollte sie für die weitere Verarbeitung dieselbe interne Struktur haben: Customer, OrderHeader, OrderLines, DeliveryInformation, CommercialTerms, SourceDocument, ConfidenceAndValidation. Damit funktioniert die Validierungslogik unabhängig vom Eingangskanal.

Die Entscheidungslogik darf nicht nur aus KI-Konfidenzwerten bestehen. Ein Dokument kann mit hoher technischer Sicherheit ausgelesen sein und trotzdem fachlich unsicher sein – die Artikelnummer wurde sicher erkannt, existiert aber für diesen Kunden nicht, oder der Preis weicht stark ab, oder die Einheit passt nicht zur Verpackung.

Die ERP-Übergabe selbst kann über API, vorhandene ERP-Schnittstelle, CSV-/XML-Import, SFTP, Datenbank-Staging oder Middleware laufen. Dunkelverarbeitung verlangt nicht die modernste Schnittstelle, sondern eine stabile, nachvollziehbare und idempotente. Wie das auch in älteren Systemlandschaften funktioniert, zeigt der Artikel Altes ERP ohne API anbinden.

Dunkelverarbeitung nach Kanal: was realistisch ist

Der Eingangskanal beeinflusst stark, wie weit Dunkelverarbeitung sinnvoll geht.

E-Mail ist flexibel, aber unstrukturiert. Eine Bestellung kann im Text stehen, als PDF angehängt sein, als Excel-Datei vorliegen oder aus mehreren Dokumenten bestehen. Vor jeder Automatisierung steht hier die Klassifikation: Nicht jede E-Mail mit Anhang ist eine Bestellung – es können Rückfragen, Auftragsänderungen, Stornos, Reklamationen oder Preislisten sein. Wie der Weg vom Posteingang ins ERP konkret aussieht, beschreibt E-Mail-Bestellungen automatisch ins ERP übernehmen.

PDF ist im B2B sehr häufig und gut automatisierbar, wenn es digital erzeugt und strukturell stabil ist. Schwieriger wird es bei Scans, wechselnden Layouts oder vielen Freitextpositionen. Auslesbar ist nicht dasselbe wie dunkelverarbeitbar – die fachliche Prüfung gegen das ERP entscheidet. Welche Technik für welchen Dokumenttyp passt, zeigt Bestellungen aus PDF, E-Mail und Scan auslesen.

Excel und CSV sind oft die besten Kandidaten. Stabile Spalten erlauben hohe Trefferquoten. Risiken entstehen durch geänderte Spaltennamen, zusätzliche Kopfzeilen, leere Zeilen, manuelle Kommentare, zusammengeführte Zellen, abweichende Zahlenformate oder mehrere Tabellenblätter. Eine gute Lösung validiert das Format, statt nur Zellen zu lesen.

Ein B2B-Bestellportal ist der kontrollierteste Kanal. Kunden arbeiten direkt mit gültigen Artikeln, Preisen, Einheiten und Lieferadressen, die meisten Prüffälle entfallen schon vor dem Eingang. Dunkelverarbeitung ist hier besonders realistisch – vorausgesetzt, das Portal ist sauber an Sortiment, Preise und Stammdaten angebunden.

EDI ist standardisiert und für volumenstarke Partner stark, ersetzt aber nicht die fachliche Validierung. Auch hier gibt es Partnerabweichungen, Mappingfehler, Stammdatenprobleme, alte Versionen, fehlende Pflichtfelder und Sonderfälle bei Einheiten oder Preisen. EDI senkt die Interpretationsprobleme – die Geschäftsregeln bleiben.

Kanal	Dunkelverarbeitungspotenzial	Hauptproblem
E-Mail	mittel	Klassifikation und uneinheitliche Inhalte
PDF	mittel bis hoch	Layout, Qualität und Tabellenverständnis
Excel/CSV	hoch bei stabilen Vorlagen	Formatänderungen und Stammdaten
B2B-Portal	hoch	initialer Aufbau und ERP-Integration
EDI	hoch	Partner-Mapping und Datenqualität

Welche Kennzahlen wirklich helfen

Viele Projekte messen zu früh nur eine Kennzahl: Wie viele Bestellungen laufen ohne manuellen Eingriff durch? Diese Quote ist wichtig, allein aber gefährlich. Eine hohe Dunkelverarbeitungsquote kann auch heißen, dass das System zu großzügig entscheidet.

Sinnvoller ist eine kleine Gruppe:

Kennzahl	Frage	Warum sie wichtig ist
Dunkelverarbeitungsquote	Wie viele Bestellungen laufen automatisch durch?	Zeigt das Entlastungspotenzial.
Korrekturquote nach ERP-Übergabe	Wie viele automatisch verarbeitete Aufträge mussten korrigiert werden?	Zeigt, ob die Automatisierung sicher ist.
Prüffallquote	Wie viele Bestellungen werden bewusst angehalten?	Zeigt die Qualität von Daten, Kundenformaten und Regeln.
Klärungszeit pro Prüffall	Wie schnell werden Ausnahmen gelöst?	Zeigt, ob die Prüfstrecke wirklich entlastet.
Wiederholrate von Prüffallgründen	Kommt derselbe Fall immer wieder?	Zeigt, wo das nächste Mapping oder die nächste Regel fehlt.

Eine 55-%-Dunkelquote mit sehr niedriger Korrekturquote kann besser sein als 85 % mit vielen nachträglichen Korrekturen. Das Ziel ist nicht maximale Dunkelverarbeitung um jeden Preis. Es ist maximale Entlastung bei kontrolliertem Risiko.

Ein realistischer Pilot in 30 bis 60 Tagen

Ein guter Pilot versucht nicht, den gesamten Bestelleingang auf einmal dunkel zu verarbeiten. Er beantwortet eine konkrete Frage: Welche wiederkehrenden Bestellungen können wir sicher automatisieren – und welche Regeln brauchen wir für den Rest?

Sie merken das daran, dass die Diskussion im Pilot weg von „Was kann das Tool?" wandert und zu „Welche Bestellung darf wie laufen?" wird. Genau dann beginnt Dunkelverarbeitung, ein operativer Prozess zu werden statt eines Demo-Versprechens.

Typische Fehler bei Dunkelverarbeitung im Bestelleingang

Die wirtschaftliche Frage lautet selten „Wie hoch wird unsere Dunkelquote?". Sie lautet: Wie viel manuelle Erfassung verschwindet wirklich, wie viele Korrekturen entstehen dafür im Hintergrund, und wie schnell wachsen die Regeln aus den Prüffällen?

Fazit

Dunkelverarbeitung im Bestelleingang ist ein starkes Ziel. 100 % Automatisierung ist selten der richtige Startpunkt. Der bessere Weg ist kontrollierte Automatisierung: sichere Standardfälle automatisch verarbeiten, unsichere Fälle gezielt prüfen, riskante Fälle blockieren, jede Klärung in Regeln und Stammdaten zurückführen, den Automatisierungsgrad schrittweise erhöhen.

So entsteht nicht nur eine höhere Dunkelquote, sondern ein robusterer Auftragseingang. Der Hebel im Mittelstand liegt nicht im Mut zur blinden Automatisierung, sondern in der Fähigkeit, sichere von unsicheren Entscheidungen zuverlässig zu trennen.

Nicht jede Bestellung muss am ersten Tag dunkel laufen. Aber jede wiederkehrende manuelle Entscheidung sollte sichtbar werden. Erst dann lässt sich entscheiden, ob sie automatisiert, vereinfacht oder bewusst in der Prüfung bleibt.

FAQ zur Dunkelverarbeitung im Bestelleingang