PIM-Fehler im ERP: Welche Stammdatenfehler welche Prozesse blockieren

Warum rufen Fehler in den Artikeldaten erst so spät Probleme im ERP hervor? 

Ein Auftrag steckt fest. Das Versandlabel lässt sich nicht generieren. Der Bestellvorschlag bleibt aus, obwohl der Bestand längst auf null gelaufen ist. Das Team schaut in den Prozess, prüft die Schnittstelle, fragt beim Versanddienstleister nach und findet nichts.

Die Ursache liegt nicht im Prozess selbst. Sie liegt in den Artikeldaten, die drei Monate früher angelegt wurden. Damals hatte noch niemand daran gedacht, dass dieser Artikel international versendet oder über Amazon gelistet werden soll.

Das ist das Problem mit PIM-Fehlern im ERP: Sie entstehen früh, die Auswirkungen zeigen sich spät, und die Verbindung zwischen Fehler und Auswirkung ist selten offensichtlich.

Das ERP warnt nicht – es wartet 

Das eigentliche Problem ist, dass fehlerhafte Artikeldaten erst im Prozess, also weit nach der Artikelanlage, sichtbar werden und dann an einer ganz anderen Stelle im Betrieb auftauchen als dort, wo sie entstanden sind.

Am Artikel ist kein Einkaufspreis hinterlegt. Bemerkt wird das erst drei Wochen später, wenn der Bestand unter die Mindestlagermenge fällt und der Artikel im Bestellvorschlag trotzdem nicht auftaucht.

Die falsche Mengeneinheit wird beim Import nicht beanstandet, aber die Kommissionierung entnimmt die falsche Menge, während die Retouren sich häufen, ohne dass jemand den Zusammenhang herstellt.

Im ERP ist ein Artikel mit fehlendem Steuerattribut angelegt, aber der Versand der Rechnung schlägt erst beim nächsten Auftrag fehl, und bis dahin hat niemand den Artikel im Verdacht.

Diese zeitliche Entkoppelung zwischen Fehler und Symptom ist der Grund, warum operative Teams so viel Zeit damit verbringen, Prozesse zu debuggen, die eigentlich gar nicht das Problem sind.

Der Picking-Prozess ist nicht kaputt. Die Schnittstelle zum Versanddienstleister funktioniert. Das Problem liegt im Artikelstamm – und der wurde von jemandem angelegt, der längst nicht mehr an diesem Vorgang beteiligt ist.

Fünf typische Fehler in Artikelstammdaten und ihre Folgen 

Fehler 1: Kein Einkaufspreis am Artikel – der Bestellvorschlag lässt den Artikel aus 

Fehler im Feld: Am Artikel ist kein Einkaufspreis mit Lieferant hinterlegt, oder der Artikel ist nicht als Lagerartikel markiert.

Betroffener Prozess: Bestellvorschlag und Disposition.

Was passiert: Der Bestellvorschlag arbeitet über die Einkaufspreise, die am Artikel hinterlegt sind. Daraus zieht Xentral den Lieferanten und gruppiert die Positionen. Fehlt der Einkaufspreis, gibt es keinen Lieferanten, dem die Position zugeordnet werden kann, und der Artikel fällt aus dem Vorschlag heraus. Dass die Min. Lagermenge gepflegt ist, hilft dann nicht. Der Einkauf merkt es erst, wenn der Bestand auf null läuft und Aufträge nicht mehr bedient werden können. Das passiert oft mitten in der Peak-Season, wenn Nachbestellungen am längsten dauern.

Der Weg dagegen: Drei Angaben müssen stehen, damit ein Artikel im Bestellvorschlag auftaucht. Die Lieferantenadresse braucht eine Lieferantennummer, am Artikel muss ein Einkaufspreis für diesen Lieferanten hinterlegt sein, und der Artikel muss als Lagerartikel markiert sein. Xentral warnt dich dabei: Hat ein Artikel denselben Hauptlieferanten wie andere, aber keinen Einkaufspreis, blendet der Bestellvorschlag einen Hinweis ein. Darauf zu achten kostet Sekunden, die Suche im Prozess kostet später Stunden.

Und die EAN? Die ist in Xentral die wichtigste Kennung, über die deine Produkte identifiziert werden, aber im Lager, nicht im Einkauf. Sie hängt an den Scan-Prozessen: Wareneingang, Kommissionierung, Packtisch, Retouren, Kasse. Fehlt sie oder ist sie doppelt vergeben, scannst du ins Leere. Auf die Disposition hat sie keinen Einfluss.

Konsequenz: Lieferverzögerungen, verärgerte Kund:innen, Notbestellungen zu schlechteren Konditionen.

Fehler 2: Falsche Einheiten im ERP – die Kommissionierung entnimmt die falsche Menge 

Fehler im Feld: Der Artikel wird in Kartons à 12 Stück gehandelt, aber im Artikelstamm ist keine Umverpackung angelegt.

Betroffener Prozess: Kommissionierung und Versand.

Was passiert: Das Feld Einheit im Artikel ist nur eine Beschriftung. Es steht auf Belegen und in Stücklisten, es rechnet nichts um. Wer „5" bestellt und „Karton" meint, bekommt fünf Einzelstücke gepickt, wenn der Bestand in Stück geführt wird. Die Lieferung ist falsch, die Retoure kommt zurück. Weil der Fehler im Picking sichtbar wird, sucht das Team dort nach der Ursache und findet sie nicht.

Der Weg dagegen: Im Artikel legst du unter Umverpackung den Barcode der Umverpackung an und die Menge, die darin steckt. Xentral erkennt dann bei jedem Scan automatisch die korrekte Artikelmenge und verbucht sie. Wichtig dabei: Umverpackungsnummern brauchen einen eigenen Nummernkreis, getrennt von den Artikelnummern.

Fehler 3: Falscher Steuersatz – die Rechnung geht raus und ist falsch 

Fehler im Feld: Am Artikel ist der falsche Steuersatz ausgewählt, zum Beispiel normal statt ermäßigt für Lebensmittel.

Betroffener Prozess: Rechnungsstellung und Buchhaltungsexport.

Was passiert: Der Steuersatz am Artikel ist eine Auswahl zwischen den beiden Sätzen, die systemweit hinterlegt sind, in Deutschland 19 % und 7 %. Ist nichts gesetzt, gilt der Normalsatz. Die Rechnung geht also raus, sieht korrekt aus und trägt den falschen Satz. Auffällig wird es erst bei der Korrektur: Stornorechnung, Neuerstellung, neuer Zahlungslauf. Dazu kommt der Buchhaltungsexport. Die Erlöskonten zieht Xentral in dieser Reihenfolge: Konto am Artikel, dann Konto an der Artikelkategorie, dann Systemeinstellungen. Ist am Artikel mit abweichendem Steuersatz kein Konto gepflegt, landet der Umsatz auf dem Standardkonto. Der Fehler wandert damit aus der Rechnung in die Buchhaltung. Besonders heikel bei Artikeln, die zwischen 7 % und 19 % wechseln, etwa Lebensmittel mit und ohne Verarbeitung: Dort ist der Steuersatz beim Anlegen selten im Fokus.

Konsequenz: Verzögerter Zahlungseingang, Buchungskorrektur kostet Stunden, im schlimmsten Fall GoBD-relevante Fehler.

Fehler 4: Fehlende Varianten-Struktur – das Marktplatz-Listing schlägt fehl 

Fehler im Feld: Farbe und Größe sind nicht als Varianten-Matrix angelegt, sondern als separate Einzelartikel ohne Verknüpfung.

Betroffener Prozess: Übertragung an Shop und Marktplatz.

Was passiert: Die Schnittstelle erwartet eine strukturierte Varianten-Hierarchie, also eine Parent-Child-Beziehung. Fehlt sie, schlägt die Übertragung fehl oder der Artikel wird als Einzelvariante ohne Auswahl-Option gelistet. Kund:innen können Größe oder Farbe nicht wählen, der Artikel verkauft sich kaum oder gar nicht. Bemerkt wird das oft erst, wenn die Verkaufszahlen einbrechen und jemand nachschaut, warum der Artikel kaum noch auftaucht. In Xentral legst du die Struktur als Matrixprodukt an: ein Eltern-Artikel, darunter die Kind-Artikel je Kombination aus Farbe und Größe. Für Shopify und Shopware 6 ist die Synchronisation über Connect dokumentiert. Sie läuft bei der Erst-Übertragung schrittweise: erst das Matrixprodukt, dann warten, bis es im Journal grün steht, dann die Varianten. Wer das in einem Zug versucht, bekommt genau die fehlgeschlagene Übertragung, um die es hier geht.

Konsequenz: Fehlende Sichtbarkeit auf dem Marktplatz, entgangener Umsatz, manueller Korrekturaufwand für jede betroffene Variante. Bei großen Sortimenten kann das schnell Dutzende von Artikeln betreffen.

Fehler 5: Falsches Gewicht oder fehlende Zollnummer – der internationale Auftrag bleibt hängen 

Fehler im Feld: Artikelgewicht fehlt oder ist falsch, Zolltarifnummer (HS-Code) ist nicht hinterlegt.

Betroffener Prozess: Versandlabel bei internationalen Aufträgen.

Was passiert: Die Erzeugung des Versandlabels schlägt fehl. Fehlt das Gewicht in den Artikelstammdaten, kommt kein Label. Fehlt die Zolltarifnummer, ebenfalls nicht. Jemand muss die Daten beim Hersteller oder in Zolldatenbanken recherchieren und den Versand neu anstoßen. Bei einem Artikel ist das lästig. Bei 200 Produkten, die gerade auf einen neuen Markt ausgerollt werden, ist es ein Engpass.

Die Maßnahme dagegen: Für genau diesen Fall bringt Xentral zwei Notbremsen mit. In der Versandart hinterlegst du unter Fallback-Positionsartikelgewicht ein Gewicht in Kilogramm, das greift, wenn am Artikel keines gepflegt ist. Unter Auto-Fallback für den HS-Code hinterlegst du eine Zolltarifnummer, die einspringt, wenn am Artikel keine steht. Die Sendung läuft dann weiter, statt am Packtisch zu stehen. Ein Ersatz für gepflegte Stammdaten sind die Fallbacks nicht: Gewicht, Zolltarifnummer und Herkunftsland müssen korrekt sein, sonst stimmen die Zollpapiere nicht. Sie kaufen dir Zeit, den Fehler in Ruhe zu beheben.

Wo die Felder liegen: das Gewicht im Artikel unter Details > Lager/Abmessungen, die Zolltarifnummer unter Details > Hersteller.

Konsequenz: Lieferverzögerung bei internationalen Kund:innen, manueller Aufwand pro Auftrag, Skalierung ins Ausland wird zur Fehlerquelle statt zum Wachstumshebel.

Wie schließt Xentral PIM-Fehler schon bei der Integration ins ERP aus? 

Die fünf Fehlerbilder oben haben eine gemeinsame Ursache: Das ERP hat beim Anlegen des Artikels keine Rückmeldung gegeben, dass ein relevantes Feld fehlt. Und wer beim Anlegen nicht weiß, welche Felder für welchen Prozess relevant sind, lässt sie weg. Das System lässt es zu.

Die Lösung ist keine Schulung und kein neues Checklisten-Dokument, sondern eine sichere Struktur im System selbst.

In der Artikelverwaltung in Xentral lässt sich genau das konfigurieren:

Pflichtfelder je Artikeltyp 

Im Modul Pflichtfelder legst du systemweit fest, welche Felder beim Speichern ausgefüllt sein müssen, mit eigener Fehlermeldung. Für Gewicht und Zolltarifnummer ist das der wirksamste Hebel, weil daran der internationale Versand hängt.

Wer einen neuen Artikel anlegt, wird an genau der Stelle aufgehalten, wo die Lücke sonst ins ERP käme. Die Regel gilt systemweit für ein Modul, nicht je Artikeltyp.

Du kannst also nicht für physische Produkte andere Pflichtfelder setzen als für Dienstleistungen. Neben Modul und Seite trägst du die Feld-ID ein, die du im Browser über "Element untersuchen" abliest.

Validierungsregeln beim Import 

Der CSV-Importer prüft deine Zuordnung, bevor er schreibt. Passt etwas nicht, kommt eine rote Meldung und du korrigierst die genannten Datensätze; ist alles grün, startet der Import im Hintergrund und du verfolgst den Status je Datensatz.

Die Prüfung fängt Datensätze ab, die Xentral nicht verarbeiten kann: eine Artikelnummer, die es nicht gibt, ein Einkaufspreis ohne Lieferant, ein Bruttopreis unter dem Nettopreis. Was sie nicht fängt, sind plausible, aber falsche Werte. Beim Artikelimport sind nur Artikelnummer und Bezeichnung Pflicht. Alle leeren Felder werden auf den Standard gesetzt. Eine falsche Einheit ist damit gültige Daten. Dagegen hilft nur eine Sichtprüfung der Importvorlage, bevor du 500 Zeilen hochlädst.

Fallback-Werte für den Versand 

Für die beiden Felder, an denen der internationale Versand tatsächlich scheitert, kannst du in der Versandart eine Rückfallebene hinterlegen. Fehlt am Artikel das Gewicht, greift das Fallback-Positionsartikelgewicht. Fehlt die Zolltarifnummer, greift der Auto-Fallback für den HS-Code. Der Auftrag läuft weiter, und du korrigierst die Stammdaten danach statt mitten im Versand.

Nach demselben Muster funktioniert die Standard Artikel Einheit in den Grundeinstellungen: Artikel ohne Einheit bekommen auf Belegen automatisch die hinterlegte Standardeinheit. Das ist nützlich, wenn der tägliche Shop-Import keine Einheiten mitliefert.

Fazit: PIM-Fehler im ERP systematisch verhindern – einmal sauber strukturieren spart fünfmal händisch kontrollieren 

Um zu vermeiden, dass Fehler in den Stammdaten ERP-Prozesse blockieren, musst du überhaupt erst einmal die Verbindung herstellen zwischen dem Datenfeld, das beim Anlegen fehlt, und dem Prozess, der später daran scheitert.

Die fünf Fehlerbilder sind ein guter Ausgangspunkt, um deine e-Commerce-Produktdaten gezielt zu prüfen.

Der zweite Schritt ist die Strukturierung: Pflichtfelder, Validierungsregeln und kanalspezifische Freigabelogiken verhindern, dass neue Fehler entstehen. Nicht durch händische Kontrolle, sondern weil das System selbst keine Lücken mehr durchlässt.