Carve-out eines Software-Unternehmens. Wo der Perimeter beginnt und wo er endet.
```htmlEin Carve-out eines Software-Unternehmens aus einem Konzernverbund ist keine vereinfachte Version einer klassischen Akquisition. Er ist eine eigene Disziplin. Der Perimeter, den der Konzern zieht, und der Perimeter, der wirtschaftlich tragfähig ist, decken sich selten. Wer den Unterschied nicht früh erkennt, kauft entweder zu viel oder zu wenig. Beides kostet.
Die Perimeter-Frage. Warum sie alles andere bestimmt.
Der erste Schritt in einem Carve-out ist nicht die Bewertung. Er ist die Perimeter-Klärung. Was gehört zur Substanz, die übertragen wird? Was verbleibt beim Konzern? Was liegt in der Grauzone, und wer entscheidet dort? Diese Fragen werden beim Konzernsoftware-Carve-out besonders schnell unangenehm, weil Software-Unternehmen in Konzernen selten sauber abgegrenzt existieren. Sie teilen Infrastruktur, Lizenzen, Entwicklerteams, SSO-Systeme, Data-Warehouses, Legal-Entity-Ressourcen. Sie haben Code-Repositories, in denen konzern-eigene Bibliotheken stecken, die nie explizit lizenziert wurden.
Die Perimeter-Frage hat vier Schichten. Die technische: welche Systeme, welche Repositories, welche Datenbankinstanzen gehen mit? Die personelle: welche Mitarbeiter gehören zur Übertragungseinheit, welche verbleiben beim Konzern, welche sind geteilt? Die vertragliche: welche Kundenverträge, Lieferantenverträge, Lizenzverträge laufen auf der zu übernehmenden Legal Entity, welche auf der Konzernmutter? Die steuerliche: welche stille-Reserve-Positionen, welche Verlustvortragsmassen, welche Verrechnungspreisbeziehungen werden durch den Carve-out neu geordnet?
Wer alle vier Schichten gleichzeitig liest, kann einen tragfähigen Perimeter definieren. Wer eine ausblendet, läuft in Nachverhandlungen, die das Closing gefährden. Das gilt besonders dann, wenn das Zeitfenster der Sondersituation eng ist. Und bei Konzern-Carve-outs ist es das fast immer.
IP-Reinheit. Die häufigste Unterschätzung.
In einem Software-Carve-out ist die Frage der IP-Reinheit regelmäßig der methodisch heikelste Punkt. Sie wird in einer Vielzahl von Transaktionen unterschätzt, weil Konzerne die IP-Entstehungsgeschichte ihrer Software selten vollständig dokumentiert haben. Code wird zwischen Teams geteilt. Externe Entwickler werden ohne klare Work-for-Hire-Vereinbarungen eingesetzt. Open-Source-Komponenten werden integriert, ohne ihre Lizenzbedingungen zu prüfen.
Die Lizenzkette der Software muss lückenlos sein. GPL-, LGPL- und AGPL-Komponenten haben Copyleft-Wirkungen, die bei kommerzieller Verwertung operative Konsequenzen nach sich ziehen. Apache-2.0- und MIT-lizenzierte Komponenten sind gutartiger, aber sie verlangen trotzdem Attributions-Compliance. Eine Software-Bill-of-Materials ist kein Nice-to-have. Sie ist die Grundlage jeder seriösen technischen Due Diligence, wie sie in der Spur eins einer strukturierten Prüfung geführt werden muss: Code-Inspektion, Repository-Analyse, Open-Source-Compliance-Check, IP-Reinheitsurteil.
Hinzu kommt die Frage der Urheberrechts-Zuordnung. Haben alle Entwickler, die an der Software gearbeitet haben, rechtswirksam ihre Rechte auf den Arbeitgeber übertragen? Bei deutschen Entwicklern ist die Rechtslage durch §69b UrhG vergleichsweise klar. Bei US-Entwicklern greifen Work-for-Hire-Grundsätze des Copyright Act. Bei israelischen Entwicklern gelten die Sonderregeln des Israeli Copyright Law. Bei freien Mitarbeitern, Praktikanten, Hackathon-Teilnehmern ist die Lage regelmäßig unklarer. Wer das nicht frühzeitig prüft, erwirbt möglicherweise Software, deren Kernkomponenten Dritten gehören.
TSA-Architektur. Zwischen Brücke und Abhängigkeit.
Was ein Transition Services Agreement leisten muss.
Ein Transition Services Agreement ist die vertragliche Brücke zwischen dem Closing und der operativen Unabhängigkeit der Erwerbseinheit. Ohne TSA ist ein Konzern-Carve-out in den meisten Fällen nicht vollziehbar. Mit einem schlecht verhandelten TSA ist er ein Kostengrab. Die Laufzeit, der Leistungsumfang, die Preisgestaltung und die Exit-Klauseln eines TSA entscheiden darüber, ob die erworbene Substanz innerhalb von zwölf bis achtzehn Monaten eigenständig operieren kann oder dauerhaft vom Konzern abhängig bleibt.
Typische TSA-Leistungen bei Software-Carve-outs: IT-Infrastruktur-Betrieb (Rechenzentrum, Cloud-Konten, Active Directory, E-Mail-Systeme), HR-Administration (Lohnabrechnung, Sozialversicherungsmeldungen), Finanzbuchhaltung, Steuerberichterstattung, Einkauf-Prozesse, Legal-Entity-Unterstützung. Jede dieser Leistungen hat eine Kostenstelle, die im TSA explizit bepreist werden muss. Stranded-Cost-Verteilung ist eine der häufigsten Nachverhandlungs-Ursachen. Wer das nicht im Term Sheet klärt, klärt es beim Closing nicht mehr.
Für uns als Erwerber ist ein TSA eine Überbrückungsstruktur mit definiertem Enddatum. Keine Abhängigkeit, die über achtzehn Monate hinaus toleriert wird. Die Plattform-Logik verlangt operative Eigenständigkeit. Wer ein Software-Unternehmen in eine Plattform integriert, muss dessen Systeme und Prozesse unter eigene Kontrolle bringen. Das TSA ist der Plan, nicht der Zustand.
Steuerneutralität. Wo die echten Hebel liegen.
Die steuerliche Konfiguration eines Software-Carve-outs ist regelmäßig der wichtigste einzelne Werthebel, der in Transaktionen dieser Art liegt. Bei einem typischen Volumen von zwanzig bis fünfzig Millionen Euro können unterschiedliche steuerliche Strukturierungsoptionen zwischen drei und zwölf Prozent des Transaktionsvolumens kosten oder einsparen. Das ist keine Randfrage. Das sind zwischen sechshunderttausend und sechs Millionen Euro, die durch Strukturierungsarbeit entstehen oder verloren gehen.
Im deutschen Kontext entscheidet die Wahl zwischen Asset Deal und Share Deal über die Verlustvortragserhaltung nach §8c KStG, die Grunderwerbsteuer-Wirkung bei immobilienbesitzendem Konzernverbund und die Umsatzsteuer-Behandlung der Geschäftsveräußerung im Ganzen. Ein Hive-Down, in dem die operative Substanz vorab in eine NewCo ausgegliedert und dann als Share Deal übertragen wird, kann steuerlich günstiger sein als ein direkter Asset Deal, verlangt aber mehr Vorlaufzeit. Diese Vorlaufzeit fehlt oft, wenn der Konzern den Carve-out unter Druck entschieden hat.
Bei Cross-Border-Carve-outs kommen weitere Schichten hinzu. DBA-Anwendung bei Lizenzierungsstrukturen zwischen den Gesellschaften. Verrechnungspreisdokumentation für Leistungsbeziehungen innerhalb der Gruppe, die durch den Carve-out neu geordnet werden. BEPS-2-Pillar-2-Auswirkungen bei größeren Konzernverbünden. Permanent-Establishment-Risiken, wenn Entwicklerteams in einer anderen Jurisdiktion als die IP-Holding sitzen. Diese Themen werden in einer typischen Transaktion über mehrere parallele Steuerberater-Spuren bearbeitet, koordiniert durch eine zentrale Transaktionssteuerung. Für weiterführende Strukturierungsmuster verweisen wir auf den Bericht Carve-out als Handwerk.
Regulatorische Genehmigungslandschaft. Was den Zeitplan setzt.
Ein Software-Carve-out mit Konzernbezug kann eine Reihe von Genehmigungsverfahren auslösen, die den Zeitplan von außen setzen. Investitionskontrolle nach deutschem AWG bei Beteiligungen, die kritische Technologien betreffen. FDI-Prüfung nach österreichischem InvKG oder schweizerischem IPG bei grenzüberschreitenden Strukturen. CFIUS in den USA bei US-Teilsubstanz. Diese Verfahren haben eigene Fristen. Sie können vier Wochen dauern, oder neun Monate. Eine Transaktion, die diese Verfahren nicht frühzeitig in den Closing-Plan einbindet, riskiert, dass das Zeitfenster der Sondersituation schließt, bevor die Genehmigungen vorliegen.
Für Software-Unternehmen mit Bezug zu kritischer Infrastruktur kommen NIS-2-Vorgaben und KRITIS-Anforderungen hinzu. Diese sind nicht nur Compliance-Themen für den laufenden Betrieb. Sie sind Transaktionsthemen. Eine Plattform, die KRITIS-relevante Komponenten übernimmt, muss die regulatorische Einbettung dieser Komponenten von Anfang an verstehen. Wer formal ausgewiesene KRITIS-Konformität erwirbt, die intern nicht tragfähig betrieben wird, verliert innerhalb von achtzehn Monaten die Anwenderzertifikate und damit den Marktzugang. Die regulatorische Spur läuft deshalb in jeder unserer Due-Diligence-Phasen von Anfang an parallel zu den anderen Spuren.
Wettbewerbsmeldungen können hinzukommen, müssen es aber nicht. Bei Konzern-Carve-outs unterhalb der Aufgreifschwellen der EU-FKVO und des GWB ist die Wettbewerbsprüfung oft kein kritischer Pfad. Bei größeren Plattformzusammenschlüssen dagegen schon. Die Frage wird in der Perimeter-Klärung gestellt und beantwortet, nicht erst im Closing.
Cap-Table-Bereinigung. Der unterschätzte Schritt vor dem Carve-out.
Konzern-Carve-outs betreffen in der Regel keine Cap-Table-Komplexität in der Tiefe von Venture-Portfolio-Transaktionen. Aber sie haben eine eigene Variante dieser Komplexität: die Frage der internen Konzernbeteiligungen, der konzerninternen Forderungen und Verbindlichkeiten, der Mitarbeiterbeteiligungsprogramme, die an den Konzernmutter-Kurs gebunden sind, und der Minderheitsbeteiligungen externer Investoren, die auf Konzerntochter-Ebene existieren.
Jede dieser Positionen muss vor dem Closing bereinigt werden. Konzern-interne Forderungen und Verbindlichkeiten werden entweder kapitalisiert, abgelöst oder explizit in der Erwerbsstruktur berücksichtigt. Mitarbeiterbeteiligungsprogramme verlangen eine Übergangsregelung, die sowohl steuerlich als auch arbeitsrechtlich belastbar ist. Externe Minderheitsbeteiligungen können Change-of-Control-Klauseln auslösen oder Vorkaufsrechte aktivieren. Wer das nicht frühzeitig prüft, wird im Closing von Ansprüchen überrascht, die den Zeitplan gefährden.
Bei Sondersituationen, in denen der Konzern den Carve-out unter Restrukturierungsdruck durchführt, kommen die Werkzeuge nach StaRUG oder, bei eingetretener Zahlungsunfähigkeit, die Verfahren nach §§270 ff. InsO ins Spiel. In diesen Konstellationen ist die Cap-Table-Bereinigung nicht bilateral verhandelbar, sondern folgt der Verfahrenslogik. Wer die Mechanik dieser Verfahren aus der Praxis kennt, kann den Bereinigungsprozess gestalten. Wer sie nicht kennt, wartet auf Entscheidungen, die andere treffen.
Mitarbeiterübergang. §613a BGB als Strukturfrage, nicht als Formalität.
In einem deutschen Software-Carve-out gilt §613a BGB als dispositives Recht des Betriebsübergangs. Der Mitarbeiter hat ein Widerspruchsrecht. Wenn er widerspricht, verbleibt er beim bisherigen Arbeitgeber. Bei Schlüsselmitarbeitern, die gerade in einer Sondersituation oft die erste Fluchtbewegung bereits vollzogen haben, ist dieses Widerspruchsrecht ein operatives Risiko.
Die Mitarbeiterübergang-Frage ist deshalb keine juristische Formalität, die am Ende der Due Diligence abgehakt wird. Sie ist eine operative Frage, die in der Perimeter-Klärung beginnt und in den ersten dreißig Tagen nach Closing ihren kritischen Punkt erreicht. Wer die Schlüsselmitarbeiter nicht früh anspricht, verliert sie. Und ein Software-Unternehmen ohne seine Engineering-Schlüsselpersonen ist eine Patentakte mit einem Kundenstamm. Mehr nicht. Was aus dieser Übergangsphase operativ folgt, zeigt der Bericht Post-Merger: Die ersten 100 Tage.
Bei Cross-Border-Carve-outs mit UK-Komponenten tritt TUPE hinzu, mit seinen Employee Liability Information-Anforderungen. Bei US-Komponenten WARN-Act-Fristen von sechzig bis neunzig Tagen. Bei israelischen Komponenten das Severance Pay Law mit seinen Section-14-Konstruktionen. Jede dieser Rechtsmaterien muss mit lokalem Co-Counsel parallel bearbeitet werden. Sie laufen nicht sequenziell. Sie laufen gleichzeitig, koordiniert durch eine zentrale Transaktionssteuerung.
Drei Logiken. Wann ein Software-Carve-out ein Investitionsziel wird.
Aus Erwerberperspektive wird ein Software-Carve-out dann zu einem Investitionsziel, wenn drei Logiken gleichzeitig greifen. Die Bewertungslogik: liegt der Erwerbspreis unterhalb des Wiederbeschaffungswertes der technischen Substanz? Personenjahre Engineering, Validierungskosten, regulatorische Zertifikate, Kundenakquisitions-Investitionen. Diese Kalkulation ist unabhängig vom aktuellen Ergebnis des Unternehmens. Sie gibt einen Sicherheitsanker, der von Marktzyklen entkoppelt ist.
Die Integrationslogik: passt die Substanz in eine bestehende oder geplante Plattformlogik? Cross-Sell-Möglichkeiten, Architektur-Kompatibilität, gemeinsame Marktansprache. Ohne Integrationslogik ist ein Software-Carve-out ein Stand-alone-Investment mit begrenztem Wertschöpfungspotenzial.
Die Vertriebslogik: hat die Substanz einen Kundenstamm, einen Vertriebskanal, eine Marktposition, die sich auf der Plattform skalieren lässt? Oder ist die Substanz technisch stark, aber kommerziell schwach, weil der Konzern den Vertrieb nie aufgebaut hat? Die Antwort auf diese Frage verändert den Erwerbspreis-Korridor erheblich. Eine Substanz mit starkem Kundenstamm und schwacher Technik ist anders bewertet als eine mit starker Technik und schwachem Kundenstamm. Beide können ein Investitionsziel sein. Aber die operative Integrationsarbeit sieht komplett anders aus. Wer diese Frage bei Founder-geführten Abspaltungen systematisch stellt, findet den Rahmen im Bericht Founder-Buyout-Strukturen.
Eine Sondersituation, in der nur eine der drei Logiken greift, ist kein Investitionsziel. Sie ist ein operatives Projekt mit unklarem Ausgang. Methodik beginnt mit dieser Unterscheidung.
Wo der Perimeter endet.
Der Perimeter eines Software-Carve-outs endet nicht mit der notariellen Beurkundung. Er endet, wenn die erworbene Substanz in einer eigenen Systemarchitektur betrieben wird, mit eigenen Verträgen, eigenen Lizenzketten, eigenen Mitarbeitern, eigener regulatorischer Einbettung. Das ist keine Frage von Wochen. Es ist eine Frage von zwölf bis achtzehn Monaten strukturierter Integrationsarbeit.
Was in dieser Zeit geschieht, ist die eigentliche Transaktion. Der Carve-out ist die Voraussetzung. Die Integration ist die Substanz. Wer den Perimeter sauber zieht, gibt der Integration eine Grundlage. Wer ihn unscharf zieht, arbeitet die nächsten achtzehn Monate an Konflikten, die beim Closing hätten gelöst sein müssen.
Methodisch. Dicht. Belastbar. Das sind die drei Anforderungen an jeden Perimeter. An keiner anderen Stelle einer Transaktion zahlt sich methodische Disziplin früher aus.
Der Perimeter ist nicht die Grenze der Transaktion. Er ist ihr Fundament.
```