SaaS-Wildwuchs im KMU stoppen: Wie kleine Unternehmen 2026 Kosten, Schatten-IT und unnoetige Lizenzen wieder in den Griff bekommen

• Weil viele KMU steigende SaaS-Ausgaben sehen, aber nicht wissen, welche Kosten vermeidbar sind, wo Schatten-IT und doppelte Tools entstehen und ab wann manuelle Listen nicht mehr reichen. Der Beitrag liefert dafür ein umsetzbares Prüf- und Entscheidungsmodell.
• Die Originalität liegt in der Synthese mehrerer sonst getrennter Disziplinen: FinOps, IdP-/Admin-Daten, Procurement, Vertragsfristen, Governance und Exit-Portabilität. Statt generischer 'SaaS Waste'-Behauptungen zeigt der Beitrag, welche Daten und Prozesssignale KMU tatsächlich prüfen sollten.

Den Beitrag frueh als vendor-neutralen Governance-Leitfaden positionieren: SaaS Spend Management ist fuer KMU zuerst eine Frage von Transparenz, Ownership, Nutzungsdaten und Vertragslogik, nicht von pauschalen Sparversprechen oder Tool-Hype.

Welche SaaS-Kostenarten in kleinen Unternehmen wirklich anfallen – jenseits der sichtbaren Monatsgebühr

In vielen kleinen Unternehmen beginnt die Kostenbetrachtung bei SaaS noch immer mit dem sichtbarsten Wert: dem Preis pro Nutzer und Monat. Für die Praxis reicht das jedoch nicht. Das FinOps Framework beschreibt SaaS-Kosten breiter und bezieht neben dem Listenpreis auch Vertragsbedingungen, Renewal-Termine, Commitments, Secondary Metrics und mögliche Overage-Mechaniken ein. Genau deshalb ist SaaS-Ausgabensteuerung weniger ein Preisvergleich als eine Frage sauberer Kostenlogik.

Wichtig ist vor allem: Eine Anwendung kostet nicht nur das, was auf der Rechnung als Grundgebühr steht. Viele Tarife kombinieren feste und variable Bestandteile. Offizielle Dokumentation zu nutzungsbasierten Modellen zeigt typische Muster wie feste Grundgebühr plus Mehrverbrauch, reines Pay-as-you-go oder Credit-basierte Abrechnung. Für KMU bedeutet das: Kosten steigen nicht nur mit zusätzlichen Mitarbeitenden, sondern oft auch mit Nutzung, Volumen oder Funktionsumfang.

Für eine belastbare Gesamtkostenbetrachtung lohnt es sich deshalb, mindestens sechs Blöcke getrennt zu erfassen:

• Basisgebühren für Seats, Nutzer oder Pakete. Das ist der sichtbare Teil der Kosten, aber selten der ganze.
• Variable Nutzungskosten. Dazu zählen etwa Mehrverbrauch, verbrauchsabhängige Abrechnung oder Kontingente, die bei Überschreitung teurer werden.
• Zusatzmodule und Funktionsstufen. Sicherheit, Compliance, Automatisierung, Analytics oder Premium-Support werden oft separat bepreist.
• Vertragslogik. Commitments, Laufzeiten, Verlängerungen und Abrechnungsgrenzen beeinflussen die tatsächliche Wirtschaftlichkeit erheblich.
• Interner Betriebsaufwand. Benutzerverwaltung, Rollenpflege, Rechnungsprüfung, Renewal-Vorbereitung und Abstimmung zwischen Fachbereich, IT und Einkauf kosten ebenfalls Zeit und damit Geld.
• Kosten durch fehlende Transparenz. Wenn Rechnungen, Nutzungsdaten und Vertragsdaten getrennt voneinander liegen, wird SaaS zwar bezahlt, aber kaum aktiv gesteuert.

Das FinOps Framework empfiehlt deshalb ausdrücklich, Billing-Daten, Anbieter- und Lizenzdaten sowie Business-Kontext zusammenzuführen, statt nur Rechnungsbeträge zu sammeln. Erst diese Kombination zeigt, ob eine Ausgabe tatsächlich sinnvoll ist: Ein günstiger Vertrag kann teuer werden, wenn Nutzungsspitzen regelmäßig Aufschläge auslösen. Umgekehrt bringt auch ein gut verhandelter Rabatt wenig, wenn Lizenzen falsch zugeschnitten sind oder Renewal-Fristen ohne Nutzungsabgleich weiterlaufen.

Auch Beschaffung ist damit kein reines Einkaufsthema. Laut FinOps wirken ausgehandelte Preise, Volumenprogramme und Vertragsbedingungen nur dann wirtschaftlich, wenn ihre Nutzung und Einhaltung laufend sichtbar bleiben. Für KMU ist das eine wichtige Verschiebung im Denken: Nicht der niedrigste Listenpreis entscheidet, sondern ob Preis, Nutzung und Vertragslogik im Alltag zusammenpassen.

Ein praxistaugliches Raster beginnt daher mit wenigen, aber klar getrennten Fragen: Was ist die feste Grundgebühr? Welche Nutzung kann zusätzliche Kosten auslösen? Welche Add-ons sind aktiviert? Welche Laufzeit- und Renewal-Mechanik gilt? Und wer prüft regelmäßig, ob Vertrag und tatsächlicher Bedarf noch zusammenpassen? Erst mit dieser Sicht entsteht aus einzelnen Monatsgebühren ein belastbares SaaS-Kostenbild.

Woran ungenutzte Lizenzen, Überlizenzierung und doppelte Tools in KMU früh erkennbar sind

Ungenutzte Lizenzen erkennt man in der Praxis selten an einer einzelnen Zahl, sondern an einem Muster: Ein Account ist weiterhin lizenziert oder einer App zugewiesen, zeigt aber über längere Zeit keine relevante Aktivität mehr. Genau dafür sind Admin-Daten wichtig. Microsoft 365 weist in seinen Nutzungsberichten den letzten Aktivitätstermin je App aus und trennt diese Sicht von den Lizenzzuweisungen im Admin Center. Google Workspace stellt ebenfalls App-Nutzungsberichte pro Nutzer bereit. Für KMU ist das der erste saubere Abgleich: bezahlt das Unternehmen noch für einen Zugang, obwohl kaum oder gar keine Nutzung mehr sichtbar ist?

Belegte Warnsignale sind damit vor allem diese:

• Lizenz vorhanden, aber keine aktuelle Nutzung in den Nutzungs- oder Aktivitätsberichten.
• Zuweisung bleibt bestehen, obwohl sich Rolle oder Team geändert hat.
• Große Differenz zwischen zugewiesenen und tatsächlich aktiven Nutzern einer Anwendung.
• Accounts in Gruppen-Zuweisungen, die aus Administrationssicht noch korrekt wirken, operativ aber nicht mehr benötigt werden.

Gerade Überlizenzierung entsteht in kleinen Unternehmen oft schleichend. Der Auslöser ist nicht immer ein schlechter Einkauf, sondern häufig ein sauber gemeinter Standardprozess: Apps werden gruppenbasiert oder per Bulk-Zuweisung vergeben, damit Onboarding schnell funktioniert. Okta dokumentiert genau diese Mechanik: App-Integrationen lassen sich einzelnen Personen oder ganzen Gruppen zuweisen, und bestehende Assignments sind auf der jeweiligen App sichtbar. Das ist administrativ effizient, erhöht aber das Risiko, dass Zugänge nach Rollenwechseln, Projektende oder Teamumbau nicht konsequent entzogen werden. Redaktionell eingeordnet heißt das: Je stärker ein KMU mit Standardgruppen arbeitet, desto wichtiger wird eine regelmäßige Bereinigung der Gruppenmitgliedschaften und App-Zuweisungen.

Doppelte Tools sind schwerer zu erkennen als reine Shelfware. Das Problem zeigt sich meist nicht als „falsches“ Tool, sondern als funktionale Überschneidung: Zwei Teams nutzen verschiedene Meeting-Tools, drei Abteilungen verwalten Aufgaben in unterschiedlichen Work-Management-Apps oder einzelne Fachbereiche kaufen zusätzlich Speziallösungen, obwohl bereits eine Suite mit ähnlichen Funktionen vorhanden ist. Sichtbar wird das erst, wenn drei Ebenen zusammengeführt werden:

1. Zuweisungsebene: Wer ist welchem Tool überhaupt zugeordnet?
2. Nutzungsebene: Welche dieser zugewiesenen Nutzer sind tatsächlich aktiv?
3. Funktions- und Team-Ebene: Welche Tools decken denselben Anwendungsfall in verschiedenen Bereichen ab?

Für ein KMU ist deshalb eine pragmatische Prüflogik sinnvoll: Nicht sofort kündigen, sondern je Anwendung eine kurze Matrix erstellen aus Nutzerzahl, aktiven Nutzern, letztem Aktivitätssignal, Zuweisungsart (einzeln oder per Gruppe) und primärem Use Case. Erst wenn dabei auffällt, dass mehrere Tools denselben Kernzweck bedienen und jeweils nur Teilgruppen aktiv sind, wird aus normaler Tool-Vielfalt echter Wildwuchs.

Die entscheidende Abgrenzung lautet also: Berechtigte Vielfalt liegt vor, wenn verschiedene Tools klar unterschiedliche Anforderungen, Teams oder Compliance-Vorgaben abdecken. Problematische Redundanz liegt vor, wenn ähnliche Tools parallel bezahlt werden, ohne dass Verantwortliche sauber begründen können, welche Nutzer welches Produkt wirklich benötigen. Vor jeder Kürzung sollten KMU daher nicht nur auf Kosten schauen, sondern auf die Kombination aus Assignment, Aktivität, Teamkontext und Funktionsüberschneidung. Erst diese Sicht macht aus Bauchgefühl eine belastbare Lizenzentscheidung.

Wie Schatten-IT entsteht – und warum zu langsame Freigaben das Problem oft verschärfen

Schatten-IT beginnt in kleinen Unternehmen oft unspektakulär: Ein Team testet ein neues Projekttool mit Firmenadresse, Marketing verbindet einen Dienst per OAuth mit Google Workspace, Vertrieb aktiviert eine Self-Service-SaaS per Karte, oder einzelne Mitarbeitende geben einer App Zugriff auf Kalender, Dateien oder Mailboxen. Technisch ist das kein großer Rollout – organisatorisch aber sehr wohl. Denn sobald Drittanbieter-Apps Datenzugriffe, Nutzerkonten oder wiederkehrende Zahlungen außerhalb des vorgesehenen Freigabewegs erhalten, entsteht ein Teil des SaaS-Bestands außerhalb des offiziellen Inventars.

Gerade in modernen SaaS-Umgebungen ist dieser Weg kurz. Microsoft weist darauf hin, dass Anwendungen vor dem Zugriff auf Organisationsdaten Berechtigungen benötigen und dass Nutzer je nach Tenant-Einstellung selbst Consent erteilen können. Microsoft empfiehlt deshalb, User Consent auf Apps verifizierter Publisher und ausgewählte Berechtigungen zu begrenzen. Google beschreibt ähnlich, dass Admins den Zugriff externer und interner Apps auf Workspace-Daten über OAuth steuern, angeforderte Scopes einsehen und Apps gezielt als vertrauenswürdig oder blockiert markieren können. Daraus folgt für KMU: Schatten-IT entsteht nicht nur über Einkauf und Rechnungen, sondern oft schon über Identitäts-, OAuth- und App-Consent-Prozesse.

Ein zweiter Treiber ist Self-Service-Beschaffung. Viele SaaS-Produkte lassen sich ohne Procurement, ohne Rahmenvertrag und ohne IT-Ticket starten – per Gratisversion, Testaccount oder Monatsabo. Das ist aus Teamsicht effizient, weil kein langes Auswahlverfahren nötig ist. Für die Organisation bedeutet es aber: Es gibt oft keinen benannten Owner, keine abgestimmte Datenklassifizierung, keine definierte Exit-Logik und keine Stelle, die prüft, ob ein ähnliches Tool bereits existiert. NIST betont bei Cloud-Systemen Eigenschaften wie breiten Netzzugang, schnelle Elastizität und Datenfreigabe; genau diese Merkmale machen SaaS operativ attraktiv, erhöhen aber auch die Anforderungen an Zugriffs- und Governance-Modelle. Redaktionell zugespitzt: Wo Anwendungen schnell aktivierbar und sofort kollaborativ nutzbar sind, wächst der Bestand schneller als klassische Freigabe- oder Inventarprozesse nachkommen.

Besonders heikel wird es, wenn Unternehmen Schatten-IT nur mit Verboten beantworten. Microsoft nennt nach einer Einschränkung von User Consent ausdrücklich begleitende Maßnahmen wie Dokumentation, Monitoring, Education und einen zentralen Bewertungsprozess für Anfragen. Der Hintergrund ist praxisnah: Wenn Fachbereiche einen legitimen Bedarf haben, aber kein handhabbarer Freigabepfad existiert, weichen sie leichter auf private oder unmanaged Accounts aus. Auch Gartner formuliert das für den aktuellen AI-Kontext klar: Wer Mitarbeitende nicht in freigegebenen Tools arbeiten lässt, riskiert Ausweichbewegungen in Shadow AI statt kontrollierter Nutzung. Für KMU heißt das nicht, jede App freizugeben. Es heißt aber, dass langsame oder intransparente Freigaben selbst zum Risikotreiber werden können.

Ein belastbarer Gegenansatz ist deshalb keine Verbotslogik, sondern Governance mit kurzer Reaktionszeit. Praktisch heißt das: ein einfacher Intake-Prozess für neue Tools, klare Kriterien für Datenzugriffe, Prüfung von Publisher-Verifikation und OAuth-Scopes, dokumentierte Verantwortliche pro App sowie ein Weg für befristete Tests mit definierter Nachprüfung. So bleibt Innovation möglich, ohne dass Testkonten, Kartenzahlungen und App-Integrationen dauerhaft unter dem Radar laufen. Für kleine Unternehmen ist genau das oft der realistischere Hebel: nicht jede Schatten-IT moralisch zu problematisieren, sondern die Ursachen in Beschaffungswegen, Consent-Modellen und Freigabegeschwindigkeit sichtbar zu machen.

Welche Daten ein belastbares SaaS-Audit braucht: Accounts, Nutzung, Zahlungen, Verträge und Eigentümer

Ein SaaS-Audit ist in KMU nur dann belastbar, wenn es nicht bei einer App-Liste stehenbleibt. Die eigentliche Arbeit besteht darin, mehrere Datenquellen zusammenzuführen, die in der Praxis fast immer getrennt vorliegen: Identitäten und Zugriffe, Nutzungsdaten, Zahlungen, Vertragsinformationen und intern benannte Verantwortliche. Erst aus dieser Kombination wird aus einem groben Tool-Verzeichnis ein steuerbares SaaS-Inventar.

1. Accounts und Zugriffe aus IdP, SSO und Audit-Logs
Die erste Ebene ist die Identitäts- und Zugriffssicht: Welche Nutzer, Gruppen, Rollen, Service-Accounts und App-Objekte existieren überhaupt, welche Anwendungen wurden hinzugefügt oder verändert, und wer hat das veranlasst? Microsoft beschreibt Audit-Logs ausdrücklich als Nachweis für Änderungen an Anwendungen, Gruppen, Nutzern und Lizenzen. Zusätzlich lassen sich über neue Audit-Felder bei Service Principals Herkunft und Auslöser besser nachvollziehen. Für ein Audit heißt das: Neben „welche App ist da?“ gehört immer auch „wer hat sie verbunden, freigegeben oder technisch eingerichtet?“ in die Datensammlung. (learn.microsoft.com)

2. Nutzungsdaten aus den Admin-Konsolen der SaaS-Anbieter
Die zweite Ebene ist die tatsächliche Nutzung. Google Workspace stellt dafür App-Nutzungsberichte bereit, die Aktivitäten pro Nutzer zeigen und als CSV oder Google Sheet exportiert werden können. Microsoft 365 bietet ebenfalls Nutzungsberichte und Exportmöglichkeiten, etwa nach Excel, Power BI oder über die Graph Reports API. Wichtig ist aber die Grenze dieser Daten: Nutzung allein beantwortet nicht die Frage, ob eine Lizenz entbehrlich ist. Sie zeigt Aktivität, aber nicht automatisch die vertragliche oder finanzielle Relevanz. Zudem weist Google darauf hin, dass Berichtsdaten nicht immer tagesaktuell sind. Für KMU ist das ein praktischer Hinweis: Nutzungsdaten sind eine Kernquelle, aber keine alleinige Entscheidungsgrundlage. (support.google.com)

3. Lizenz- und Zuweisungsdaten getrennt von der Nutzung erfassen
Viele Teams vermischen „hat Zugriff“ mit „wird genutzt“ und „wird bezahlt“. Genau diese Gleichsetzung macht Audits unzuverlässig. Microsoft trennt im Admin Center die Nutzungssicht von der Lizenzsicht; Lizenzen liegen unter Billing, Nutzerstatus unter Active users, und es gibt laut Dokumentation keinen einzelnen Bericht, der pro Nutzer alle genutzten Dienste vollständig zusammenführt. Für die Praxis folgt daraus: Ein Audit braucht eine eigene Tabelle oder Datenansicht, in der pro Anwendung mindestens Seat-Zahl, Lizenztyp, Zuweisung, letzte erkennbare Aktivität und betroffene Kostenstelle nebeneinander stehen. (learn.microsoft.com)

4. Zahlungsdaten aus Finance, Karten- und Expense-Systemen
Die vierte Ebene ist die Geldspur. Gerade in KMU tauchen kleinere SaaS-Abos häufig zuerst in Kreditkartenabrechnungen, Spesen-Tools oder Bankumsätzen auf und erst später in offiziellen IT- oder Einkaufssystemen. Redaktionell lässt sich daraus eine einfache Prüfregel ableiten: Alles, was in IdP und Admin-Konsole nicht auftaucht, aber regelmäßig als wiederkehrende Zahlung erscheint, ist ein Kandidat für Schatten-IT oder mindestens für ein unvollständiges Inventar. Umgekehrt gilt dasselbe: Eine im SSO sichtbare App ohne nachvollziehbare Kostenstelle oder Rechnungsweg ist für Governance ebenfalls unvollständig dokumentiert.

5. Vertrags- und Renewal-Daten aus Einkauf und Ablage
Ein SaaS-Audit ohne Vertragsdaten bleibt operativ zu schwach. Die CISA ordnet Software- und SaaS-Bezüge ausdrücklich auch als Beschaffungs- und Vertragsgegenstand ein. Das ist für KMU relevant, weil sich Kündigungsfristen, Laufzeiten, Mindestabnahmen, Zahlungszyklen und Verlängerungsmechaniken meist nicht aus Nutzungsberichten ableiten lassen. In die Audit-Checkliste gehören deshalb pro Anwendung mindestens: Vertragspartner, Startdatum, Laufzeit, Renewal-Termin, Kündigungsfrist, Abrechnungsmodell, Zahlweg und Ablageort des Vertrags. (cisa.gov)

6. Eigentümer statt anonymer Tool-Bestand
Ein Inventar ohne Owner ist nur eine Sammlung von Namen. Sinnvoll ist die Trennung zwischen fachlichem Eigentümer und technischem Eigentümer: Der fachliche Owner verantwortet Zweck, Budget und Nutzen der Anwendung; der technische Owner verantwortet Admin-Zugänge, Integrationen, SSO, Offboarding und Sicherheitskonfiguration. Gerade bei App-Objekten, Service Principals und verbundenen Anwendungen ist diese Zuordnung wichtig, weil technische Einbindungen sonst weiterlaufen können, obwohl im Fachbereich niemand mehr aktiv zuständig ist. Die Microsoft-Dokumentation zu Audit-Logs und Service-Principal-Herkunft stützt genau diesen Punkt: Ohne Ereignis- und Eigentümerbezug bleibt unklar, wer eine Verbindung angelegt hat und wer sie heute verantwortet. (learn.microsoft.com)

Praktische SaaS-Audit-Checkliste für KMU

Für ein erstes belastbares Inventar sollten pro Anwendung mindestens diese Felder vorliegen:

• Anwendungsname und Hersteller
• Kategorie/Zweck der App
• Fachlicher Owner
• Technischer Owner oder Admin-Verantwortlicher
• Nutzerzahl, Gruppen oder zugewiesene Seats
• Erkennbare Nutzung: aktive Nutzer, letzte Aktivität, relevante Nutzungsmetriken
• Identitätsbezug: SSO/IdP angebunden ja/nein, lokale Accounts ja/nein
• Technische Objekte: Service Accounts, OAuth-/Service-Principal-Verknüpfungen, Integrationen
• Kostenbezug: Kostenstelle, Rechnungsadresse, Zahlweg, Monats- oder Jahresbelastung
• Vertragsbezug: Vertragsnummer oder Ablageort, Laufzeit, Renewal-Datum, Kündigungsfrist
• Sicherheitsbezug: Admin-Rollen, Auditierbarkeit, Exportmöglichkeiten für Berichte

Die redaktionelle Kernbotschaft für KMU lautet damit: Ein SaaS-Audit ist kein einmaliger Export aus einer Admin-Konsole. Es ist der Abgleich von Zugriff, Nutzung, Bezahlung und Verantwortung. Fehlt eine dieser vier Sichten, bleibt das Bild lückenhaft – und genau dort entstehen später unklare Renewals, ungenutzte Lizenzen oder Apps ohne verantwortlichen Besitzer.

Procurement, Kündigungsfristen und Vertragslaufzeiten: Wo SaaS-Kosten im Bestand oft festhängen

Wenn in KMU die Nutzung eines Tools sinkt, sinken die Kosten oft trotzdem nicht automatisch mit. Der Grund liegt häufig weniger im fehlenden Sparwillen als in der Vertragslogik des Bestands: automatische Verlängerungen, Kündigungsfenster vor dem Renewal-Datum, feste Laufzeiten und Preisregeln, die erst sichtbar werden, wenn das Handlungsfenster fast schon geschlossen ist. Gerade Standardverträge können solche Mechaniken enthalten, sodass Ausgaben weiterlaufen, obwohl der operative Nutzen bereits geschrumpft ist.

Hinzu kommt ein zweites Muster, das im Alltag leicht übersehen wird: Mehrkosten entstehen nicht nur beim nächsten Neuabschluss. In seat-basierten Modellen können sie bereits innerhalb der laufenden Laufzeit entstehen, etwa wenn zusätzliche Nutzer über das gebuchte Kontingent hinaus angelegt werden und dadurch True-ups oder automatische Plananpassungen greifen. Produktspezifische Dokumentation von Anbietern wie Atlassian und Asana zeigt genau dieses Prinzip: Zusätzliche Nutzer können während einer aktiven Vertragsperiode nachberechnet werden, und bei Überschreiten einer Planstufe kann die Abrechnung automatisch auf ein größeres Nutzerpaket wechseln.

Für die Beschaffung reicht es deshalb nicht, SaaS nur als „Tool plus Monatspreis“ zu erfassen. In der Praxis ist jeder Vertrag eher ein Bündel aus Fristen, Commitments und Zuständigkeiten. Mindestens im Blick sein sollten:

• Laufzeit und Startdatum
• Renewal-Datum
• Kündigungsfrist vor der Verlängerung
• Auto-Renewal-Regel
• Zahlungszyklus
• Seat-Commitment oder Mindestmenge
• Regeln für Zusatznutzer, True-ups oder automatische Plananpassungen
• mögliche Preisänderungen
• zuständiger Billing Owner oder interner Vertragsverantwortlicher

Gerade hier zeigt sich ein typisches KMU-Problem: Vertragsdaten liegen verteilt in E-Mail-Postfächern, beim Einkauf, im Fachbereich und in einzelnen Admin-Konsolen. Dann sinkt zwar die Nutzung, aber niemand prüft rechtzeitig vor dem Notice-Termin, ob Seats reduziert, Tarife angepasst oder Verträge überhaupt noch gebraucht werden. Die praktische Konsequenz ist klar: Ein SaaS-Audit sollte nicht erst zum Renewal starten, sondern deutlich davor. Nur dann bleibt genug Zeit, um Bedarf, Nutzerzahl und vertragliche Handlungsoptionen sauber gegenzuprüfen.

Ab wann Excel, Einkauf und Admin-Konsole nicht mehr reichen

Der entscheidende Kipppunkt ist meist kein fester Schwellenwert bei der Zahl der Tools, sondern wachsende Prozesskomplexität. Solange wenige Anwendungen genutzt werden, Owner klar benannt sind und Vertragsdaten, Zugriffe und Verlängerungen ohne großen Abstimmungsaufwand zusammenpassen, kann eine manuelle Steuerung noch funktionieren. Kritisch wird es dort, wo dieselbe SaaS-Anwendung gleichzeitig in mehreren Logiken verwaltet werden muss: im Identity-Store, in einzelnen Admin-Konsolen und in Vertrags- oder Renewal-Listen. NIST beschreibt für Cloud- und SaaS-Provisioning genau diese Verteilung von Identitäts-, Rollen-, Gruppen- und Berechtigungsdaten über mehrere Verwaltungsebenen. Damit wird aus einer einfachen Bestandsliste schnell ein fortlaufender Abgleich zwischen Identität, Zugriff und Zuständigkeit.

Ein zweites Warnsignal sind Renewals, die operative Nacharbeit auslösen. Dann reicht eine Fristenliste in Excel oft nicht mehr aus. Die ServiceNow-Dokumentation zeigt als konkretes Beispiel, dass bei Verlängerungen neue SKUs entstehen können und manuell gepflegte Nutzer- oder Gruppenzuordnungen anschließend erneut zugewiesen werden müssen. Für KMU ist weniger der einzelne Vendor-Fall entscheidend als das zugrunde liegende Muster: Sobald Vertragsverlängerungen nicht nur kaufmännische Termine sind, sondern Änderungen an Zuordnungen, Produkten oder Verantwortlichkeiten nach sich ziehen, wird SaaS-Verwaltung zu einem wiederkehrenden Abstimmungsprozess zwischen Einkauf, IT und Fachbereich.

Spätestens dann stößt auch die reine Arbeit in einzelnen Admin-Konsolen an Grenzen. Sie beantworten meist nur Fragen zur jeweiligen Anwendung, nicht aber zur Gesamtlage: Wer ist fachlicher Owner, wer bezahlt, welche Gruppe ist tatsächlich zugeordnet, und passt das noch zum aktuellen Organisationszustand? Wenn diese Antworten nur durch manuelles Zusammenziehen aus mehreren Quellen entstehen, steigt das Fehlerrisiko deutlich.

Hinzu kommt die Sicherheits- und Betriebsseite. CISA empfiehlt einen umfassenden Asset-Management-Ansatz und betont, dass Organisationen ihre logischen IT-Assets, also auch Software, verstehen und inventarisieren sollen. Für KMU ist das ein wichtiges Signal: Wenn das SaaS-Inventar nicht mehr nur für Kostenkontrolle gebraucht wird, sondern ebenso für Offboarding, Berechtigungsprüfung, Priorisierung kritischer Systeme oder Reaktionsfähigkeit im Störfall, ist die Grenze manueller Steuerung in der Praxis meist erreicht.

Der passende Entscheidungsrahmen lautet deshalb nicht „ab wie vielen Tools?“, sondern: Wie viele Schnittstellen zwischen Identität, Vertrag, Nutzung und Eigentümerschaft müssen manuell synchron gehalten werden? Je mehr diese Ebenen auseinanderlaufen, desto eher reichen Excel, Einkauf und Einzelkonsole nicht mehr aus.

Wann Spend-Management-Tools sinnvoll werden – und welche Kriterien vor jeder Auswahl sichtbar sein müssen

Spend-Management-Software wird nicht schon deshalb sinnvoll, weil viele SaaS-Tools im Einsatz sind. Relevant wird sie dann, wenn manuelle Listen, einzelne Admin-Konsolen und der Einkauf keine gemeinsame Wahrheit mehr liefern: also wenn Anwendungen entdeckt, Kosten bewertet, Lizenzen mit Nutzung abgeglichen und Renewals rechtzeitig vorbereitet werden müssen. Offizielle Produktdokumentation aus dem SAM-/ITAM-Umfeld zeigt, dass die Kategorie heute typischerweise genau diese Bausteine bündelt: SaaS-Discovery, Subscription- und Lizenzsicht, Nutzungs- und Kosten-Dashboards sowie Renewal-Workflows statt bloßer Erinnerungen. Für KMU ist das weniger eine Frage von „mehr Software“, sondern von Prozessdichte und Datenkonsistenz. Wenn dieselbe Anwendung in Finance, Admin-Konsole und Vertragsspeicher unterschiedlich erscheint, ist der Punkt für ein spezialisiertes System meist erreicht.

Vor jeder Auswahl sollte deshalb zuerst das eigene Problemprofil sichtbar sein. Ein Unternehmen mit vielen dezentral gekauften Tools braucht vor allem Discovery und Ownership-Zuordnung. Ein Unternehmen mit bekannten Anwendungen, aber unklaren Seat-Ständen, braucht eher Nutzungs- und Lizenzabgleich. Und wer vor allem an späten Verlängerungsentscheidungen leidet, braucht belastbares Vertrags- und Renewal-Management. Herstellerdokumentation belegt, dass diese Funktionen zwar oft unter demselben Oberbegriff vermarktet werden, operativ aber verschieden sind: Dashboarding und Kostenübersicht lösen noch kein Renewal-Problem, ein Vertragsworkflow entdeckt noch keine Self-Service-Tools, und reine Discovery ersetzt keinen Governance-Prozess für Genehmigungen und Verantwortlichkeiten.

Ein neutraler Kriterienkatalog beginnt daher mit sechs Prüfblöcken:

1. Discovery: Findet das Tool SaaS-Anwendungen nur über SSO/IdP und direkte Integrationen – oder auch über Self-Service-Käufe, Trials und dezentrale Abos? Gerade Microsoft dokumentiert, dass Admins bei Self-Service-Purchases und Trials Produktname, Käufer, Preis, Ablaufdatum und zugewiesene Nutzer einsehen können. Das zeigt, wie wichtig es ist, auch Einkaufswege außerhalb des klassischen Procurements abzudecken.
2. Lizenz- und Nutzungsabgleich: Zeigt das System nicht nur gekaufte Seats, sondern auch deren tatsächliche Nutzung, Ausnahmen und Optimierungspotenziale? Ohne diese Sicht bleibt Spend-Management reines Rechnungsmanagement.
3. Renewal-Management: Werden Ablaufdaten, wiederkehrende Abrechnung und anstehende Verlängerungen aktiv gesteuert? Microsoft weist ausdrücklich darauf hin, dass wiederkehrende Abrechnung standardmäßig aktiv sein kann und das Abschalten nicht dasselbe ist wie eine sofortige Kündigung. Für die Praxis heißt das: Ein brauchbares Tool muss Renewal-Status und Fristen sauber abbilden, nicht nur Kostenstände.
4. Vertrags- und Änderungslogik: Kann das System auch geplante Änderungen zum nächsten Renewal sichtbar machen, etwa Mengenanpassungen, Produktwechsel oder geänderte Laufzeiten? Gerade diese künftigen Änderungen entscheiden darüber, ob ein Unternehmen nur retrospektiv reportet oder tatsächlich steuern kann.
5. Workflows und Rollenmodell: Lassen sich Eigentümer, Freigaben, Prüfaufgaben und Eskalationen hinterlegen? Ohne klare Zuständigkeiten bleibt selbst gute Datentransparenz folgenlos.
6. Reporting und Governance-Fit: Sind Reports so aufgebaut, dass Finance, IT und Fachbereiche dieselbe Lage unterschiedlich tief auswerten können – etwa nach Kosten, Nutzung, Publisher, Renewal-Fenster oder Verantwortlichem?

Wichtig ist dabei die redaktionelle Trennung zwischen Feature-Fülle und Eignung: Nicht jedes KMU braucht sofort ein System, das Discovery, Verträge, Workflows und Optimierung in voller Tiefe vereint. Sinnvoll wird die Kategorie erst dann wirklich, wenn der manuelle Aufwand strukturell steigt: etwa wenn Self-Service-Käufe sichtbar werden müssen, Renewal-Änderungen zu spät auffallen oder Verantwortliche für Anwendungen regelmäßig unklar sind. Dann ist die entscheidende Auswahlfrage nicht „Welches Tool hat die meisten Features?“, sondern welche Lücke im eigenen Steuerungsmodell geschlossen werden muss – Discovery, Kontrolle, Renewal-Sicherheit oder Governance.

Genau daran sollte sich auch jede Shortlist orientieren. Wer diese Vorarbeit überspringt, kauft leicht eine Plattform, die zwar viele Daten sammelt, aber am eigentlichen Engpass vorbeigeht: zu wenig Sichtbarkeit auf Self-Service-Abos, zu wenig Verknüpfung von Nutzung und Kosten oder zu wenig Kontrolle über Renewals und geplante Vertragsänderungen. Für kleine Unternehmen ist deshalb nicht Marktbreite das erste Kriterium, sondern Passung zur konkreten Problemform.

Warum Exit- und Export-Fragen schon vor dem Kauf geklärt werden sollten

Viele SaaS-Entscheidungen werden noch immer vor allem nach Funktionsumfang, Einführungsaufwand und laufender Gebühr getroffen. Für KMU ist aber oft eine andere Frage mindestens so wichtig: Wie gut lässt sich der Dienst später wieder verlassen? Genau hier zeigt sich, ob ein Tool nur bequem startet oder auch sauber wieder abgelöst, konsolidiert oder gekündigt werden kann.

Der Kernpunkt: Portabilität hängt nicht nur am Vertragsende. Sie hängt auch daran, in welchen Formaten Daten vorliegen, welche Metadaten mitkommen und über welche Exportwege sie überhaupt herausgelöst werden können. NIST betont, dass Interoperabilität und Portabilität in der Cloud wesentlich von standardisierten Datenformaten und Schnittstellen abhängen. Gerade bei SaaS bleiben dabei Lücken, vor allem bei anwendungsspezifischen Daten und Metadaten. Für die Praxis heißt das: Ein vorhandener Export ist noch kein belastbarer Exit.

Deshalb sollten Unternehmen vor Vertragsabschluss präzise nachfragen: Welche Datenbestände sind im Export enthalten? Geht es nur um Stammdaten oder auch um Historien, Anhänge, Berechtigungen und andere strukturrelevante Informationen? Die Cloud Security Alliance empfiehlt, solche Punkte ausdrücklich vertraglich zu regeln. Dazu gehören mindestens das Datenformat, die Dauer der Datenverfügbarkeit nach Vertragsende, der Umfang der bereitgestellten Daten und die Löschpolitik. Diese vier Fragen sind für KMU ein sinnvoller Mindestkatalog, weil sie die häufigsten Exit-Risiken früh sichtbar machen.

Gerade bei personenbezogenen Daten reicht zudem irgendein Download nicht aus. Die ICO-Guidance zur Datenportabilität hebt hervor, dass bereitgestellte Daten strukturiert, gängig und maschinenlesbar sein sollten. Gleichzeitig besteht keine pauschale Pflicht, Systeme technisch vollständig kompatibel zu machen. Übersetzt in den SaaS-Einkauf heißt das: Ein CSV-Export kann formal genügen und praktisch trotzdem zu wenig sein, wenn Beziehungen, Metadaten oder sichere Übertragungswege fehlen.

Ebenso wichtig ist der Blick auf das Vertragsende selbst. Auch dann sind Daten nicht automatisch überall sofort gelöscht. Die ICO weist ausdrücklich darauf hin, dass vollständige unmittelbare Löschung in Backups oder Archiven praktisch nicht immer möglich ist. Umso wichtiger ist es, Löschfristen, Schutzmaßnahmen für Restbestände und den Nachweis des Offboardings vorab zu klären.

Wer diese Fragen erst beim Anbieterwechsel stellt, entdeckt Wechselhürden oft zu spät. Ein belastbarer SaaS-Exit beginnt deshalb nicht mit der Kündigung, sondern mit sauber definierten Export-, Lösch- und Offboarding-Regeln vor dem Kauf.

Was B2B-Teams daraus ableiten sollten

Die Kernaussage zuspitzen, dass KMU zuerst eine gemeinsame Datensicht auf Anwendungen, Nutzung, Vertraege, Renewals und Verantwortliche aufbauen sollten, bevor sie kuerzen, konsolidieren oder spezialisierte Spend-Management-Software auswaehlen.

• Welche SaaS-Kostenarten sollte ein KMU außer der Monatsgebühr systematisch erfassen? TCO-orientiert antworten: Grundgebühren, variable Nutzung, Add-ons, Integrationen, Admin-Aufwand, Commitments, Renewals und Vertragsnebenkosten sauber trennen.
• Wie erkenne ich ungenutzte Lizenzen, ohne produktive Teams versehentlich auszubremsen? Auf Nutzungsberichte, letzte Aktivität, Zuweisungslogik, Rollenwechsel und fachlichen Kontext verweisen statt auf starre Inaktivitätsgrenzen.
• Was zählt in der Praxis als Schatten-IT bei SaaS und AI-Tools? Nicht nur Rechnungen und Kartenkäufe, sondern auch OAuth-Consent, Self-Service-Trials, unmanaged Accounts und App-Verknüpfungen erklären.
• Welche Datenquellen brauche ich für ein erstes belastbares SaaS-Audit? IdP/SSO, Audit-Logs, Admin-Nutzung, Lizenzdaten, Zahlungsdaten, Verträge, Renewal-Termine und Owner in einer Checkliste bündeln.
• Warum laufen SaaS-Kosten trotz geringer Nutzung oft weiter? Vertragsmechaniken wie Auto-Renewal, Notice Periods, True-ups, Seat-Buckets und verteilte Zuständigkeiten erklären.

Quellenlage und offene Punkte

Die Einordnung stuetzt sich auf 8 Quellen. Besonders wichtig ist, dass die wichtigsten Themenbereiche jeweils mit eigener Quellenbasis und nachvollziehbarer Zuordnung behandelt werden.

• Viele praxisnahe Vertrags- und Billing-Muster sind nur über Anbieter-Dokumentation offen zugänglich; sie sollten als Muster, nicht als Marktstandard behandelt werden.
• US-lastige Framework- und Behördenquellen sind fachlich stark, aber nur eingeschränkt auf deutsche KMU-Prozesse übertragbar.
• Gartner dient hier nur als Kontext zu Shadow-AI, nicht als Kernbeleg für operative Aussagen.
• Für Zahlungs- und Expense-Daten fehlen in der Recherche frei zugängliche, vendor-neutrale Primärquellen mit KMU-Fokus.
• Ein Teil der besonders nützlichen Checklistenlogik ist redaktionelle Synthese aus mehreren Primärquellen, nicht wörtliche Aussage einer einzelnen Quelle.