Technologie

Software Due Diligence bei SaaS-Übernahmen: ein Branchenleitfaden

Jacek Podoba
CEO, Altimi
August 12, 2026
9
min read

Jede technische Due Diligence betrachtet dieselben großen Bereiche: Architektur, Codequalität, Infrastruktur, Sicherheit, Skalierbarkeit, Team. Eine generische Checkliste, angewendet auf ein SaaS-Unternehmen, verfehlt jedoch das, was über den Ausgang eines SaaS-Deals tatsächlich entscheidet. Bei Software-as-a-Service liegen einige wenige technische Befunde unmittelbar unter jenen Zahlen, die einen Käufer am meisten interessieren - Bruttomarge, Net Revenue Retention, die Glaubwürdigkeit des Wachstumsplans - und sie verhalten sich anders als in einem Dienstleistungsgeschäft, einem lizenzierten On-Premise-Produkt oder einem Marktplatz.

In diesem Leitfaden geht es um genau diesen Unterschied. Er führt durch die Dimensionen einer Software Due Diligence, die am stärksten ins Gewicht fallen, wenn das Zielunternehmen ein SaaS-Anbieter ist, durch die für das Modell typischen Warnsignale und durch die Frage, wie sich ein technischer Befund als das lesen lässt, was er meist ist: ein Bewertungssignal. Die Perspektive ist durchgehend käuferseitig: Was ein Erwerber vor der Unterzeichnung verstehen muss und warum das SaaS-Modell dafür belohnt, an einigen Stellen genauer hinzusehen als an anderen.

Warum SaaS verändert, wonach eine Software Due Diligence sucht

Ein SaaS-Unternehmen monetarisiert dieselbe Software wiederholt über viele Kunden hinweg, und genau das verleiht dem Modell seine Margen und seine Skalierbarkeit. Ebenso macht es die technischen Fundamente ungewöhnlich tragend. In einem Dienstleistungsunternehmen sind die Menschen der Engpass. Bei SaaS ist es die Architektur. Diese eine Tatsache ordnet die Prioritäten einer Software Due Diligence neu.

Daraus folgen drei Konsequenzen. Erstens rückt die Infrastrukturökonomie von einer Backoffice-Frage zu einem zentralen Bewertungsfaktor, denn bei SaaS sind die Kosten für den Betrieb der Software die Herstellungskosten, und sie fließen direkt in die Bruttomarge. Zweitens entscheidet die Fähigkeit auszuliefern - Funktionen zu ergänzen, Anforderungen von Konzernkunden zu erfüllen und sich in deren Systemlandschaft zu integrieren - darüber, ob die Net Revenue Retention kompoundiert oder abfließt, sodass Liefergeschwindigkeit eine kommerzielle und nicht nur eine technische Kennzahl ist. Drittens konzentriert die mandantenfähige Architektur, die SaaS effizient macht, zugleich das Risiko: Ein Sicherheitsfehler oder eine Skalierungsgrenze ist nicht das Problem eines Kunden, sondern das aller Kunden auf einmal. Eine Software Due Diligence für ein SaaS-Ziel muss diese drei Bereiche entsprechend gewichten, statt alle acht Prüffelder als gleichermaßen entscheidend zu behandeln.

Die Dimensionen, die am stärksten ins Gewicht fallen

Mandantenfähigkeit und die Architektur unter der Marge

Die erste Frage in einer SaaS-Software-Due-Diligence lautet, wie die Mandantenfähigkeit tatsächlich funktioniert. Eine sauber mandantenfähige Plattform, auf der Kunden die Infrastruktur sicher teilen und die darauf ausgelegt ist, die nächsten tausend Mandanten ohne lineare Kosten aufzunehmen, ist ein grundlegend anderes Asset als ein System, das in der Praxis still zu einem Ein-Mandanten-System geworden ist und dedizierte Ressourcen je Kunde hochfährt, weil echte Isolation nie gebaut wurde. Das zweite sieht in der Gewinn- und Verlustrechnung wie SaaS aus, bis das Wachstum es offenlegt und die Marge mit der Skalierung nicht mehr steigt. Das ist einer der folgenreichsten Befunde der Branche und zugleich einer der von außen am wenigsten sichtbaren, denn beide Modelle verkaufen dasselbe Abonnement.

Infrastrukturkosten als Anteil am Umsatz

Eng damit verbunden und als eigene Position lohnenswert ist die Frage, was der Betrieb der Plattform im Verhältnis zu ihren Erträgen kostet, im Zeitverlauf verfolgt. Bei SaaS ist dieses Verhältnis ein direkter Indikator für die Qualität der Bruttomarge und dafür, ob das Modell so skaliert, wie der Plan unterstellt. Ein steigender Infrastrukturanteil bei gleichbleibender oder wachsender Kundenzahl deutet auf Überdimensionierung, auf die Unfähigkeit, Kapazität zwischen Mandanten zu teilen, oder auf jahrelang gepflegte Workarounds hin, deren Beseitigung eine zu große Änderung gewesen wäre. Ein Käufer, der einen SaaS-Multiplikator zahlt, zahlt für eine Marge, die mit der Skalierung wächst, weshalb ein Beleg für das Gegenteil die These direkt trifft.

Sicherheit, Compliance und die Enterprise-Obergrenze

Für jedes SaaS-Unternehmen, das ins gehobene Segment verkauft, sind Sicherheit und Compliance keine Hygiene, sondern eine Schranke für den adressierbaren Markt. SOC 2, ISO 27001, DSGVO-Reife, solide Authentifizierung und Zugriffskontrolle sowie ein belastbarer Audit-Trail entscheiden darüber, ob man um Konzernkunden konkurriert oder bereits am Sicherheitsfragebogen ausgefiltert wird. Eine Software Due Diligence muss nicht nur feststellen, ob die Zertifizierungen bestehen, sondern ob die Architektur sie überhaupt tragen kann, denn Mandantenisolation oder Zugriffskontrollen in ein nicht dafür entworfenes System nachzurüsten, ist ein Programm und kein Häkchen. Wo die Lücke architektonisch ist, entsprechen ihre Kosten jenem Marktsegment, das das Unternehmen derzeit nicht erreichen kann.

Liefergeschwindigkeit und der Bezug zur Retention

Bei SaaS ist die Roadmap ein Instrument der Kundenbindung. Kunden bleiben, weil das Produkt einen immer größeren Teil ihres Problems löst, und sie gehen, wenn es stockt. Deshalb ist die Gesundheit der Liefermaschine - CI/CD-Reife, Testabdeckung in risikoreichen Bereichen, Release-Frequenz und die Zeit von der Entscheidung bis zur Produktion - ein Frühindikator der Net Revenue Retention. Eine Software Due Diligence sollte geringe Liefergeschwindigkeit nicht als rein technisches Thema lesen, sondern als künftige Abwanderung, die in den Zahlen noch nicht sichtbar ist, denn ein Produkt, das nicht ausliefern kann, verliert am Ende jenen Expansionsumsatz, auf dem der SaaS-Multiplikator aufbaut.

Datenarchitektur und KI-Reife

Zunehmend ist die Fähigkeit eines SaaS-Unternehmens, KI-gestützte Funktionen zu ergänzen, ein Bestandteil seines Werts, und diese Fähigkeit hängt davon ab, ob die Daten kohärent und zugänglich sind oder über Mandanten und Speicher verstreut, ohne nutzbares Modell. Eine Software Due Diligence muss KI- und Datenreife heute als vorausschauende Wertdimension bewerten: nicht, ob das Unternehmen heute KI einsetzt, sondern ob seine Architektur sie ohne Neubau tragen könnte. Für einen Käufer, dessen These eine KI-gestützte Produkterweiterung umfasst, kann das der Befund sein, an dem der Plan gelingt oder scheitert.

Schlüsselpersonenrisiko in einer gründergebauten Codebasis

Viele SaaS-Unternehmen stehen zum Transaktionszeitpunkt noch nahe an ihrem gründenden Engineering-Team, und kritisches Wissen über Mandantenfähigkeit, Abrechnungslogik, Integrationen und Incident Response liegt oft bei wenigen Personen ohne formalisierte Verantwortlichkeit. In einem Geschäft, dessen gesamter Wert in der Kontinuität eines laufenden Dienstes besteht, ist das ein wesentliches Risiko und keine organisatorische Fußnote. Eine Software Due Diligence legt es gerade deshalb offen, weil es selten in einem Dokument steht; es zeigt sich erst im Gespräch mit dem Engineering-Team.

Für das SaaS-Modell typische Warnsignale

Manche Befunde sind in den meisten Softwareprodukten gewöhnlich und bei SaaS alarmierend. Dedizierte Infrastruktur je Kunde, als Mandantenfähigkeit verkleidet, ist das klarste, denn es deckelt die Margengeschichte, von der die Bewertung abhängt. Infrastrukturkosten, die schneller wachsen als der Umsatz, sind aus demselben Grund ein weiteres. Eine Sicherheitsarchitektur, die die vom Wachstumsplan unterstellten Zertifizierungen nicht tragen kann, ist ein drittes, weil sie den adressierbaren Markt still deckelt. Nicht gesteuerte Open-Source-Abhängigkeiten und unklare Lizenzierung wiegen bei SaaS schwerer als bei On-Premise-Software, weil der Dienst kontinuierlich ausgeliefert wird und ein Lizenzproblem eine laufende Exponierung ist statt eines ausgelieferten Artefakts. Und ein Lieferprozess, der so weit verlangsamt ist, dass die Roadmap davon geprägt wird, was sich sicher anfassen lässt, statt davon, was Kunden brauchen, ist ein Retention-Risiko im Gewand einer technischen Unannehmlichkeit.

Die Erfahrung aus über hundert käuferseitigen Prüfungen bestätigt das in der Branche. Bei einer SaaS-Plattform für Betreiber mit mehreren Standorten überzeugten Produkt-Markt-Passung und ein stabiles Team, doch kritisches Systemwissen war auf wenige Personen ohne formalisierte Verantwortlichkeit konzentriert, was das Risikoprofil nach der Übernahme veränderte. Bei einer anderen, einer SaaS-Plattform mit starker Händlerbasis in Mittel- und Osteuropa, wirkte die Retention solide, während Dependency-Governance und CI/CD-Reife hinter der Größe der Plattform zurücklagen. Keines dieser Themen zeigte sich in den kommerziellen Kennzahlen, und beide mussten in den Plan nach dem Closing einfließen.

Einen Befund als Bewertungssignal lesen

Der Zweck einer SaaS-Software-Due-Diligence ist nicht, das Engineering zu benoten. Er besteht darin, technische Befunde in die Sprache des Deals zu übersetzen. Ein Mandantenfähigkeitsproblem ist eine Margengeschichte. Eine Sicherheitslücke ist eine Geschichte über den adressierbaren Markt. Langsame Auslieferung ist eine Retention-Geschichte. Konzentriertes Wissen ist eine Kontinuitätsgeschichte. Jeder dieser Befunde wird in einer Verhandlung erst dann verwendbar, wenn er eine Schätzung des Behebungsaufwands trägt und einen Platz in einer nach Schweregrad geordneten Risikomatrix, sodass das Investment Committee keine Mängelliste sieht, sondern eine Reihe bepreister, priorisierter Entscheidungen.

Diese Übersetzung ist zugleich das, was aus einer Prüfung einen Plan für die Zeit nach dem Closing macht. Jeder Befund, der einer Maßnahme und einem Werthebel zugeordnet ist, wird zu einer Position in den ersten hundert Tagen statt zu einer Überraschung im zweiten Jahr, was bei einem SaaS-Asset - wo Marge und Retention kompoundieren - den Unterschied ausmacht zwischen gekauftem Tempo und geerbtem Problem.

Wie Altimi SaaS-Software-Due-Diligence angeht

Altimi erbringt käuferseitige technische Due Diligence für Private-Equity-Häuser, Venture-Capital-Fonds und Wachstumsinvestoren in Europa, mit ausgeprägter Erfahrung im SaaS-Segment unter über hundert käuferseitigen Prüfungen und mehr als 150 Engineering-Projekten. Die Prüfung erfolgt zum Festpreis in einem vor Kickoff vereinbarten Scope innerhalb von zwei Wochen und liefert ein komiteereifes Paket: einen RAG-bewerteten Bericht, eine nach Schweregrad geordnete Risikomatrix mit Go- oder No-Go-Empfehlung, eine Bewertung von Skalierbarkeit und KI-Reife, eine Einschätzung der Team- und Delivery-Reife sowie eine 90-Tage-Roadmap zur Wertschöpfung. Für ein SaaS-Ziel gewichtet die Prüfung jene Bereiche, die eine SaaS-Bewertung bewegen - Mandantenfähigkeit und Infrastrukturökonomie, die Sicherheitslage als Schranke für den Vertrieb an Konzernkunden, Liefergeschwindigkeit als Retention-Signal und Datenarchitektur als Signal der KI-Reife - statt eine flache Checkliste anzuwenden.

Unabhängigkeit ist dabei ein Arbeitsprinzip: Altimi arbeitet ausschließlich für den Investor, zu einem Festhonorar ohne Anreize für Folgeaufträge, legt frühere Verbindungen zum Zielunternehmen offen und lehnt Mandate mit wesentlichem Interessenkonflikt ab. Da Altimi als Technologiepartner SaaS-Systeme auch baut und modernisiert, kann die von einer Prüfung empfohlene Sanierung vom selben Team umgesetzt werden, was die tatsächlichen Kosten der Umsetzung senkt. Als in der EU ansässige, nach ISO 27001 zertifizierte Organisation hält Altimi Quellcode und Transaktionsdaten über den gesamten vertraulichen Prozess innerhalb des europäischen Datenschutzraums.

Hinweis für Transaktionen in Europa und CEE

Bei SaaS-Übernahmen in Mittel- und Osteuropa, der DACH-Region und dem weiteren europäischen Markt ist die Compliance-Dimension oft der schärfste Werttreiber, weil sie so direkt auf den adressierbaren Markt abbildet. DSGVO-, ISO-27001- und SOC-2-Reife sowie die Sicherheitserwartungen von Konzernkunden entscheiden, in welche Segmente ein SaaS-Unternehmen verkaufen kann, sodass eine Lücke dort eine in den Deal eingepreiste Wachstumsbremse ist. Wo das Zielunternehmen in einer Jurisdiktion tätig ist und der Fonds in einer anderen berichtet, wiegt es ebenso schwer wie die Befunde selbst, Quellcode und Kundendaten während der Prüfung innerhalb des europäischen Datenschutzraums zu halten, weshalb ein in der EU ansässiger, zertifizierter Anbieter bei grenzüberschreitenden SaaS-Transaktionen mehr ist als eine Bequemlichkeit.

Eine Software Due Diligence für eine SaaS-Übernahme ist keine generische technische Prüfung mit SaaS-Etikett. Das Modell legt spezifisches Gewicht auf einige wenige technische Befunde - wie die Mandantenfähigkeit wirklich funktioniert, was der Betrieb der Plattform kostet, ob die Sicherheit den Wachstumsplan tragen kann, ob die Auslieferung die Retention stützt und ob die Daten eine KI-Geschichte tragen - weil jeder davon unmittelbar unter der Marge, der Retention und der Skalierbarkeit liegt, die ein SaaS-Multiplikator bepreist. So gelesen, ist ein technischer Befund selten nur technisch. Er ist die Bewertung, eine Ebene tiefer betrachtet.

Wenn Sie ein SaaS-Ziel prüfen und eine Bewertung wünschen, die die Treiber eines SaaS-Multiplikators anspricht, ist ein kurzes Gespräch über das Unternehmen und die These der schnellste Einstieg.

FAQ

FAQ - Software Due Diligence bei SaaS-Übernahmen: ein Branchenleitfaden

Wie unterscheidet sich eine Software Due Diligence für ein SaaS-Unternehmen von einer generischen technischen Prüfung?

Die untersuchten Bereiche überschneiden sich, doch die Gewichtung ändert sich. Bei SaaS trägt die Architektur die Marge und die Skalierbarkeit, sodass Infrastrukturökonomie, Mandantenfähigkeit, Sicherheit als Schranke für den Enterprise-Markt und Liefergeschwindigkeit als Retention-Signal stärker ins Gewicht fallen als in einem Dienstleistungsgeschäft oder bei einem On-Premise-Produkt. Eine generische Checkliste behandelt alle Felder gleich; eine SaaS-bewusste Prüfung konzentriert sich am stärksten auf die technischen Befunde, die unter einer SaaS-Bewertung liegen.

Was ist das Wichtigste, das man in einer SaaS-Technikprüfung prüfen sollte?

Wenn es eine einzelne Sache gibt, dann wie die Mandantenfähigkeit tatsächlich funktioniert. Eine wirklich mandantenfähige Plattform skaliert mit verbessernder Marge, während eine, die still dedizierte Ressourcen je Kunde bereitstellt, wie SaaS aussieht, bis das Wachstum eine flache oder sinkende Marge bei Skalierung offenlegt. Da beide dasselbe Abonnement verkaufen, ist das von außen leicht zu übersehen und, einmal gefunden, folgenreich, weshalb eine SaaS-fokussierte Prüfung es zuerst feststellt.

Warum ist Sicherheit gerade für die SaaS-Bewertung so wichtig?

Weil für jedes SaaS-Unternehmen, das an mittelständische oder Konzernkunden verkauft, Sicherheit und Compliance den adressierbaren Markt begrenzen. Fehlende SOC 2 oder ISO 27001, schwache Zugriffskontrollen oder ein fehlender Audit-Trail führen dazu, dass ein Anbieter am Sicherheitsfragebogen ausgefiltert wird, sodass die Lücke kein Hygienethema ist, sondern eine Umsatzgrenze. Wo der Rückstand architektonisch und nicht prozessual ist, ist seine Schließung ein Arbeitsprogramm, dessen Kosten in das Deal-Modell gehören.

Lässt sich Liefergeschwindigkeit wirklich als kommerzielle Kennzahl behandeln?

Bei SaaS ja. Die Roadmap ist der Weg, über den ein Produkt Accounts hält und ausbaut, sodass eine verlangsamte Liefermaschine - durch schwache CI/CD, dünne Testabdeckung oder Code, den das Team meidet - ein Frühindikator für Abwanderung ist, die noch nicht in den Zahlen erscheint. Langsame Auslieferung als künftiges Retention-Risiko statt als rein technisches Thema zu lesen, ist einer der charakteristischen Schritte einer SaaS-bewussten Software Due Diligence.

Bewertet eine SaaS-Due-Diligence die KI-Fähigkeit?

Sie bewertet die KI-Reife als vorausschauende Wertdimension, was etwas anderes ist als die Prüfung, ob das Unternehmen heute KI einsetzt. Die Frage lautet, ob die Daten kohärent sind und die Architektur KI-gestützte Funktionen ohne Neubau tragen könnte, denn für einen Käufer, dessen These eine KI-gestützte Produkterweiterung umfasst, ist diese Reife Teil dessen, wofür er zahlt. Ein fragmentierter Datenbestand kann ein ansonsten attraktives SaaS-Asset still unfähig machen, so zu kompoundieren, wie der Plan es unterstellt.

Articles you might be interested in

Mehr als der Coding-Assistent: Wie sich KI über den gesamten SDLC einbetten lässt

September 8, 2026
Minutes

Strangler Fig statt Big Bang: der schrittweise Weg zur Legacy-Modernisierung

September 7, 2026
Minutes

KI-Due-Diligence: Was PE-Fonds 2026 wissen müssen

September 7, 2026
Minutes