Technische Schulden vor einer Akquisition bewerten

In den meisten Transaktionen werden technische Schulden nicht verschwiegen. Sie werden schlicht nie beziffert. Das Management spricht allgemein davon, dass man sich irgendwann darum kümmern müsse, der Datenraum schweigt dazu, und der Fonds unterschreibt in der Annahme, dass die Technologie den Wachstumsplan schon tragen wird, solange das Produkt läuft und die Kunden zahlen. Die Rechnung kommt später, meist im ersten Jahr nach Closing, wenn sich zeigt, dass jede neue Funktion doppelt so viel kostet wie im Modell unterstellt und die Hälfte des Produktbudgets in die Reparatur des Übernommenen fließt.

Technische Schulden gehören zu den wenigen Risiken, die sich vor der Unterzeichnung messen lassen, und werden dennoch regelmäßig übergangen. Nur rund 15 Prozent der Private-Equity-Transaktionen umfassen eine dedizierte technische Due Diligence, was bedeutet, dass der Kern des Geschäfts in den meisten Fällen auf Vertrauen übernommen wird. Der folgende Beitrag zeigt praxisnah, wie sich technische Schulden vor einer Akquisition bewerten lassen: was sie aus Investorensicht überhaupt sind, wo man sie sucht, wie aus technischen Beobachtungen eine Zahl für das Modell wird und wie eine Bewertung aussieht, die vor einem Investment Committee Bestand hat.

Was technische Schulden aus Investorensicht bedeuten

In Engineering-Gesprächen werden technische Schulden häufig auf Codequalität verkürzt. Für einen Investor ist diese Definition zu eng und im Ergebnis irreführend. Im Transaktionskontext sind technische Schulden die Lücke zwischen dem Zustand, in dem das System heute gebaut ist, und dem Zustand, den es bräuchte, um die Investitionsthese zu tragen. Sieht der Plan vor, den Kundenstamm zu verdoppeln, drei neue Märkte zu erschließen und Partner anzubinden, dann ist Schuld alles, was diesem Plan im Weg steht: eine Architektur, die sich nicht horizontal skalieren lässt, unscharfe Modulgrenzen, die saubere Schnittstellen verhindern, Release-Prozesse, die die Auslieferung bremsen, Sicherheitslücken, die den Zugang zu Konzernkunden versperren.

Daraus folgt ein wichtiger Punkt. Dieselbe Codebasis kann unter einer Investitionsthese hoch verschuldet und unter einer anderen völlig ausreichend sein. Ein System, das seit einem Jahrzehnt zuverlässig mehrere hunderttausend Transaktionen im Jahr verarbeitet, ist ein bewährtes Asset, wenn ruhiges organisches Wachstum geplant ist, und eine ernste Einschränkung, wenn aggressive Expansion und schnelle Funktionszyklen vorgesehen sind. Eine Schuldenbewertung losgelöst von der These ist deshalb eine akademische Übung. Entscheidend ist die Frage, was genau dieser Plan von der Technologie verlangt und was es kostet, die Lücke zu schließen.

Ebenso wichtig ist die Unterscheidung zwischen Schulden und Vernachlässigung. Jedes System, das lange genug läuft, um Wert zu schaffen, sammelt Schulden an, und dieser Umstand allein ist kein Warnsignal. Das Warnsignal ist fehlendes Bewusstsein: wenn das Team nicht sagen kann, wo die Schulden liegen, was sie kosten und was passiert, wenn nichts geschieht.

Warum die Schulden vor der Unterzeichnung beziffert werden müssen

Die Reihenfolge hat hier unmittelbare finanzielle Wirkung. Vor der Unterzeichnung identifizierte Schulden werden Teil der Verhandlung: eine Preisanpassung, eine Korrektur des Multiples, eine Regelung im Vertrag oder eine Position im Value-Creation-Plan, die der Fonds bewusst finanziert. Dieselben Schulden, sechs Monate nach Closing entdeckt, sind nur noch ungeplante Kosten, die das Produktbudget aufzehren und die These verzögern.

Hinzu kommt ein zweiter, weniger offensichtlicher Grund. Wer die Schulden vor der Transaktion beziffert, plant die ersten hundert Tage anders. Ein Fonds, der mit einer priorisierten Maßnahmenliste und belastbaren Aufwandsschätzungen einsteigt, beginnt am ersten Tag mit der Wertschöpfung. Ein Fonds, der erst einmal entdecken muss, verliert das erste Quartal an die Diagnose und oft das zweite daran, das Team von der Richtigkeit dieser Diagnose zu überzeugen. Dieser Unterschied ist häufig mehr wert als die Bewertung selbst.

Acht Bereiche, in denen die Schulden tatsächlich sitzen

Eine belastbare Bewertung technischer Schulden bedeutet nicht, den Code zu sichten und eine Note zu vergeben. Sie bedeutet, systematisch die Bereiche zu durchleuchten, in denen Schulden die Fähigkeit des Unternehmens zur Planerfüllung wirklich beeinflussen. In den Bewertungen von Altimi sind es acht, und jeder beantwortet eine andere Investorenfrage.

• Architektur und Technologie-Stack. Abhängigkeitsanalyse, Quantifizierung der technischen Schulden und Validierung der Upgrade-Pfade. Hier treten Komponenten außerhalb des Herstellersupports zutage, ebenso wie Stellen, an denen Module so eng gekoppelt sind, dass jede Änderung das halbe System berührt.
• Codequalität und Engineering-Praktiken. Statische Analyse, Testabdeckung, CI/CD-Reifegrad und Bewertung der Code-Gesundheit im Branchenvergleich. Die Frage dahinter lautet, ob das Team das System sicher verändern kann oder ob jede Änderung ein Risiko ist.
• Infrastruktur und Cloud-Readiness. Deployment-Architektur, Kosteneffizienz, Skalierungsgrenze und Anbieterabhängigkeit. Hier zeigt sich, ob die Betriebskosten im Gleichschritt mit dem Umsatz wachsen oder schneller.
• Sicherheit und Compliance. Risikoanalyse nach OWASP, Authentifizierungsmuster, Umgang mit Daten und regulatorische Exponierung, einschließlich DSGVO, SOC 2 und ISO 27001. Lücken in diesem Bereich können ganze Marktsegmente verschließen.
• KI- und Datenreife. Bewertung des KI-Einsatzes, Reifegrad der Datenpipelines, Modell-Governance und konkrete Wertschöpfungspotenziale. Zunehmend entscheidet dieser Bereich darüber, ob ein Asset seinen Vorsprung ausbaut oder zurückfällt.
• Skalierbarkeit und Wachstumsszenarien. Ergebnisse von Lasttests, Machbarkeit horizontaler Skalierung und Kostenprognosen bei zwei-, fünf- und zehnfachem Volumen. Das ist der direkteste Abgleich zwischen Technologie und Investitionsthese.
• Team- und Delivery-Reife. Struktur der Engineering-Organisation, Liefergeschwindigkeit, Schlüsselpersonenrisiko und Belastbarkeit des Einstellungsplans. Schulden sitzen oft nicht im Code, sondern darin, dass nur eine Person weiß, wie die Abrechnung funktioniert.
• 90-Tage-Roadmap zur Wertschöpfung. Maßnahmenplan mit Aufwandsschätzungen, schnellen Erfolgen und strategischen Investitionen für die Zeit nach Closing. Hier wird aus der Diagnose ein Handlungsplan.

Alle acht Bereiche zu durchlaufen, hat einen weiteren Vorteil. Schulden treten selten isoliert auf. Dünne Testabdeckung, ein unreifer Release-Prozess und auf eine Person konzentriertes Wissen gehen meist zusammen, weil sie dieselbe Ursache haben: Lieferdruck zulasten der Grundlagen. Die Bewertung Bereich für Bereich legt dieses Muster offen und nicht nur die einzelnen Symptome.

Wie aus technischen Befunden eine Zahl wird

Der schwächste Punkt der meisten technischen Bewertungen ist, dass sie bei der Beschreibung enden. Der Bericht hält fest, dass die Architektur eng gekoppelt und die Testabdeckung gering ist, und lässt den Investor mit der Frage zurück, was daraus für den Preis folgt. Eine Bewertung, die in einer Transaktion nützt, muss drei Schritte weiter gehen.

Der erste Schritt ist die Aufwandsschätzung. Jeder wesentliche Befund sollte mit einer Schätzung des Aufwands versehen sein, der zu seiner Beseitigung nötig ist, ausgedrückt in konkreten Ressourcen und Zeiträumen. Ohne das lässt sich nichts ins Modell übernehmen.

Der zweite Schritt ist die Priorisierung nach Schweregrad. Nicht jede Schuld muss getilgt werden. Ein Teil kann bewusst bestehen bleiben, wenn er die These nicht berührt. Deshalb werden die Befunde in einer Risikomatrix nach Gewicht und Dringlichkeit geordnet, getrennt danach, was vor der Skalierung behoben sein muss und was lediglich beobachtet wird.

Der dritte Schritt ist die Übersetzung in die Sprache der Transaktion. Quantifizierte Schulden gehen auf drei Wegen ins Modell ein: als einmalige Sanierungskosten im Value-Creation-Plan, als erhöhte laufende Kosten in der Prognose und als Risiko einer Verzögerung der These, das auf das Multiple durchschlägt. Erst in dieser Form wird eine technische Bewertung zum Argument in der Verhandlung statt zur Anlage, die niemand liest.

Hilfreich ist dabei eine einheitliche Bewertungsskala. Eine Einstufung in Rot, Amber oder Grün je Bereich, ergänzt um eine Punktzahl, erlaubt es Partner und Principal, das Gesamtbild in Sekunden zu erfassen, während ein CTO dort in die Tiefe geht, wo es nötig ist. Dasselbe Dokument bedient zwei sehr unterschiedliche Bedürfnisse.

Befunde, die im Datenraum nicht auftauchen

Die Erfahrung aus mehr als hundert käuferseitigen Bewertungen zeigt, dass die teuersten Befunde selten aus Dokumenten stammen. Sie zeigen sich erst mit Zugriff auf den Code und im direkten Gespräch mit dem Engineering-Team.

Bei einem reifen B2B-Marktplatz, der seit über einem Jahrzehnt grenzüberschreitend in Europa tätig ist, waren die kommerziellen Kennzahlen einwandfrei und die Plattform hatte ihre Belastbarkeit über Jahre bewiesen. Erst die Architekturanalyse zeigte, dass organisches Wachstum enge Abhängigkeiten zwischen den Modulen und eingeschränkte API-Grenzen erzeugt hatte. Für eine Plattform in dieser Phase nicht ungewöhnlich, doch die Folge ist konkret: Die Liefergeschwindigkeit sinkt, sobald das Team wächst, und jede weitere externe Integration wird schwerer sauber umzusetzen. Das Geschäft hatte gut skaliert, die Technologie musste zur Ambition aufschließen.

In einem anderen Fall, einer Cloud-Plattform für Betreiber mit mehreren Standorten, überzeugten Produkt-Markt-Passung, reale Wechselkosten und ein stabiles Team. Die Bewertung machte sichtbar, dass kritisches Systemwissen zu Incident Response, Integrationslogik und Deployment-Verfahren auf wenige Personen konzentriert war, ohne formalisierte Verantwortlichkeiten. In gründergeführten Unternehmen dieser Phase verbreitet, aber es verändert das Risikoprofil nach der Übernahme erheblich. Kontinuität muss konstruiert werden, sie lässt sich nicht voraussetzen.

Ein drittes Beispiel, eine etablierte SaaS-Plattform mit starker Händlerbasis in Mittel- und Osteuropa, wirkte bei Retention und Produkt-Roadmap solide. Unter der Oberfläche waren Dependency-Governance und Versionierung der Open-Source-Komponenten nicht standardisiert, und der CI/CD-Reifegrad lag hinter dem zurück, was die Größe der Plattform erwarten ließ. Einzelne Module waren in gutem Zustand, andere trugen angesammelte Schulden, von außen unsichtbar. Nichts, was sich nicht beheben ließe, aber es muss in die Roadmap nach Closing einfließen, bevor Zusagen gemacht werden.

Der gemeinsame Nenner: In keinem dieser Fälle warnten die Geschäftskennzahlen. Technische Schulden tauchen in keiner Umsatzrechnung auf, solange sie das Wachstum nicht begrenzen, und dann sind sie bereits Kosten, die der Käufer getragen hat.

Wie eine gut geführte Bewertung abläuft

Der begrenzende Faktor in einer Transaktion ist die Zeit. Das Fenster für die technische Prüfung ist eng und muss in den Prozessfahrplan passen, weshalb eine Bewertung technischer Schulden als Workstream der Transaktion konzipiert sein sollte und nicht als Beratungsprojekt. In der Praxis passt eine gut geführte Bewertung in zwei Wochen und verläuft in vier Etappen.

Die ersten beiden Tage gelten Mandat und Scoping: Briefing zur Investitionsthese, Bereitstellung der Zugänge, Festlegung der Schwerpunkte. Tag drei bis acht bringen die KI-gestützte Analyse, bei der Codebasis, Abhängigkeiten, Sicherheitslage und Infrastruktur gescannt und anschließend von Ingenieuren geprüft werden. Tag neun bis zwölf sind Deep-Dive-Sessions mit der Engineering-Leitung und der Bewertung der Teamreife gewidmet. Die letzten Tage bringen Bericht und Präsentation für das Investment Committee.

Der Einsatz von KI in der Analysephase verkürzt die Discovery-Zeit um rund 60 Prozent, ersetzt aber kein Urteilsvermögen. Werkzeuge kartieren Abhängigkeiten und erkennen Muster im Code deutlich schneller als ein Mensch, während die Einschätzung, ob ein Befund die Investitionsthese gefährdet, Aufgabe erfahrener Ingenieure bleibt. Genau diese Trennung macht es möglich, einen kurzen Zeitplan mit echter Tiefe zu verbinden.

Der Aufwand aufseiten des Zielunternehmens ist geringer als meist angenommen: Lesezugriff auf Code-Repositories und Cloud-Konsole sowie zwei bis drei Sessions mit dem CTO oder der Engineering-Leitung. Alles erfolgt unter unterzeichneter Vertraulichkeitsvereinbarung, bevor Informationen zur Transaktion ausgetauscht werden.

Was die Bewertung nicht abdeckt

Eine ehrliche Bewertung hat klar gezogene Grenzen. Die technische Due Diligence konzentriert sich auf Technologie, Infrastruktur, Sicherheit und die Leistungsfähigkeit der Engineering-Organisation. Sie ersetzt weder die Validierung des Finanzmodells noch Marktgrößenanalysen, Prüfungen zu Schutzrechtsstreitigkeiten, Background-Checks der Gründer oder die kommerzielle Due Diligence. Wert entsteht, wenn die technischen Befunde mit dem kommerziellen Workstream abgestimmt werden, statt beziehungslos nebeneinander zu laufen. Ein guter Anbieter integriert seine Ergebnisse mit der Arbeit des kommerziellen Beraters, sodass das Investment Committee ein stimmiges Gesamtbild erhält und nicht zwei unverbundene Dokumente.

Ein eigenes Thema ist die Unabhängigkeit, und sie ist ebenso wesentlich. Eine Bewertung technischer Schulden ist nur dann aussagekräftig, wenn ihr Verfasser kein Interesse daran hat, dass die Schulden größer oder kleiner erscheinen, als sie sind. Deshalb zählen Honorarmodell und Transparenz über Vorbeziehungen: ein Festhonorar ohne Anreize für Folgeaufträge, die Offenlegung früherer Verbindungen zum Zielunternehmen und der Verzicht auf das Mandat, wo ein wesentlicher Interessenkonflikt besteht.

Der Ansatz von Altimi

Altimi erbringt käuferseitige technische Due Diligence für Private-Equity-Häuser, Venture-Capital-Fonds und Wachstumsinvestoren in Europa. Die Bewertung wird zum Festpreis in einem vor Kickoff vereinbarten Scope innerhalb von zwei Wochen geliefert und umfasst ein vollständiges Materialpaket für das Investment Committee: einen rund 50-seitigen Bericht mit Bewertung in Rot, Amber oder Grün, eine 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. Eine Executive-Präsentation für das Komitee und definierte Korrekturrunden sind enthalten.

Die Bilanz umfasst über hundert käuferseitige Bewertungen in den Segmenten SaaS, FinTech, HealthTech und industrielle Deep Tech, gestützt auf mehr als 150 Engineering-Projekte. Die zweite Zahl hat praktische Bedeutung: Ein Team, das Systeme täglich baut und modernisiert, schätzt die realen Sanierungskosten anders ein als ein Team, das ausschließlich prüft. Da Altimi als Technologiepartner Kompetenzen aus Product und Application Engineering, DevOps und Cloud Security sowie KI und Data Enablement vereint, kann die empfohlene Sanierung anschließend von demselben Team umgesetzt werden, was die tatsächlichen Kosten der Umsetzung senkt.

Unabhängigkeit ist dabei ein Arbeitsprinzip und keine Behauptung. 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 ab, bei denen ein wesentlicher Interessenkonflikt besteht. Aktueller Scope und Preis sind auf der Seite zur Technology Due Diligence veröffentlicht.

Hinweis für Fonds in DACH und Europa

Für Fonds, die in Deutschland, Österreich und der Schweiz sowie in Mittel- und Osteuropa investieren, hat die Bewertung technischer Schulden eine zusätzliche regulatorische Dimension. Die Exponierung gegenüber der DSGVO, Anforderungen aus Rahmenwerken wie ISO 27001 und SOC 2 sowie die Sicherheitserwartungen von Konzernkunden schlagen unmittelbar auf den adressierbaren Markt des Zielunternehmens durch. Eine Lücke in diesem Bereich ist keine technische Fußnote, sondern eine Wachstumsbremse, die bepreist werden muss.

Ebenso zählt, wo Transaktionsdaten und Quellcode während der Prüfung physisch liegen. Die Zusammenarbeit mit einem in der EU ansässigen, nach ISO 27001 zertifizierten Partner hält sensibles Material über den gesamten vertraulichen Prozess innerhalb des europäischen Datenschutzraums. Bei grenzüberschreitenden Transaktionen, in denen das Zielunternehmen in einem Land tätig ist und der Fonds in einem anderen berichtet, kann dieser Aspekt ebenso schwer wiegen wie der Inhalt der Befunde selbst.

Fazit

Technische Schulden sind unter den Transaktionsrisiken insofern eine Besonderheit, als sie sich vor der Unterzeichnung vollständig quantifizieren lassen und dennoch meist erst danach entdeckt werden. Eine Bewertung mit echtem Wert für den Investor beginnt bei der Investitionsthese, arbeitet sich systematisch durch die acht Bereiche, in denen Schulden das Wachstum beeinflussen, und endet nicht in einer Beschreibung, sondern in einer Zahl: einem geschätzten Sanierungsaufwand, einer geordneten Risikomatrix und einem Plan für die ersten neunzig Tage nach Closing.

Jeder vor der Unterzeichnung aufgedeckte Befund ist entweder eine Preisanpassung zugunsten des Fonds oder eine Position in einem Plan, den der Fonds bewusst finanziert. Jeder nach Closing entdeckte Befund ist ausschließlich Kosten. Der gesamte Unterschied liegt darin, wer die Schulden zuerst beziffert hat.

Wenn Sie eine laufende Transaktion haben und Scope sowie Zeitplan besprechen möchten, ist ein kurzes Gespräch über das Zielunternehmen der schnellste Einstieg.