B2B-Bestellportal für Distributoren: Scope, Preise, ERP-Sync

Ein B2B-Bestellportal gibt freigegebenen Händlern ihren eigenen Katalog und die mit ihnen vereinbarten Preise in die Hand: sie bestellen selbst, wiederholen letzte Bestellungen und sehen ihre Belege – alles synchron mit dem ERP-System. Planen Sie den Umfang in Phasen: zuerst Konten, Preise und Bestellungen, danach Zahlungen und Freigaben – ein Portal, das sofort vollständig starten will, kommt spät und unvollständig auf den Markt.

Was ist ein B2B-Bestellportal?

Ein B2B-Bestellportal ist ein unternehmenseigener Webkanal, über den Ihre freigegebenen Distributoren und Gewerbekunden selbst Geschäft machen: sie durchblättern den für ihr Konto sichtbaren Katalog, sehen die mit ihnen vereinbarten Preise, stellen eine Bestellung zusammen oder wiederholen eine frühere und finden die Belege, die zu ihrem Konto gehören – Angebote, Bestellungen, Rechnungen, Gutschriften, Lieferscheine. Das ERP-System bleibt das System der Aufzeichnung; das Portal ist das Fenster darauf, mit Regeln darüber, was jedes Konto sehen und tun darf.

Klar trennen lässt sich das Portal von drei Nachbarn, mit denen es häufig verwechselt wird:

• Ein Webshop. Handelspreise, offene Registrierung, Kartenkasse. Ein Distributorenportal ist das Gegenteil: Der Zugang wird je Konto gewährt, Preise sind vertraglich, und die Zahlung erfolgt zu vereinbarten Bedingungen statt an der Kasse.


• Ein Kundenbereich auf der Marketing-Seite. Nützlich für Downloads und Support-Tickets, aber ohne Katalog-, Preis- und Bestelllogik nimmt er dem Vertriebsschalter nicht ein einziges Telefonat ab.


• Eine PDF-Preisliste per E-Mail. Der Zustand, in dem die meisten Distributoren vor einem Portal leben: am Versandtag korrekt, in der Folgewoche falsch und je Konto nicht durchsuchbar.

Funktionstabelle: Muss, sollte, später

Anbieter-Seiten listen alles auf einmal. Erst die Aufteilung in Phasen hält die erste Version auslieferbar. Die Tabelle ordnet die wiederkehrenden Funktionen danach, was die erste Version braucht, was die zweite typischerweise ergänzt und was auf echte Nutzungsdaten warten darf:

Tabelle A: Funktion | Zweck | Phase (1/2/3) | ERP-Abhängigkeit

Phase 1 ist die Version, die Verhalten ändert: Wenn ein Distributor einloggen, seine Preise sehen, die Bestellung vom letzten Monat wiederholen und sie ins ERP-System bringen kann, schließt sich der Kanal aus Telefon und Tabelle von selbst. Phasen 2 und 3 ergänzen die Finanz- und Steuerungsschichten; sie setzen voraus, dass die Organisation ihre Kredit-, Finanz- und Freigabeentscheidungen getroffen hat, bevor die Software sie halten kann.

ERP- und CRM-Integration

Die Integration entscheidet, ob das Portal ein Spiegel des Geschäfts ist oder eine Broschüre mit Login. Vier Fragen brauchen schriftliche Antworten, bevor eine Architektur gewählt wird:

1. Sync-Richtung. Stammdaten – Konten, Produkte, Preise, Bedingungen – fließen vom ERP ins Portal. Bestellungen, Preisanfragen und Zahlungen fließen zurück. Alles andere braucht einen eindeutigen Besitzer: Wer darf einen Preis ändern, und wo lebt diese Änderung?


2. Sync-Häufigkeit. Nächtlicher Batch, regelmäßige Aktualisierung am Tag oder nahezu Echtzeit. Die ehrliche Regel: Preise und Kreditpositionen rechtfertigen häufigere Synchronisierung als Produktbilder, eine Mischstrategie ist also normal – kritische Daten öfter, Kataloginhalte seltener.


3. Fehlerbehandlung. Wenn das ERP ausfällt oder ein Datensatz die Validierung nicht besteht: Was tut das Portal – Warteschlange, Ablehnung oder Anzeige des letzten bekannten Stands mit klarem Hinweis? Stilles Scheitern führt dazu, dass ein Distributor zum Preis der Vorwoche bestellt – daraus wird Ihr Streit, nicht seiner.


4. Abgleich. Wie wissen Sie, dass jede Portal-Bestellung genau ein ERP-Beleg wurde – keine Duplikate, keine Lücken, keine halb konvertierten Datensätze? Die Antwort ist ein Betriebsbericht, den in den ersten Monaten jemand täglich liest, und er ist einer der Abnahmetests unten.

Mehrsprachige und mehrwährige Kataloge

Exporteure stoßen früh auf beide Fragen, und sie sind billiger zu entscheiden als nachzurüsten.

Sprachen. Der Katalog braucht Übersetzungen für Produktnamen, Kategorien und Belege; die Kontenstruktur braucht eine Sprachpräferenz je Konto, damit derselbe Einkäufer nicht bei jedem Besuch neu wählen muss. Zwei praktische Punkte: festlegen, wem die Übersetzungen gehören und wie oft sie aktualisiert werden – ein halb übersetzter Katalog wirkt auf den Käufer, der es bemerkt, schlechter als ein rein englischer – und entscheiden, ob Belege (Angebote, Rechnungen) der Oberflächensprache folgen oder in der Sprache bleiben, die Ihr Finanzsystem verlangt. Die zweite Frage ist nicht technisch: Eine Rechnung in der falschen Sprache ist ein Buchhaltungsproblem.

Währungen. In einer Währung vereinbarte Preise sollten unabhängig vom Standort des Besuchers in dieser Währung erscheinen; die Mischung aus Anzeigewährung und Vertragswährung ist der Anfang von Streitigkeiten. Wenn ein Konto in mehr als einer Währung handelt, muss die Regel in den ERP-Daten stehen, nicht in den Portal-Einstellungen, und das Portal darf nie der Ort sein, an dem eine Umrechnung erfunden wird.

Beide Themen hängen mit dem Phasenplan zusammen: Ein Exporteur, der in drei Märkte verkauft, kann Phase 1 in den Sprachen starten, die diese drei Märkte tatsächlich in ihren Bestellungen verwenden, und weitere Katalogsprachen ergänzen, wenn der Markt wächst. Die allgemeine Regel für Spracharbeit auf Handelsseiten – ein Verantwortlicher, eine Quelldatei, ein Aktualisierungsweg – steht auf der Internet-Marketing-Seite und gilt für einen Portalkatalog genauso.

Sicherheit und Rollen

Ein Portal ist eine Tür ins kommerzielle Datenmaterial, also sind die Entwurfsfragen Zugangsfragen:

• Zugang wird gewährt, nicht selbst registriert. Jedes Konto legt Ihr Team gegen ein ERP-Konto an; die Alternative – offene Registrierung mit Freigabeschritt – erzeugt Hintergrundrauschen und verwischt, wer Kunde ist.


• Rollenbasierte Rechte. Ein Einkäufer darf innerhalb eines Limits eine Bestellung zusammenstellen und abschicken; ein Freigebender darf es freigeben; ein Leser sieht nur Belege. Limits je Rolle sind Teil der kommerziellen Bedingungen, kein technischer Nachgedanke – sie kodieren, wer in der Organisation Ihres Kunden Sie verpflichten darf.


• Kontenisolation. Der ernsteste Fehlermodus in dieser Produktklasse ist ein Distributor, der Preise oder Belege eines anderen sieht. Die Daten-Sichtbarkeit je Konto wird ausdrücklich getestet, und sie ist einer der Abnahmetests unten.


• Prüfpfad. Wer die Bestellung aufgegeben, wer sie freigegeben, wer einen Preis geändert und wann – als Daten gehalten, nicht als Logdateien, von denen man jemanden überzeugen muss, sie zu lesen. Streitigkeiten im Handel werden häufiger durch diesen Pfad entschiedet als durch Erinnerung.


• Identität und Single Sign-On. Für größere Distributoren ist SSO in ihr eigenes Verzeichnis eine häufige Anforderung, die sich eher spät als früh festlegen lohnt – die meisten Konten laufen mit Einladungen und Passwörtern zufriedenstellend, bis eine Zentrale die Föderierung verlangt.


• Datenschutz. Kundendaten im Portal unterliegen denselben Pflichten, die das Unternehmen ohnehin für seine Kundenstammdaten hat; für türkische Aktivitäten ist das der KVKK-Rahmen, für europäische Kunden die DSGVO – ein Thema, das auf der Outsourcing-Seite im Kontext der Zusammenarbeit mit einem Entwicklungspartner ausführlich behandelt wird.

Eigenbau oder Plattform

Die Frage ist nicht pauschal Eigenbau versus Standardprodukt; sie betrifft, welche Ebene Sie tatsächlich kaufen.

Tabelle B: Weg | Was Sie bekommen | Was Sie tragen | Passt, wenn ...

Den mittleren Weg wählen die meisten Exporteure beim ersten Mal; der zu vermeidende Fehler ist ihn für den günstigen zu halten: Ein Konnektor ist ein gepflegtes Produkt, und seine Kosten fallen regelmäßig an. Der Entscheidungsrahmen für „konfigurieren, kaufen oder bauen“ wird auf der Seite Eigenbau versus Standard-ERP ausführlich behandelt; was diese Seite ergänzt, ist der portalspezifische Test: Was auch immer Sie wählen – die Preisliste je Konto und die Bestellung ins ERP-System müssen nachweisbar korrekt sein, und der gewählte Weg sollte der sein, der das zum niedrigsten wiederkehrenden Preis nachweisbar macht.

Gestufter Rollout und Abnahmetests

Ein Portal-Start scheitert leise, wenn „es funktioniert“ bedeutet „die Demo funktionierte“. Jede Phase sollte schriftliche Abnahmetests mit sich tragen, durchgeführt mit echten Konten und echten Daten:

1. Katalogsichtbarkeit je Konto. Mit zwei verschiedenen Distributoren einloggen; jeder sieht genau seine eigene Produktmenge und keine Spur der anderen. Bewusst getestet, nicht vorausgesetzt.


2. Preisgenauigkeit. Für eine Stichprobe von Konten und Artikeln ist der Portalpreis gleich dem ERP-Preis – samt der Regeln dahinter (Preisgruppe, Staffel, Vereinbarung). Das ist der Test, der die Geschäftsbeziehung schützt: ein falscher Preis im Portal ist schlimmer als ein falscher Preis im Angebot, denn der Kunde sah ihn als bestehende Vereinbarung.


3. Bestellintegrität. Eine im Portal aufgegebene Bestellung wird genau ein ERP-Beleg, mit korrekten Artikeln, Mengen, Einheiten und Preisen – und der Abgleichbericht weist es nach. Auch den Fehlerpfad testen: Eine von einer Regel blockierte Bestellung sollte das klar sagen, statt still zu scheitern.


4. Status und Belege. Eine im ERP gebuchte Rechnung und Lieferung erscheinen in der Portalansicht des richtigen Kontos, mit dem richtigen Status, innerhalb des vereinbarten Sync-Fensters.


5. Bedingungen und Limits. Kredit- und Zahlungsbedingungen je Konto werden korrekt angezeigt, und wo die Regeln sagen, dass eine Bestellung blockiert oder markiert werden soll, wird sie blockiert oder markiert – an der Grenze getestet, nicht in der bequemen Mitte.


6. Die täglichen Routinen. Nachbestellung, Schnellbestellung nach Artikelnummer und Suche – mit den Produktlisten zweier echter Distributoren, nicht mit dem Demo-Katalog. Das Ankommen lebt oder stirbt an diesen drei Wegen, und sie kosten einen Bruchteil des Baus, wenn man sie richtig testet.

Häufig gestellte Fragen

Brauchen wir zuerst ein ERP?

Nicht zwingend ein neues – aber Sie brauchen die Stammdaten irgendwo vertrauenswürdig: Konten, Produkte, Preislisten und Bedingungen. Wenn sie nur in Tabellen leben, automatisiert das Portal die Fehler der Tabelle je Konto, und das ist schlechter als das Telefon. In diesem Fall ist die ehrliche Reihenfolge zuerst die Daten zu stabilisieren (oft in einem vorhandenen, unternutzten ERP), danach das Portal; die Seite Odoo für Handelsunternehmen behandelt diese Entscheidung aus ERP-Sicht.

Können Kunden eigene Preislisten haben?

Ja – Preise je Konto sind der Kern dieser Produktklasse, kein Extra: Preisgruppen, Staffelpreise oder einzelne Vereinbarungen, alle im ERP gehalten und je Konto angezeigt. Die Regel, auf der zu bestehen ist: Das Portal bepreist nie selbst; es zeigt, was das ERP hält, und jeder Preis, den ein Distributor sieht, lässt sich auf eine Vereinbarung zurückführen, die Ihr Team getroffen hat.

Wie werden Bestellungen freigegeben?

In der Regel in zwei Ebenen. In der Organisation Ihres Kunden liegt die Freigabe bei ihnen: Ein Einkäufer schlägt vor, ein Freigebender gibt frei, optional innerhalb von Limits – diese Rollen kann das Portal in Phase 3 tragen. In Ihrer eigenen Organisation kommt die Bestellung im ERP an und folgt Ihrer normalen Auftragsabwicklung; das Portal ersetzt nicht die Kontrollen Ihres Vertriebsschalters, es nimmt nur die Wiedereingabe und das Telefonat rund um sie weg.

Kann das Portal mehrere Sprachen?

Ja, und das sollte es auch – aber legen Sie den Umfang je Phase fest. Katalogübersetzungen, Sprachpräferenz je Konto und übersetzte Belege sind drei verschiedene Aufgaben; starten Sie Phase 1 in den Sprachen, die Ihre aktiven Märkte in Bestellungen verwenden, und ergänzen Sie den Rest mit echter Nachfrage. Die Steuerungspunkte – ein Verantwortlicher für Übersetzungen, ein Aktualisierungsweg – stehen im Abschnitt zu Sprachen und Währungen oben.

Wem gehören die Daten?

Ihnen – Konten, Preise, Bestellungen, Belege und Historie bleiben Unternehmensdaten, im ERP. Das lohnt sich im Vertrag mit demjenigen, der das Portal baut, ausdrücklich zu benennen: Hosting-Zugang, Quellcode oder Konfiguration und der Export Ihrer Daten beim Ausstieg, alles namentlich. Die Outsourcing-Seite behandelt geistiges Eigentum und Ausstiegsbedingungen im weiteren Kontext des Entwicklungsauftrags.

Wie binden wir Distributoren an?

Beginnen Sie mit den Konten, die am meisten bestellen, laden Sie sie persönlich ein und geben Sie ihnen in der ersten Nachricht drei Dinge: ihren Login, ihre Preisliste sichtbar auf dem Schirm und eine Ansprechperson zum Anrufen. Beobachten Sie dann das Signal, das wirklich zählt – nicht die Logins, sondern den Anteil der Nachbestellmenge, der über das Portal kommt. Parallelbetrieb (im Portal bestellt, telefonisch bestätigt) ist wochenlang normal; er endet, wenn das Portal bei Preisen und Belegen nachweisbar richtig liegt – genau dafür sind die Abnahmetests oben da.

Quellen und Standards

• Der hier beschriebene typische Funktionsumfang (Konten, Preislisten je Konto, Nachbestellung, Rechnungen und Gutschriften, Sichtbarkeit je Konto, Rollen mit Limits, Skonti, Zahlungsdienstleister) folgt den von Anbietern für B2B-Bestellportale allgemein beschriebenen Fähigkeiten; auf dieser Seite wird kein Performance-Ergebnis, keine Kosten und kein Zeitplan behauptet.
• Betriebsmodelle (ERP-nahes Portal; Handelsplattform wie Shopify, über Middleware oder Konnektoren mit dem ERP synchronisiert) werden als die zwei wiederkehrenden Wege beschrieben; es wird keine Partnerschaft mit einem Plattformanbieter behauptet.
• Aussagen zu Prozessen und Steuerung folgen den Seiten dieser Website: Eigenbau versus Standard-ERP, RFP-Checkliste für Lieferanten, Odoo für Handelsunternehmen und IT-Outsourcing aus der Türkei (Datenschutzpflichten, IP- und Ausstiegsbedingungen, Pilotdesign).
• Auf dieser Seite erscheinen keine Kundenbeispiele, Portalbudgets oder Projektdauern; Scope, Phasen und kommerzielle Bedingungen werden projektspezifisch im Angebot festgelegt.

Weiterführende Seiten

Softwareentwicklung · Eigenbau versus Standard-ERP · RFP-Checkliste für Lieferanten · Odoo ERP für Handelsunternehmen · Internet-Marketing · Angebot anfordern