Konzernabschluss: drei Standorte, drei Zahlen

4 Min. Lesezeit

Drei Werke, drei ERP-Instanzen, drei Zahlen. Fragt der Beirat nach dem Quartalsumsatz, liefert jeder Standort eine andere Summe. Abstimmen lässt sich das nur mit Tagen Handarbeit im Controlling. Das ist keine Schlamperei. Es ist eine Architekturentscheidung, die vor Jahren niemand bewusst getroffen hat. Wer Niederlassungen über Landesgrenzen führt, kennt die Wahl zwischen lokaler Hoheit und zentralem Überblick. Sie muss kein Entweder-oder sein.

Verwandt:Die ERP-Wartungsfalle im Mittelstand  /  Wenn der Agent die Eingangsrechnung selbst bucht

Wenn jede Niederlassung ihre eigene Wahrheit pflegt

Der Ablauf wiederholt sich in vielen wachsenden Mittelständlern. Ein Großkunde wird in der Zentrale angelegt. Drei Tage später bestellt die Filiale unter einer eigenen Kundennummer, ein dritter Standort rechnet mit abweichenden Zahlungszielen ab. Niemand hat bewusst falsch gebucht. Das System lässt es nur so zu.

Dasselbe passiert mit Artikeln, Lieferanten und Preisen. Was ein Werk als einen Artikel führt, sind anderswo zehn Varianten. Beim Konzernabschluss treffen diese Welten aufeinander. Die Differenz kostet das Controlling regelmäßig mehrere Tage Abstimmung pro Periode. Am Ende steht die Frage, wem ein Datensatz eigentlich gehört.

Zentral oder dezentral, beides hat seinen Preis

Üblich sind zwei Antworten. Alles zentral erzwingen bringt sauberes Reporting, doch die Standorte verlieren ihre örtlichen Eigenheiten und blockieren. Jeder macht sein Ding hält alle vor Ort zufrieden, im Mutterhaus sieht dann aber niemand mehr durch. Der dritte Weg entscheidet sich an Kriterien statt an Prinzipien.

Föderierte Datenhaltung, in einem Satz erklärt

Jede Niederlassung arbeitet in einer eigenen Instanz auf einem unabhängigen Datenschema. Lokale Felder, eigene Belegarten und örtliche Erweiterungen bleiben erhalten. Zentral legt das Unternehmen nur fest, welche Stammdaten alle teilen: zentrale Kundennummern, Artikelkerne oder Preislogiken, während die lokale Lagerlogik lokal bleibt. Drei Festlegungen tragen das Modell. Wer einen Datensatz besitzt, in welche Richtung er synchronisiert und welche Regel im Konflikt gilt.

Ein Praxisbeispiel: Klienten statt Einheitsinstanz

Ein Beispiel aus dem deutschsprachigen Raum liefert das österreichische Softwarehaus Multidata. Den Ansatz nennt es Klientenkonzept, umgesetzt auf der Plattform MD-Premium. Unternehmen richten eigene Instanzen für Länderorganisationen oder Filialen ein, jede auf einem eigenen Datenschema mit lokaler Flexibilität. Zentral legen sie fest, welche Daten geteilt und wie sie synchronisiert werden.

Zwei Einordnungen halten das Bild gerade. Das Modell ist eine programmierbare Plattform im eigenen Betrieb, kein Cloud-Produkt, das die Frage per Hyperscaler löst. Und der unterschiedliche steuerliche Rahmen mehrerer Länder ist der Kontext, in dem das System lokale Anforderungen technisch abbildbar macht. Die steuerliche Bewertung selbst bleibt Sache der Fachleute vor Ort.

Die Fehler, die Föderation scheitern lassen

Föderation scheitert selten an der Technik. Sie scheitert an fehlenden Regeln, immer an denselben Stellen.

Vier Fragen vor der Entscheidung

Diese vier Fragen trennen die saubere Architektur vom Datenchaos. Wer sie beantworten kann, hat die Hälfte der Arbeit erledigt.

1. Wer besitzt im Konfliktfall den Kunden-, Artikel- und Lieferantenstamm?
2. Welche Felder müssen konzernweit gleich sein, welche dürfen lokal abweichen?
3. Wie oft und in welche Richtung werden geteilte Daten abgeglichen?
4. Wie schnell lässt sich ein zugekaufter Standort anbinden?

Lokale Hoheit und zentraler Überblick sind kein Gegensatz. Sie sind eine Entscheidung, die ein Haus einmal sauber trifft. Wer die Regeln nicht schreibt, bekommt sie trotzdem. Dann schreibt sie jeder Standort selbst. Beim nächsten Quartalsende liefert der Beirat wieder drei Zahlen.

Häufige Fragen

Bildquelle: KI-generiert (Juni 2026)