Eine Unternehmensgruppe wächst selten geradlinig. Aus einem Betrieb werden eine Vertriebsgesellschaft, ein Produktionswerk und ein zugekaufter Fachhändler, jeder mit eigenem Buchungskreis im ERP. Der Vertrieb möchte trotzdem einen Shop: ein Katalog, ein Login, ein Warenkorb. Zwischen diesem Wunsch und der Buchhaltung liegt die eigentliche Arbeit, denn jede Gesellschaft führt eigene Artikelnummern, eigene Nummernkreise, eigene Lagerorte und eigene Steuerkennzeichen. Wer diese Trennung im Shop nachbaut, betreibt am Ende drei Shops. Wer sie ignoriert, erzeugt Belege, die sich in der Buchhaltung nicht mehr zuordnen lassen. Dieser Beitrag zeigt, wie eine mandantenfähige Middleware die Trennung dort hält, wo sie hingehört, nämlich in den Regeln, und wie die ERP-Anbindung im Großhandel auch nach dem nächsten Zukauf ohne zweiten Shop auskommt.
Das Wichtigste in Kürze
- Ein Shop kann mehrere ERP-Mandanten bedienen, wenn jede Zeile im Warenkorb genau eine liefernde Gesellschaft trägt. Diese Zuordnung gehört in eine Routing-Regel der Middleware und nicht in den Artikelstamm des Shops.
- Überlappende Sortimente brauchen einen fachlichen Schlüssel über allen Mandanten. Die GTIN, in Europa üblicherweise mit 13 Ziffern (GS1), und die GLN mit ebenfalls 13 Ziffern je Standort und Rechtsträger (GS1) taugen als Anker, wenn interne Artikelnummern kollidieren.
- Rechnungsnummern dürfen je Gesellschaft in eigenen Kreisen laufen: Gefordert ist eine vom Aussteller einmalig vergebene fortlaufende Nummer (Umsatzsteuergesetz). Buchungsbelege sind 8 Jahre aufzubewahren, Bücher und Jahresabschlüsse 10 Jahre (Abgabenordnung).
- Währung und Steuerfindung hängen an der liefernden Gesellschaft, nicht am Shop. Ab 10.000 Euro unionsweitem Umsatz aus Fernverkäufen und elektronischen Dienstleistungen greift die Besteuerung im Bestimmungsland (EU-Kommission), und die Zusammenfassende Meldung ist oberhalb von 50.000 Euro je Quartal monatlich abzugeben (Umsatzsteuergesetz).
- Betrifft ein Warenkorb zwei Gesellschaften, entstehen zwei Aufträge und zwei Rechnungen. Für den Kunden bleibt es eine Bestellung, wenn Auftragsaufteilung, Versandkostenlogik und Statusanzeige zusammen entworfen werden.
Warum Gruppen mehrere Mandanten führen und trotzdem einen Shop wollen
Mandanten im ERP sind keine technische Spielerei, sondern die Abbildung von Rechtsträgern. Sobald ein Mutterunternehmen beherrschenden Einfluss auf ein anderes Unternehmen ausübt, entsteht die Pflicht zum Konzernabschluss (Handelsgesetzbuch); jede Tochter bleibt dabei buchhalterisch eigenständig und stellt ihren eigenen Jahresabschluss auf. Dazu kommen Gründe, die im Tagesgeschäft schwerer wiegen als jede Bilanzvorschrift: Eine Ländergesellschaft braucht eine eigene Umsatzsteuer-Registrierung, ein zugekaufter Betrieb bringt seine gewachsenen Nummernkreise und Konditionen mit, und ein Produktionswerk bewertet Bestände anders als ein Handelsbetrieb. Wer diese Trennung im ERP aufhebt, verliert die Grundlage für Steuererklärung, Abschluss und Betriebsprüfung. Die Mandantentrennung ist deshalb kein Altlastenproblem, das eine Shop-Einführung nebenbei beseitigt, sondern eine gesetzte Randbedingung.
Der Vertrieb sieht dieselbe Gruppe von der anderen Seite. Der Einkäufer auf der Gegenseite bestellt Werkzeug und Verbrauchsmaterial in einem Vorgang und hat kein Interesse daran, aus welchem Buchungskreis die Ware kommt. Zwei Shops bedeuten für ihn zwei Zugänge, zwei Warenkörbe und zwei Versandkostenschwellen. Jeder zusätzliche Schritt im Bestellablauf kostet Abschlüsse: Über zahlreiche ausgewertete Studien hinweg liegt die dokumentierte Kaufabbruchquote bei rund 70 % (Baymard Institute). Die Aufgabe lautet also nicht, die Gesellschaften zu verschmelzen, sondern sie im Frontend unsichtbar und im Backend sauber getrennt zu halten. Genau dazwischen sitzt die Integrationsschicht.
Welcher Mandant liefert welchen Artikel
Die grundlegende Entscheidung lautet: Jede Zeile im Warenkorb trägt genau eine liefernde Gesellschaft. Nicht der Kunde, nicht der Auftrag, sondern die einzelne Position. Sobald das feststeht, lassen sich Lagerort, Nummernkreis, Währung und Steuerfindung daraus ableiten, statt sie einzeln zu pflegen. Woher die Zuordnung stammt, ist eine Frage der Datenhoheit, die in der Stammdatensynchronisation zwischen ERP, Shop und CRM grundsätzlich geklärt wird. Für die Praxis genügen meist wenige Kriterien, die in einer festen Reihenfolge ausgewertet werden. Wichtig ist nur, dass die Regel an einer Stelle liegt und nicht als Sonderfall in Shop, ERP und Versandsoftware dreifach gepflegt werden muss.
Sortimentszuschnitt
Führt genau eine Gesellschaft eine Warengruppe, ist die Zuordnung statisch und lässt sich am Artikelstamm hinterlegen.
Lieferland
Sendungen in bestimmte Länder laufen über die dortige Gesellschaft, weil Registrierung, Zoll und Retourenweg daran hängen.
Verfügbarkeit
Führen zwei Mandanten denselben Artikel, entscheidet der Bestand am Standardlager, ergänzt um eine feste Vorrangregel.
Kundenzuordnung
Ein Rahmenvertrag mit einer Gesellschaft bindet die Bestellung an diesen Mandanten, auch wenn eine andere ebenfalls liefern könnte.
Konditionen
Preislisten und Rabattstaffeln liegen je Gesellschaft vor; die Zuordnung entscheidet daher auch über den gültigen Preis.
Rückfallregel
Trifft keine Regel zu, greift ein definierter Standardmandant. Ein stillschweigendes Raten der Zuordnung ist der teurere Weg.
Doppelte Artikelnummern und überlappende Sortimente
Zwei gewachsene Mandanten führen dieselbe Schraube unter zwei Nummern, und irgendwo führen sie zwei verschiedene Artikel unter derselben Nummer. Beides ist normal und beides bricht einen Shop, der interne ERP-Nummern als Schlüssel verwendet. Der Ausweg ist ein Schlüssel, der über den Mandanten steht. Handelsübliche Artikel tragen eine GTIN, in Europa üblicherweise mit 13 Ziffern (GS1); Standorte und rechtliche Einheiten lassen sich über die GLN mit ebenfalls 13 Ziffern eindeutig benennen (GS1). Wo keine GTIN existiert, tritt ein zusammengesetzter Schlüssel aus Mandantenkennung und interner Nummer an ihre Stelle. Wie dieses Mapping technisch aufgebaut und dokumentiert wird, beschreibt der Beitrag zum Daten-Mapping zwischen ERP und Shop im Detail.
Der fachliche Schlüssel gehört über den Mandanten
# Zuordnung je Warenkorbzeile: welche Gesellschaft liefert
schlüssel: GTIN, ersatzweise Mandantenkennung + interne Nummer
regel 1: sortiment = "Werkzeug" -> gesellschaft 1000
regel 2: sortiment = "Verbrauchsmaterial" -> gesellschaft 2000
regel 3: lieferland in (NL, BE, LU) -> gesellschaft 2000
regel 4: bestand(1000) = 0 und bestand(2000) > 0 -> gesellschaft 2000
standard: -> gesellschaft 1000
zeile.gesellschaft = erste zutreffende regel
zeile.lagerort = standardlager(zeile.gesellschaft)
zeile.nummernkreis = auftragskreis(zeile.gesellschaft)
zeile.steuerfindung = sitzland(gesellschaft) + lieferland + ust-idMandantenscharfe Nummernkreise für Aufträge und Rechnungen
Sobald der Shop Aufträge in mehrere Mandanten schreibt, braucht jede Gesellschaft ihren eigenen Nummernkreis. Das ist keine Ordnungsliebe, sondern Voraussetzung für eine prüfbare Buchhaltung. Eine Rechnung muss eine fortlaufende Nummer tragen, die der Aussteller einmalig vergibt (Umsatzsteuergesetz) - mehrere getrennte Zahlenreihen sind ausdrücklich zulässig, solange innerhalb einer Reihe keine Nummer doppelt auftaucht. Genauso wichtig ist die Aufbewahrung: Buchungsbelege sind 8 Jahre, Bücher, Inventare und Jahresabschlüsse 10 Jahre aufzubewahren (Abgabenordnung). Wer Belege zweier Gesellschaften in denselben Kreis schreibt, hat spätestens bei der nächsten Prüfung ein Zuordnungsproblem, das sich nachträglich kaum sauber auflösen lässt. Die Regeln dafür gehören in die Warenwirtschaftsanbindung und nicht in ein Skript, das jemand vor drei Jahren geschrieben hat.
- Kreis je Gesellschaft und Belegart: Getrennte Reihen für Auftragsbestätigung, Lieferschein, Rechnung und Gutschrift, jeweils mit einem Präfix, das den Buchungskreis erkennbar macht.
- Vergabe im führenden System: Die Nummer entsteht dort, wo der Beleg gebucht wird, also im ERP. Der Shop zeigt sie an, erfindet sie aber nicht selbst.
- Shop-Referenz getrennt halten: Die Bestellnummer des Shops ist eine eigene Kennung für den Kunden und ersetzt die Belegnummern der Gesellschaften nicht.
- Lücken vermeiden, Abbrüche protokollieren: Reservierte, aber letztlich ungebuchte Nummern sollten nachvollziehbar sein, damit eine Lücke in der Reihe erklärbar bleibt.
- Rückweg absichern: Storno und Gutschrift laufen im Kreis derselben Gesellschaft, sonst passen Ausgangs- und Korrekturbeleg buchhalterisch nicht zusammen.
Währungen und Steuerkennzeichen je Gesellschaft
Die Währung hängt an der liefernden Gesellschaft und an der Preisliste, nicht an der Sprachauswahl im Shop. Technisch ist das unspektakulär, weil Währungen über dreistellige alphabetische Codes eindeutig benannt sind (ISO) und Länder über zweistellige Codes (ISO). Fachlich beginnt hier trotzdem die Arbeit: Ein Katalogpreis in Euro, eine Schweizer Vertriebsgesellschaft und ein Kunde mit Rahmenvertrag in Landeswährung ergeben drei Preisbildungen, die je Mandant hinterlegt und je Warenkorbzeile ausgewertet werden. Rundungsregeln und Umrechnungskurse gehören dabei in den führenden Datenbestand des ERP, damit Shop und Rechnung denselben Betrag ausweisen.
Steuerlich entscheidet die Kombination aus Sitzland der liefernden Gesellschaft, Lieferland und Status des Kunden. Für innergemeinschaftliche Fernverkäufe an Privatkunden gilt eine unionsweite Schwelle von 10.000 Euro; oberhalb davon wird im Bestimmungsland besteuert und über eine einzige Anlaufstelle gemeldet (EU-Kommission). Im B2B-Geschäft verlagert sich die Steuerschuld in vielen Konstellationen auf den Leistungsempfänger (Umsatzsteuergesetz), was eine belastbare Prüfung der Umsatzsteuer-Identifikationsnummer voraussetzt; die qualifizierte Bestätigungsabfrage liefert dafür den Nachweis (Bundeszentralamt für Steuern). Und die Zusammenfassende Meldung ist oberhalb von 50.000 Euro je Quartal monatlich abzugeben (Umsatzsteuergesetz). Wie diese Logik im Checkout ohne Sonderfälle im Code abgebildet wird, zeigt der Beitrag zur Steuerfindung im B2B-Shop.
| Kriterium | Ein Shop je Gesellschaft | Ein Shop über alle Mandanten |
|---|---|---|
| Katalogpflege | Je Shop einmal, vervielfachter Aufwand | Einmal zentral, das Routing bestimmt die Herkunft |
| Kundensicht | Mehrere Zugänge und Warenkörbe | Ein Konto, ein Warenkorb, ein Bestellverlauf |
| Artikelnummern | Kollisionen bleiben unbemerkt | Fachlicher Schlüssel über allen Mandanten |
| Nummernkreise | Je Shop getrennt, ohne Bezug zueinander | Je Gesellschaft getrennt, im Beleg nachvollziehbar |
| Steuerfindung | Je Shop fest verdrahtet | Aus Gesellschaft, Lieferland und Kundenstatus abgeleitet |
| Zukauf anbinden | Neuer Shop, neues Projekt | Neuer Mandant, ergänzter Regelsatz |
| Betriebsaufwand | Wächst mit der Zahl der Gesellschaften | Wächst mit der Zahl der Regeln |
Lagerorte und Bestandsaggregation über Gesellschaften
Bestände über Gesellschaftsgrenzen zu addieren ist verlockend und in den meisten Fällen verkehrt. Was im Lager der niederländischen Tochter liegt, gehört bilanziell dieser Tochter; es dem Kunden als Verfügbarkeit der deutschen Gesellschaft anzuzeigen, erzeugt eine Zusage, die nur über einen konzerninternen Verkauf einzulösen ist. Sinnvoll ist eine gestufte Anzeige: der Bestand der zugeordneten Gesellschaft als verbindliche Menge, der Bestand verbundener Gesellschaften als verlängerte Lieferzeit. Die Mechanik dahinter unterscheidet sich technisch wenig von der Bestandssynchronisation über mehrere Lager; neu ist allein, dass jeder Lagerort zusätzlich einem Buchungskreis zugeordnet sein muss.
Zwei Stolpersteine tauchen dabei regelmäßig auf. Erstens die Reservierung: Wird im Shop eine Menge blockiert, muss klar sein, in welchem Mandanten sie blockiert wird, sonst verkaufen zwei Gesellschaften dieselbe Palette. Zweitens die Mengeneinheit. Dieselbe Ware wird in einer Gesellschaft in Stück und in einer anderen im Gebinde geführt, was jede Aggregation still verfälscht, wenn die Umrechnung fehlt; die Fallstricke dazu behandelt der Beitrag über Mengeneinheiten und Gebinde aus dem ERP. Beide Punkte lassen sich früh entschärfen, wenn Lagerorte, Buchungskreise und Einheiten in einer gemeinsamen Tabelle gepflegt werden, statt sie aus drei Systemen zusammenzusuchen.
Kundenstamm mehrfach vorhanden: Zuordnung beim Login
Ein Kunde, der seit Jahren bei zwei Gesellschaften der Gruppe kauft, existiert im ERP zweimal, mit zwei Debitorennummern, zwei Zahlungszielen und womöglich zwei Ansprechpartnern. Im Shop soll er sich einmal anmelden. Die Lösung ist ein Shop-Konto, das auf mehrere Debitoren zeigt, statt eines Kontos je Debitor. Beim Login lädt die Integrationsschicht alle zugeordneten Debitoren, ermittelt daraus die freigegebenen Sortimente und die gültigen Konditionen und stellt die Zuordnung je Warenkorbzeile her. Welche Sortimente ein Kunde überhaupt sehen darf, ist dieselbe Fragestellung wie bei der Kundenfreischaltung mit kundenindividuellen Sortimenten, nur um die Mandantenachse erweitert.
Zwei Details verdienen dabei besondere Aufmerksamkeit. Erstens die Identität: Eine E-Mail-Adresse taugt als Login, aber nicht als fachlicher Schlüssel, weil derselbe Einkäufer für zwei Standorte des Kunden bestellen kann. Standorte und Rechtsträger lassen sich über die GLN eindeutig benennen (GS1), was die Zuordnung stabil hält, wenn sich Adressen ändern. Zweitens das Kreditlimit: Es wird je Debitor geführt, nicht je Shop-Konto. Ein Warenkorb, der beide Gesellschaften betrifft, prüft daher zwei Limits, und die Anzeige im Checkout muss verständlich bleiben, ohne interne Buchungskreise offenzulegen.
Wenn ein Warenkorb zwei Gesellschaften betrifft
Der Regelfall im Großhandel ist der gemischte Warenkorb. Sobald er entsteht, teilt die Integrationsschicht ihn in zwei Aufträge auf, je einen pro Gesellschaft, jeder mit eigenem Nummernkreis, eigener Rechnung und eigenem Lieferschein. Für den Kunden bleibt es eine Bestellung mit einer Bestellnummer, unter der beide Teilaufträge im Konto zusammenlaufen. Diese Aufteilung ist unspektakulär, solange drei Fragen vorab beantwortet sind: Wie werden Versandkosten verteilt, wie wird eine Mindestbestellmenge bewertet, und was passiert, wenn ein Teilauftrag im ERP abgelehnt wird, während der andere bereits gebucht ist.
Die Alternative zur Aufteilung ist das Reihengeschäft: Eine Gesellschaft verkauft an den Kunden und bezieht die Ware konzernintern von der Schwestergesellschaft. Umsatzsteuerlich ist das kein Nebenschauplatz, denn in einer solchen Reihe gilt nur eine Lieferung als die bewegte Lieferung (Umsatzsteuergesetz), und die Zuordnung dieser Warenbewegung ist unionsweit geregelt (EU-Kommission). Welcher Weg passt, entscheidet die Steuerabteilung und nicht die Technik; die Integrationsschicht muss beide abbilden können. Wie sich der Checkout verhält, wenn ein Mandant vorübergehend nicht antwortet, behandelt der Beitrag zum Notbetrieb bei ERP-Ausfall.
Trennung gehört in die Regeln, nicht in die Oberfläche
Konzerninterne Weiterberechnung und getrennte Belegablage
Liefert die Schwestergesellschaft die Ware, entsteht ein konzerninterner Umsatz, der bepreist werden muss. Maßstab ist der Fremdvergleichsgrundsatz: Verrechnungspreise zwischen verbundenen Unternehmen sollen den Bedingungen entsprechen, die unabhängige Dritte vereinbart hätten (OECD). Für die Anbindung bedeutet das eine zweite Preisebene neben dem Kundenpreis, die je Mandantenpaar gepflegt und dokumentiert wird. Im Konzernabschluss werden diese Innenumsätze anschließend wieder herausgerechnet, unter anderem über Schulden- und Zwischenergebniskonsolidierung (Handelsgesetzbuch). Damit das gelingt, müssen die entsprechenden Belege als konzernintern gekennzeichnet in die Buchhaltung gelangen und nicht als gewöhnliche Ausgangsrechnung.
Der Belegweg selbst läuft je Gesellschaft getrennt: eigener Mandant, eigener Kontenrahmen, eigene Belegkreise. Eine DATEV-Anbindung bildet das ab, indem sie je Buchungskreis einen eigenen Export erzeugt, statt alles in einen Stapel zu schreiben. Formal steigt der Druck ohnehin: Inländische Unternehmen müssen elektronische Rechnungen bereits seit dem 1. Januar 2025 empfangen können (Bundesfinanzministerium), und die Übergangsfrist für den Versand endet für Unternehmen mit höchstens 800.000 Euro Gesamtumsatz im Vorjahr am 31. Dezember 2027 (Bundesfinanzministerium). Wie sich die Belegübergabe praktisch automatisieren lässt, beschreibt der Beitrag zur DATEV-Automatisierung im E-Commerce.
Rechteschnitt und Berichte je Gesellschaft
Mit mehreren Mandanten wird die Frage, wer was sehen darf, zu einer fachlichen Anforderung. Der Vertriebsleiter der deutschen Gesellschaft soll deren Aufträge auswerten, nicht die der niederländischen; die Konzernleitung möchte beide sehen, gruppiert nach Gesellschaft. Praktikabel ist ein Rechteschnitt entlang des Buchungskreises: Jede Rolle trägt eine Liste erlaubter Mandanten, und jede Abfrage im Backend filtert darauf, bevor sie Daten liefert. Dasselbe gilt für Schnittstellen: Ein Zugang, der nur Aufträge einer Gesellschaft schreiben darf, begrenzt den Schaden bei einem kompromittierten Schlüssel erheblich. Wie solche Zugänge geschnitten, versioniert und protokolliert werden, gehört in die Konzeption der API-Entwicklung und nicht in eine nachträgliche Härtung. Berichte sollten entsprechend zwei Ebenen kennen: die Sicht je Gesellschaft für das operative Geschäft und die konsolidierte Sicht für die Gruppe, wobei die konsolidierte Sicht Innenumsätze erkennbar ausweist.
Rollout-Reihenfolge bei Zukäufen
- Mit dem umsatzstärksten Mandanten beginnen: Er liefert die meisten Sonderfälle und damit den belastbarsten Regelsatz für alle weiteren Gesellschaften.
- Sortimentsüberschneidung vorab erheben: Vor dem Anschluss klären, welche Artikel in mehreren Mandanten geführt werden und welcher Schlüssel sie zusammenführt.
- Lesend anfangen: Katalog, Preise und Bestände des neuen Mandanten zunächst nur lesen und im Shop verborgen prüfen, bevor Aufträge zurückgeschrieben werden.
- Nummernkreise und Steuerkennzeichen abnehmen: Je Gesellschaft einen vollständigen Testbeleg durch SAP oder ein anderes führendes System bis in die Buchhaltung ziehen.
- Kundenstamm zusammenführen: Bestehende Debitoren des zugekauften Betriebs auf vorhandene Shop-Konten abbilden und Dubletten vor der Freischaltung auflösen.
- Regelsatz und Betrieb übergeben: Routing-Regeln, Mandantenzuordnungen und Überwachung dokumentiert übergeben, damit der übernächste Zukauf ohne Archäologie auskommt; die Grundlage dafür legt eine mandantenfähige Middleware mit sauber getrennten Regelsätzen je Gesellschaft.
Ein Shop wird nicht dadurch mandantenfähig, dass er die Gesellschaften versteckt, sondern dadurch, dass er jede Zeile eindeutig einer zuordnen kann.
Quellen und Studien