Mandantenfähigkeit: was sie kostet, wenn man sie zu spät einplant

In Anforderungslisten taucht das Wort meistens als einzelne Zeile auf, irgendwo zwischen Rechteverwaltung und Export: „System muss mandantenfähig sein.” Eine Zeile, ein Häkchen, nächster Punkt.

Das ist die teuerste Zeile des Dokuments. Mandantenfähigkeit ist keine Funktion, die sich wie ein zusätzliches Feld ergänzen lässt. Sie ist eine Entscheidung über den Aufbau der Daten, und sie wirkt sich auf praktisch jede Stelle aus, an der später Daten gelesen, geschrieben, ausgewertet oder gelöscht werden. Wer sie am Anfang trifft, zahlt einen überschaubaren Aufschlag. Wer sie nachträglich einzieht, baut große Teile des Systems neu.

Was Mandantenfähigkeit tatsächlich bedeutet

Ein Mandant ist eine abgeschlossene Einheit innerhalb derselben Anwendung: ein Kundenunternehmen, eine Tochtergesellschaft, ein Standort, ein Verband. Alle Mandanten nutzen dieselbe laufende Software, aber jeder sieht ausschließlich seine eigenen Daten, hat seine eigenen Benutzer, seine eigenen Einstellungen und oft seine eigenen Stammdaten.

Der Punkt, an dem die meisten Missverständnisse entstehen: Es geht nicht darum, fremde Datensätze auszublenden. Ausblenden ist eine Eigenschaft der Oberfläche, und Oberflächen kann man umgehen. Es geht darum, dass eine Abfrage fremde Daten gar nicht erst zurückgibt — unabhängig davon, welche Kennung jemand in eine Adresszeile schreibt oder welchen Wert eine Schnittstelle übergibt.

Drei Fälle führen typischerweise zu dieser Anforderung:

1. Sie bieten Ihre Software anderen Unternehmen an. Dann ist Mandantenfähigkeit das Geschäftsmodell und nicht verhandelbar.
2. Ihr Unternehmen besteht aus mehreren Gesellschaften, die getrennte Zahlen, getrennte Berechtigungen und getrennte Auswertungen brauchen.
3. Sie verwalten Daten für Ihre Kunden — als Dienstleister, Verwaltung oder Vermittler. Auch das sind Mandanten, selbst wenn niemand das Wort benutzt.

Die drei Bauweisen

Es gibt drei etablierte Wege, Mandanten zu trennen. Sie unterscheiden sich weniger im Funktionsumfang als im Betrieb und in der Frage, was passiert, wenn ein Fehler durchrutscht.

Bauweise	Wie getrennt wird	Aufwand beim Bau	Aufwand im Betrieb	Wann sie passt	Das Risiko
Gemeinsame Datenbank, Mandantenkennung in jeder Tabelle	Jeder Datensatz trägt eine Mandantenkennung, jede Abfrage filtert darauf	Mittel — wenn von Anfang an so gebaut	Am geringsten: eine Datenbank, eine Aktualisierung	Viele kleine bis mittlere Mandanten, ähnliche Anforderungen	Eine vergessene Filterbedingung zeigt fremde Daten
Ein eigener Datenbankbereich je Mandant	Gleiche Struktur, getrennte Ablage je Mandant	Höher: Struktur muss mehrfach gepflegt werden	Mittel — jede Änderung muss überall ankommen	Wenige, größere Mandanten mit Sonderwünschen	Auseinanderlaufende Stände zwischen den Mandanten
Eine eigene Datenbank je Mandant	Vollständige Trennung bis auf die Anwendung	Am höchsten	Am höchsten: Sicherung, Aktualisierung, Überwachung je Mandant	Hohe Trennungsanforderungen, wenige Mandanten, eigene Aufbewahrung	Der Betrieb wird zum eigentlichen Kostentreiber

Für die meisten Vorhaben im Mittelstand ist die erste Bauweise richtig. Sie ist am günstigsten zu bauen und am günstigsten zu betreiben — und sie ist die einzige, bei der ein Fehler unmittelbar Daten preisgibt. Deshalb gehört zu ihr zwingend eine Absicherung, die nicht davon abhängt, dass ein Entwickler an jeder einzelnen Stelle daran denkt.

Warum die Trennung nicht in der Oberfläche liegen darf

Wenn die Mandantentrennung darin besteht, dass jede Abfrage im Programmcode eine zusätzliche Bedingung enthält, dann ist sie so verlässlich wie die Sorgfalt der Person, die die nächste Abfrage schreibt. Bei 50 Abfragen geht das gut. Bei 500, verteilt über drei Jahre und mehrere Entwickler, geht es irgendwann nicht mehr gut.

Tragfähig ist deshalb eine Trennung, die erzwungen wird und nicht erinnert werden muss: Der Mandant wird einmal an zentraler Stelle aus der Anmeldung bestimmt, und jeder Datenzugriff läuft durch eine Schicht, die diesen Filter selbst setzt. Dazu kommt eine Regel auf Datenbankebene, die verhindert, dass ein Datensatz ohne gültige Mandantenkennung überhaupt entstehen kann.

Der Prüfstein dafür ist einfach und lässt sich jedem Anbieter stellen: Was passiert, wenn ein angemeldeter Benutzer die Kennung eines fremden Datensatzes in die Adresszeile schreibt? Die richtige Antwort ist „er bekommt eine Fehlermeldung, und der Versuch steht im Protokoll” — nicht „das kann er nicht sehen, weil es nicht verlinkt ist”.

Was nachträglich alles betroffen ist

Der Grund, warum die späte Einführung so teuer wird, ist nicht die Datenbankspalte. Die ist schnell ergänzt. Es ist alles, was danach kommt.

• Jede vorhandene Abfrage muss geprüft und um den Filter ergänzt werden — auch die, die selten läuft und die niemand mehr kennt.
• Jeder Bestandsdatensatz braucht rückwirkend eine Zuordnung. Bei Daten aus mehreren Jahren ist das oft eine inhaltliche Frage, keine technische.
• Eindeutigkeiten verschieben sich. Eine Kundennummer, eine Rechnungsnummer oder eine E-Mail-Adresse war bisher systemweit eindeutig. Künftig ist sie es nur noch je Mandant — und jede Stelle, die sich auf die alte Eindeutigkeit verlassen hat, ist zu ändern.
• Auswertungen brechen. Jede Kennzahl muss beantworten, ob sie je Mandant oder über alle Mandanten hinweg gilt. Das ist der aufwendigste Teil und der, den fast alle Aufwandsschätzungen übersehen.
• Importe, Exporte und Schnittstellen müssen den Mandanten mitführen. Eine Datei ohne Mandantenbezug ist nach der Umstellung nicht mehr zuordenbar.
• Rechte werden zweidimensional. Vorher: Was darf diese Rolle? Nachher: Was darf diese Rolle in welchem Mandanten? Dazu kommen Benutzer, die mehreren Mandanten angehören.
• Protokolle und Löschungen brauchen den Mandantenbezug, sonst lässt sich weder nachvollziehen noch sauber löschen.

Der letzte Punkt ist mehr als eine Ordnungsfrage. Wenn ein Mandant das System verlässt, muss sich sein Datenbestand vollständig ausgeben und anschließend löschen lassen, ohne dass die Daten der übrigen Mandanten Schaden nehmen. Bei personenbezogenen Daten ist das eine Pflicht aus der DSGVO und nicht optional. In einem System, das nachträglich mandantenfähig gemacht wurde, ist genau diese Löschung erfahrungsgemäß der Punkt, an dem auffällt, wo überall noch ein Mandantenbezug fehlt.

Die Stellen, an denen es in der Praxis schiefgeht

Nicht die Hauptmaske ist das Problem. Die wird zuerst gebaut und am gründlichsten geprüft. Es sind die Nebenwege:

• Der Bericht, der direkt auf die Datenbank geht, weil es damals schneller ging.
• Der nächtliche Lauf, der ohne angemeldeten Benutzer arbeitet und deshalb keinen Mandanten kennt.
• Der Dateiablageort, in dem Anhänge aller Mandanten in einem gemeinsamen Verzeichnis liegen.
• Die Suche, die über alle Datensätze geht, weil sie einen eigenen Index nutzt.
• Der Zwischenspeicher, der eine Antwort für Mandant A aufbewahrt und sie Mandant B ausliefert.
• Die Fehlermeldung per E-Mail, in der ein vollständiger Datensatz steht — samt Namen aus einem fremden Mandanten.
• Der Zugang für den Betreuer, der aus guten Gründen alles sehen darf und deshalb der gefährlichste Zugang des Systems ist.

Diese sieben Stellen gehören auf jede Prüfliste vor der Abnahme. Sie tauchen in keinem Lastenheft von selbst auf — wie man ein Lastenheft aufbaut, damit solche Punkte nicht durchrutschen, steht in Lastenheft: Struktur und Vorlage.

Ein Beispiel aus dem Betrieb

Wie das aussieht, wenn Mandantenfähigkeit von Anfang an das Fundament ist, lässt sich an einem Projekt zeigen, das wir entwickelt haben und betreiben: train4safety, eine Plattform für digitale Arbeitsschutz-Unterweisungen. Sie gehört der Junghanns safe4u GmbH & Co. KG in Metten-Berg, ist seit 2026 im Betrieb und wird von über 500 Unternehmen genutzt.

Jedes dieser Unternehmen ist ein Mandant mit eigenen Standorten, eigenen Schulungsinhalten und den Personaldaten seiner Beschäftigten. Diese Daten dürfen sich unter keinen Umständen berühren, und die Trennung muss dort erzwungen werden, wo gelesen wird — nicht in der Oberfläche. Dazu kommt eine Anforderung, die in mandantenfähigen Systemen regelmäßig unterschätzt wird: Ein neuer Mandant muss sich einrichten lassen, ohne dass jemand in die Datenbank eingreift. Sonst wächst mit jedem Kunden die Handarbeit, und das Betriebsmodell trägt nicht. Die ausführliche Einordnung steht in der Fallstudie train4safety.

Brauchen Sie das wirklich?

Mandantenfähigkeit kostet Geld, und sie ist nicht in jedem Fall die richtige Antwort. Diese vier Fragen trennen die Fälle:

1. Werden die Daten der Einheiten voneinander getrennt gebraucht — oder nur getrennt angezeigt? Wenn eine Filterung in der Ansicht genügt und alle demselben Unternehmen angehören, reicht eine Rechteverwaltung.
2. Kann eine Einheit dazukommen oder wegfallen, ohne dass jemand die Datenbank anfasst? Wenn nicht, ist es keine Mandantenfähigkeit, sondern eine Konfiguration.
3. Haben die Einheiten unterschiedliche Verantwortliche für ihre Daten? Sobald zwei verschiedene Unternehmen für ihre Daten geradestehen, brauchen Sie echte Trennung — auch aus datenschutzrechtlichen Gründen.
4. Ist es denkbar, dass Sie die Anwendung in fünf Jahren einem Dritten anbieten? Wenn ja, ist das die günstigste Zeile, die Sie jetzt bezahlen können.

Wenn Sie dreimal Nein antworten, bauen Sie besser ohne Mandanten und sparen den Aufschlag. Wenn Sie einmal Ja antworten und es später doch brauchen, ist die Umstellung kein Zusatz, sondern ein zweites Projekt.

Was das kostet

Ein internes System beginnt bei uns bei 7.500 € netto. Mandantenfähigkeit ist darin kein eigener Posten, sondern eine Eigenschaft der Datenstruktur — sie erhöht den Aufwand für Konzept, Datenmodell, Rechte und Tests, und sie erhöht ihn spürbar. Der Aufschlag ist überschaubar, solange er zu Beginn eingeplant wird, und er ist es nicht mehr, wenn er nachträglich anfällt.

Was den Preis darüber hinaus bewegt: die gewählte Bauweise aus der Tabelle oben, die Frage, ob Auswertungen über Mandanten hinweg gebraucht werden, ob Benutzer mehreren Mandanten angehören können, und ob jeder Mandant eigene Stammdaten, eigene Vorlagen oder ein eigenes Erscheinungsbild bekommt. Die Preislogik im Ganzen steht unter Kosten; die laufenden Posten nach dem Start — Sicherungen, Aktualisierungen, Überwachung — behandelt Betriebskosten nach dem Start. Beim Betrieb ist der Unterschied zwischen den drei Bauweisen erheblich, deshalb gehört diese Entscheidung ins Konzept und nicht in die Entwicklung.

Wenn Sie vor dieser Entscheidung stehen, ist der schnellste Weg zu einer belastbaren Antwort ein Blick auf Ihre konkrete Situation: wie viele Einheiten es gibt, wer für welche Daten geradesteht und ob über sie hinweg ausgewertet werden muss. Beschreiben Sie das kurz im Erstgespräch, oder sehen Sie sich an, was wir unter interne Systeme übernehmen.