# Ein Datenbestand statt fünf Systeme > Fragen Sie, was ein Kunde für ein Produkt zahlt, und die Antwort hängt davon ab, wen Sie fragen. Warum kommerzielle Konditionen zwischen ERP, Preisdateien, Verträgen, Rückvergütungstabellen und Posteingängen auseinanderlaufen, was ein einziger gesteuerter Datenbestand tatsächlich voraussetzt und ein Test mit zehn Positionen, der die Lücke misst. Source: https://revomo.ai/de/blog/one-record-not-five-systems/ --- [← Alle Artikel](https://revomo.ai/de/blog/) Fokus Pricing-Systeme ## Ein Datenbestand statt fünf Systeme Alex Hoff Chief Customer Officer · 16. Okt. 2026 · 6 Min. Lesezeit Auf dieser Seite - Wo der Datenbestand heute liegt - Wie fünf Datenbestände auseinanderlaufen - Was ein einziger Datenbestand tatsächlich voraussetzt - Warum das zuerst kommen muss - Womit Sie morgen anfangen Fokusmodus Die erste Aufgabe auf der Liste im [letzten Beitrag](https://revomo.ai/de/blog/the-six-things-a-real-pricing-system-has-to-do/) war, einen einzigen Datenbestand für alle kommerziellen Konditionen zu führen. Der Beispielsatz dazu war ein einfacher Test: Wenn sich ein Preis um 9 Uhr ändert, sieht jeder, der darauf ein Angebot erstellt, eine Rechnung stellt oder eine Rückvergütung auszahlt, bis 9:05 Uhr dieselbe Zahl, ohne dass jemand eine Datei weiterleitet. Nur sehr wenige mittelständische Hersteller oder Distributoren bestehen diesen Test heute, und die meisten wissen das. Stellen Sie eine schlichte Frage wie „Was zahlt dieser Kunde für dieses Produkt?“, und die Antwort hängt davon ab, wen Sie fragen. Der Vertrieb schaut in die Preisdatei. Der Kundenservice schaut ins ERP. Die Finanzabteilung schaut in den Bericht, der die Zuordnung der Rückvergütungen enthält, und wer die letzte Vereinbarung verhandelt hat, sucht in seinem Posteingang. Jeder kommt mit dem zurück, was er für die Antwort hält, aber die Antworten passen oft nicht zusammen. In diesem Beitrag geht es darum, warum das passiert und was es braucht, um es zu beheben. ### Wo der Datenbestand heute liegt Bei den meisten Unternehmen, mit denen wir arbeiten, verteilen sich die kommerziellen Konditionen auf ungefähr fünf Orte. - **Das ERP** (oft als führendes System für den Preis betrachtet) enthält den Preis, der fakturiert wird, und dazu die Rabattstruktur, die jemand bei der Einführung des Systems konfigurieren konnte. - **Ein gemeinsamer Ordner** enthält die Preisdateien: Listenpreise, kundenspezifische Preisblätter und die „Master“-Arbeitsmappe mit der Logik der Preisfindung. - **Verträge und Sonderpreisvereinbarungen** liegen als PDFs vor, manchmal in einem CRM oder Vertragstool, oft in einem Ordner, der nach dem Kunden benannt ist. - **Konditionen für Rückvergütungen und Incentives** stehen in einer Tabelle der Finanz- oder Buchhaltungsabteilung, weil dort die Rückstellungen berechnet werden. - **Die Ausnahmen** (einmalige Freigaben, die E-Mail „bei diesem Projekt mit dem Preis des Wettbewerbers mitgehen“, die erlassene Fracht für einen guten Kunden) liegen in Posteingängen und Chatverläufen. Jeder dieser Orte wurde von einem anderen Team für einen anderen Zweck eingerichtet, und jeder erfüllt seine eigene Aufgabe recht gut. Das Problem ist, dass keiner mit den anderen übereinstimmen muss und nichts prüft, ob sie es tun. Fünf verschiedene Sichten auf den Preis, die meist nicht übereinstimmen und nicht dieselbe Geschichte erzählen. One question, five places “What does this customer pay for this product?” Today - ERP - ≠ - Price file - ≠ - Contract - ≠ - Rebate sheet - ≠ - Inbox Five answers. One record **Every term, defined once** effective-dated · owned · traceable - ERP - Price file - Contract - Rebate sheet - Inbox One answer. ### Wie fünf Datenbestände auseinanderlaufen Das Auseinanderlaufen ist selten dramatisch. Es entsteht durch gewöhnliche Lücken, für die niemand zuständig ist. **Zeitpunkte** sind die häufigste Ursache. Eine Listenpreisänderung gilt in der Preisdatei ab dem Ersten des Monats und im ERP ab dem Fünften, sobald jemand dazu kommt, sie einzuspielen. Der Vertrag, der stabile Preise bis Jahresende zugesagt hat, erfährt davon womöglich nie. Ein paar Wochen lang, oder auf unbestimmte Zeit, hat das Unternehmen mehr als einen gültigen Preis für denselben Artikel. **Kennungen** kommen als Nächstes. Das ERP kennt den Kunden unter einer Rechnungsempfänger-Kontonummer, der Vertrag nennt die Muttergesellschaft, und die Rückvergütungs-Arbeitsmappe gruppiert Kunden nach Einkaufsverbund. Die Sonderpreisvereinbarung eines Lieferanten führt dessen Teilenummer, die erst Ihrer eigenen SKU zugeordnet werden muss, bevor sich irgendetwas abgleichen lässt. **Mengeneinheiten** fügen eine weitere Ebene hinzu. Ein Vertrag mit Preis pro Karton und eine Rechnung pro Stück sehen wie ein Rabatt von 90 % aus, bis es jemandem auffällt, und viele Berichte entstehen, bevor das passiert. Dann gibt es **Konditionen, die nur an einem Ort existieren**. Vom Lieferanten finanzierte Sonderpreise sind ein gutes Beispiel in der Distribution. Die Rechnung zeigt einen Verkauf zum Einstandspreis oder darunter, und die Unterstützung, die die Position profitabel macht, kommt später als Claim gegen den Lieferanten, erfasst an einem anderen Ort. In einem aktuellen Projekt zeigten ERP-Rechnungspositionen, die unter Lieferantenvereinbarungen verkauft wurden, in den Rechnungsdaten eine negative Bruttomarge. Nachdem die Lieferantenunterstützung (SPA-Rückvergütungen) jedem Kunden und jeder SKU zugeordnet war, trugen dieselben Positionen eine Pocket-Marge von über 11 %. Niemand hatte einen Fehler gemacht; die Preise waren nicht „falsch“. Die beiden Hälften jedes Geschäfts waren in verschiedenen Systemen erfasst, und nichts verband sie. Dieses Beispiel lohnt einen zweiten Blick, denn die Kosten des Auseinanderlaufens wirken in beide Richtungen. Getrennte Datenbestände verbergen Margenverluste, das erwarten die meisten. Sie können aber auch gesundes Geschäft unprofitabel aussehen lassen, und das führt zum falschen Gespräch mit dem falschen Kunden. Beides ist schlecht. ### Was ein einziger Datenbestand tatsächlich voraussetzt „Ein Datenbestand“ kann wie die Forderung klingen, das ERP zu ersetzen, und diese Sorge ist ein Grund, warum viele Unternehmen gar nicht erst anfangen. Keine Sorge, Ihr CIO kann sich entspannen; das ERP muss nicht ersetzt werden. Das ERP fakturiert weiter, und Verträge werden weiter in dem Tool unterschrieben, das die Rechtsabteilung oder Sales Ops bevorzugt. Die Änderung ist, dass jede kommerzielle Kondition einmal definiert wird, an einem gesteuerten Ort, mit einem Gültigkeitsdatum und jemandem, der dafür verantwortlich ist. Jedes andere System liest entweder aus diesem Datenbestand oder wird gegen ihn abgeglichen. In der Praxis läuft das auf ein paar unspektakuläre Arbeitspakete hinaus. **Kunden, Produkte und Lieferanten werden einmal zugeordnet**, einschließlich Rechnungsempfänger zur Muttergesellschaft, Zugehörigkeit zu Einkaufsverbünden, Lieferanten-Teilenummer zu Ihrer SKU und Umrechnung der Mengeneinheiten. Jede nachgelagerte Verknüpfung nutzt dann dieselben Schlüssel, statt dass jeder Analyst sie neu aufbaut. **Jede Kondition trägt ein Start- und ein Enddatum**, sodass „Welchen Preis hatte dieser Kunde am 3. März?“ genau eine Antwort hat und eine Vereinbarung, die auslaufen sollte, tatsächlich ausläuft. **Jede Art von Kondition hat eine benannte verantwortliche Person**, die sie ändern darf, und jede Änderung hinterlässt eine Spur, wer sie wann und warum vorgenommen hat. **Transaktionen verweisen auf die Konditionen, nach denen sie bepreist wurden**, sodass eine Rechnungsposition Ihnen sagen kann, welcher Preis und welche Vereinbarung oder welches Rückvergütungsprogramm für sie galt. Das ist der Teil eines Pricing-Projekts, der am längsten dauert und in einer Demo die wenigste Zeit bekommt, weshalb er so oft zu knapp geplant wird. Es ist auch der Teil, der entscheidet, ob man allem, was darauf aufbaut, vertrauen kann. ### Warum das zuerst kommen muss Jede andere Aufgabe aus dem letzten Beitrag liest aus diesem Datenbestand. Eine Analyse von Margenverlusten braucht die Rechnungsposition verknüpft mit der Rückvergütung und der Vereinbarung dahinter, sonst ist die Pocket-Marge schlicht falsch. Wer eine Kostenänderung beziffern will, muss wissen, welche Kunden Preisschutz haben und bis wann. Eine Empfehlung ist nur so gut wie die Konditionen, auf denen sie beruht, und ein Prüfpfad kann nur zu einem Datenbestand zurückführen, der existiert. Unternehmen, die diesen Schritt überspringen und direkt zur Analytik gehen, bauen die Verknüpfung meist jedes Mal von Hand neu, wenn eine neue Frage aufkommt. Das ist wieder [das Tabellenproblem](https://revomo.ai/de/blog/what-pricing-looks-like-when-it-lives-in-spreadsheets/), nur mit einer schöneren Oberfläche. ### Womit Sie morgen anfangen Wie weit Ihre Datenbestände auseinanderliegen, können Sie an einem Nachmittag messen. Ziehen Sie zehn Rechnungspositionen aus dem letzten Monat, von verschiedenen Kunden, darunter mindestens ein paar, die unter (oder mit) einer Sondervereinbarung oder einem Rückvergütungsprogramm verkauft wurden. Notieren Sie für jede Position den Preis laut ERP, laut aktueller Preisdatei, laut Vertrag oder Vereinbarung und die Rückvergütungskonditionen, die gelten sollten. Halten Sie dann fest, wo sie voneinander abweichen und welche Quelle sich als richtig herausgestellt hat. Häufig finden sich ein paar Positionen, bei denen die Quellen abweichen und niemand sicher sagen kann, welche stimmt. Diese kurze Liste ist ein starker Einstieg in das Gespräch mit Finanzen und IT darüber, wo der Datenbestand liegen soll und wem welcher Teil gehört. Sie gibt Ihnen außerdem eine Ausgangsbasis, an der Sie messen können, sobald die Arbeit beginnt. *Als Nächstes in der Reihe: den Margenverlust finden, bevor das Quartalsende ihn für Sie findet.* *Bei Revomo liegt dieser Datenbestand im [Data & Context Studio](https://revomo.ai/de/product/data-context-studio/), das in jedem Abonnement enthalten ist. Wenn Sie den Test mit zehn Positionen machen und Hilfe beim Auswerten der Ergebnisse möchten, [tauschen wir uns gern aus](https://revomo.ai/de/contact/). Eine erste Einschätzung ist für Sie kostenlos.* ### Weiterlesen [Nächster Teil der Reihe #### Finden Sie das Leck, bevor das Quartalsende es für Sie findet 7 Min. Lesezeit · 21. Okt. 2026](https://revomo.ai/de/blog/finding-the-leak-before-quarter-end-finds-it-for-you/)[Mehr zu Pricing-Systeme #### Sechs Aufgaben, die ein echtes Pricing-System erfüllen muss 7 Min. Lesezeit · 12. Okt. 2026](https://revomo.ai/de/blog/the-six-things-a-real-pricing-system-has-to-do/)[Mehr zu Pricing-Systeme #### Zuzugeben, dass die Preistabelle nicht funktioniert, ist der leichte Teil 8 Min. Lesezeit · 22. Sept. 2026](https://revomo.ai/de/blog/admitting-the-spreadsheet-is-broken-is-the-easy-part/) **** Ein Datenbestand statt fünf Systeme Fokus beenden Esc