Eine Software-Beratungs-GmbH in Deutschland führen: BaFin-Fallen, Berufshaftpflicht und die Festpreisvertragsklauseln, die dich wirklich schützen
Die meisten technikgeführten Gründer, die in Deutschland eine Software-GmbH aufbauen, halten die Kundenakquise für den schwierigen Teil. Ist sie nicht. Der schwierige Teil ist die rechtliche und regulatorische Angriffsfläche, die sich unsichtbar ansammelt - bis ein FinTech-Kunde eine BaFin-Lizenzeinschätzung verlangt, ein Festpreisprojekt 40 Prozent über den Scope läuft oder ein Schweizer Engagement eine Quellensteuerpflicht auslöst, vor der dich niemand gewarnt hat.
Dieser Beitrag ist der Praxis-Guide, den ich mir gewünscht hätte, als ich Wolf-Tech gegründet habe. Er ist keine Rechtsberatung - für deine konkrete Situation brauchst du einen deutschen Rechtsanwalt und einen Steuerberater. Aber er kartiert das Gelände, damit du weißt, wo die Tretminen liegen, bevor du auf sie trittst.
Die BaFin-Lizenzfalle, die Software-GmbHs kalt erwischt
Die BaFin, Deutschlands Finanzaufsicht, reguliert nicht nur Banken. Sie reguliert Funktionen - und wenn deine Software eine regulierte Funktion im Auftrag von Nutzern ausführt, kann die Lizenzpflicht an dir hängen bleiben, nicht nur an deinem Kunden.
Der konkrete Risikopunkt für Software-Beratungen ist die Banklizenzpflicht nach § 32 KWG und, seit PSD2, das ZAG (Zahlungsdiensteaufsichtsgesetz) als Rahmen für Zahlungsdienste. Zu den Szenarien, in denen eine Software-GmbH unbeabsichtigt reguliertes Terrain betritt, gehören:
Kontoaggregation und PFM-Features. Wenn du ein Personal-Finance-Management-Tool baust, das Kontodaten über Open-Banking-APIs liest und für Endnutzer aggregiert, erbringst du möglicherweise Kontoinformationsdienste (AIS) nach ZAG. Dein Kunde braucht eine AIS-Lizenz - oder ein Subunternehmerverhältnis mit einem BaFin-lizenzierten Anbieter. Wenn beides fehlt und deine GmbH die Entität ist, die die API anspricht, kann die BaFin die Position vertreten, dass du der unlizenzierte AIS-Anbieter bist.
Escrow- oder Zahlungsauslöselogik. Ein Marktplatz-Checkout, bei dem Gelder in der Logik deiner Anwendung in einem Haltezustand liegen - auch nur kurz, auch wenn sie über Stripe geroutet werden -, kann für die BaFin je nach Implementierungsdetails wie Zahlungsauslösedienste (PIS) oder E-Geld-Dienste aussehen.
Krypto-nahe Arbeit. Seit MiCA EU-weit in Kraft ist, sind Kryptowerte-Dienstleistungen eine regulierte Kategorie. Ein Backend zu schreiben, das Wallets verwaltet, Swaps ausführt oder Private Keys verwahrt, platziert dich mitten im regulierten Terrain.
Die praktische Regel: Bevor du ein FinTech-Engagement startest, lass dir von deinem Kunden schriftlich bestätigen, welche BaFin-Lizenzen er hält und von welchen regulierten Funktionen deine Software explizit ausgenommen ist. Kann der Kunde das nicht liefern, sprich mit deinem eigenen Rechtsbeistand, bevor du unterschreibst. Das ist keine Paranoia - das ist Vertragshygiene.
Drei Versicherungsprodukte, die jede Software-GmbH haben sollte
Das deutsche Recht schreibt Software-Unternehmen keine Berufshaftpflicht vor, wie es das bei Anwälten oder Wirtschaftsprüfern tut. Das führt dazu, dass die meisten GmbH-Gründer entweder unterversichert sind oder das falsche Produkt kaufen. Hier sind die drei Schichten, die wirklich zählen.
1. Berufshaftpflichtversicherung (Professional Indemnity)
Sie deckt Vermögensschäden, die deine Kunden durch Fehler oder Versäumnisse in deinen professionellen Leistungen erleiden - eine fehlerhafte Migration, die Produktionsdaten korrumpiert, falsche technische Beratung, die zu einem teuren Rebuild führt, eine übersehene Sicherheitslücke in Code, den du auditiert hast. Die Standarddeckung beginnt bei 250.000 Euro pro Schadensfall; für mittelgroße Enterprise-Kunden willst du mindestens 1 Million Euro. Die Deckungslücke, auf die du achten musst: Die meisten Standardpolicen schließen vorsätzliche Handlungen und Folgeschäden jenseits des direkten Schadens aus. Wenn ein von dir eingeführtes Performance-Problem dazu führt, dass das SaaS deines Kunden Kunden verliert, kann der Anspruch auf entgangenen Umsatz ausgeschlossen sein. Lies den Abschnitt Ausschlüsse sorgfältig, nicht nur die Deckungssumme in der Überschrift.
2. Cyber-Versicherung (Cyber Liability)
Getrennt von der Berufshaftpflicht und zunehmend von Enterprise-Kunden vor Vertragsunterzeichnung verlangt. Deckt deine eigenen Erstparteikosten (Incident Response, Forensik, Meldepflichten nach Art. 33 DSGVO) sowie Drittansprüche von Kunden, deren Daten über deine Systeme kompromittiert wurden. Da eine Software-Beratung typischerweise Kunden-Credentials, API-Keys und Quellcode in ihrer Entwicklungsumgebung hat, ist die Exponierung real. Die Lücke, auf die du achten musst: Viele Cyber-Policen schließen bekannte Schwachstellen aus - hattest du zum Zeitpunkt des Breaches eine ungepatchte CVE in deiner Toolchain, kann die Deckung verweigert werden.
3. Betriebshaftpflichtversicherung (General Business Liability)
Die Basisschicht. Deckt Personen- und Sachschäden aus deinem Geschäftsbetrieb. Für einen reinen Software-Shop weniger direkt relevant, aber von den meisten Coworking-Mietverträgen und Zugangsvereinbarungen zu Kundengeländen verlangt. Überspring sie nicht - sie ist günstig, und manche Kunden lassen Dienstleister ohne sie nicht auf ihr Gelände.
Die Kombination aller drei kostet eine Software-GmbH je nach Umsatz und Risikoprofil typischerweise zwischen 3.000 und 8.000 Euro pro Jahr. Behandle das als Betriebskosten, nicht als optionale Ausgabe.
Werkvertrag vs. Dienstvertrag: den richtigen Vertragstyp wählen
Diese Unterscheidung ist wichtiger, als die meisten Software-Gründer denken, denn sie bestimmt, was dein Kunde verlangen kann und welche Rechtsmittel er hat, wenn etwas schiefgeht.
Ein Werkvertrag verpflichtet dich, ein definiertes Ergebnis zu liefern - ein funktionierendes System, ein bestimmtes Feature, eine Migration mit definierten Abnahmekriterien. Ist das Ergebnis mangelhaft, hat der Kunde nach § 634a BGB zwei Jahre lang gesetzliche Gewährleistungsansprüche. Er kann Nachbesserung, Minderung oder letztlich Rücktritt vom Vertrag verlangen.
Ein Dienstvertrag verpflichtet dich zur Leistungserbringung - Stunden kompetenter Engineering-Arbeit -, nicht zur Garantie eines Ergebnisses. Es gibt keine gesetzliche Gewährleistung für das Resultat. Stellt sich die von dir empfohlene Architektur als falsch heraus, ist das Rechtsmittel des Kunden das Deliktsrecht, nicht das Gewährleistungsrecht - und das ist für ihn ein deutlich schwierigerer Fall.
Die meisten Software-Beratungsengagements sollten, wo möglich, als Dienstverträge strukturiert werden, weil Software inhärent unsicher ist - Anforderungen ändern sich, Kunden treffen mitten im Projekt Scope-Entscheidungen, und die Ergebnisse liegen nicht allein in der Hand des Beraters. Die Herausforderung: Festpreisverträge mit definierten Deliverables sehen für ein deutsches Gericht wie Werkverträge aus, auch wenn du sie anders nennst. Nicht das Etikett bestimmt die rechtliche Einordnung - die wirtschaftliche Substanz tut es.
Festpreisvertragsklauseln, die dich wirklich schützen
Festpreisprojekte sind kommerziell attraktiv, aber rechtlich gefährlich, wenn dein Vertrag die Realitäten der Softwareentwicklung nicht berücksichtigt. Das sind die Klauseln, die zählen.
Eine präzise Leistungsbeschreibung mit explizitem Change-Order-Protokoll. Der Scope eines Werkvertrags ist das, was in der Leistungsbeschreibung steht. Alles, was der Kunde verlangt und dort nicht steht, ist Zusatzarbeit, die dich zu zusätzlicher Vergütung berechtigt. Das Problem: Ohne schriftliches Change-Order-Protokoll wird der Kunde jede Scope-Erweiterung als "wir sind davon ausgegangen, dass das enthalten ist" darstellen. Dein Vertrag muss festlegen: Änderungen werden schriftlich definiert, von beiden Parteien unterzeichnet und vor Arbeitsbeginn bepreist. Mündliche Freigaben zählen nicht.
Ein Gewährleistungsausschluss, der die Gewährleistung auf sechs Monate begrenzt. Die gesetzliche Gewährleistungsfrist für Werkverträge beträgt in Deutschland zwei Jahre. Für gewerbliche Kunden kannst du sie vertraglich auf sechs Monate reduzieren (B2B - für Verbraucher ist die Begrenzung unwirksam). Nimm diese Klausel auf. Die Standardformulierung begrenzt Gewährleistungsansprüche auf Mängel, die innerhalb von sechs Monaten nach förmlicher Abnahme gemeldet werden, und beschränkt die Rechtsmittel auf eine Gelegenheit zur Nachbesserung, bevor der Kunde Minderung geltend machen kann.
Eine förmliche Abnahmeklausel mit Abnahmefiktion. Die Abnahme ist der Auslöser mehrerer wichtiger Rechtsfolgen: Die Gewährleistungsfrist beginnt, das Risiko des zufälligen Untergangs geht auf den Kunden über, und du wirst zur Schlusszahlung berechtigt. Dein Vertrag muss definieren, was als Abnahme gilt - typischerweise eine schriftliche Freigabe nach einer definierten Testphase - und eine Abnahmefiktion enthalten: Meldet der Kunde nicht innerhalb von X Tagen nach Lieferung dokumentierte Mängel, gilt die Abnahme als erteilt. Ohne das kann ein passiver Kunde die Abnahme unbegrenzt verzögern und deine Schlusszahlung zurückhalten.
Eine Haftungsbegrenzung auf den Auftragswert. Das deutsche Recht erlaubt es Parteien, die Haftung in B2B-Verträgen auf den Auftragswert zu begrenzen, außer bei Vorsatz oder grober Fahrlässigkeit. Nutze das. Ein 50.000-Euro-Projekt sollte dich nicht 500.000 Euro an Folgeschadensansprüchen aussetzen.
Expliziter Ausschluss von Folgeschäden. Verwandt mit der Haftungsbegrenzung: Schließe entgangenen Gewinn, Datenverlust und mittelbare Schäden von deiner Haftung aus. Das sind Standardausschlüsse in gut formulierten Softwareverträgen, und Gerichte halten sie in B2B-Beziehungen in der Regel aufrecht.
Grenzüberschreitende Engagements und die Quellensteuerfalle
Wenn deine Software-GmbH mit Kunden in der Schweiz, Österreich oder anderen EU-Ländern arbeitet und du Mitarbeiter oder beauftragte Subunternehmer zum Kunden vor Ort schickst, kannst du lokale Quellensteuerpflichten auslösen - auch bei kurzen Einsätzen. Insbesondere die Schweiz kennt eine 15-Tage-Regel: Schweizer Kunden sind in manchen Kantonen verpflichtet, Steuern von Zahlungen an ausländische Auftragnehmer einzubehalten, wenn der Einsatz 15 Tage überschreitet.
Das erwischt Gründer kalt, weil die Pflicht beim Kunden liegt - aber der Kunde wird sie oft als dein Problem darstellen oder den Betrag ohne Vorwarnung von deiner Rechnung abziehen. Der Fix ist simpel: Lege im grenzüberschreitenden Vertrag fest, dass der Kunde für lokale Quellensteuerpflichten verantwortlich ist und Rechnungsbeträge netto solcher Verpflichtungen zu verstehen sind. Besteht der Kunde auf dem Einbehalt, muss dieser dokumentiert werden, und du musst ihn nach dem anwendbaren Doppelbesteuerungsabkommen in Deutschland als Steueranrechnung nutzen können.
Bei längeren Engagements, bei denen du oder ein Teammitglied mehr als 183 Tage im Jahr physisch in einem anderen Land präsent seid, sprich vor Beginn mit deinem Steuerberater - du könntest eine Betriebsstätte begründen.
Eine Anmerkung zur Frage Freiberufler vs. GmbH
Wenn du das hier liest, während du noch zwischen der Tätigkeit als unabhängiger Freiberufler und der Gründung einer GmbH abwägst: Die Rechnung hat sich in den letzten Jahren etwas verschoben. Die GmbH bietet Haftungsschutz und erlaubt es, Gewinne zum niedrigeren Körperschaftsteuersatz im Unternehmen zu belassen, statt auf alles Ausgeschüttete Einkommensteuer zu zahlen. Für eine Beratung mit 200.000+ Euro Jahresumsatz überwiegt die Steuereffizienz in der Regel den Verwaltungsaufwand.
Der zentrale Nachteil des GmbH-Status für Software-Berater ist das Risiko der Reklassifizierung als Scheinselbständigkeit, wenn ein großer Teil deines Umsatzes von einem einzigen Kunden stammt und du vor Ort in einer Weise arbeitest, die einem Angestelltenverhältnis ähnelt. Die BaFin ist nicht der einzige Regulator, um den du dich sorgen musst - die Deutsche Rentenversicherung prüft GmbH-Auftragnehmer und kann rückwirkende Sozialversicherungsbeiträge verlangen, wenn sie zu dem Schluss kommt, dass das Arrangement wirtschaftlich einem Arbeitsverhältnis gleichkommt.
Der strukturelle Fix ist derselbe, ob du als Freiberufler oder als GmbH agierst: mehrere Kunden halten, die Eingliederung in die operative Hierarchie des Kunden vermeiden, eigene Tools und Arbeitszeiten behalten und deine Unabhängigkeit in der Vertragssprache dokumentieren.
Die operativen Grundlagen richtig aufsetzen
Jenseits des Rechts- und Versicherungsrahmens haben drei operative Entscheidungen überproportionalen Einfluss darauf, wie reibungslos deine GmbH läuft:
Ein guter Steuerberater, der Software-Unternehmen versteht - nicht nur ein generischer Kleinunternehmens-Steuerberater -, spart dir weit mehr als sein Honorar. Die umsatzsteuerliche Behandlung innergemeinschaftlicher Leistungen, die Forschungszulage und grenzüberschreitende Rechnungs-Compliance sind alles Bereiche, in denen ein Generalist legitime Optimierungen übersieht.
Ein Standardsatz von Vertragsvorlagen, geprüft von einem deutschen IT-Anwalt, nicht aus dem Internet kopiert. Die einmaligen Rechtskosten für ordentliche Vorlagen liegen typischerweise bei 1.500 bis 3.000 Euro. Du wirst sie jahrelang für jedes Engagement nutzen.
Ein disziplinierter Rechnungs- und Mahnprozess. Das deutsche Handelsrecht verlangt Zahlung innerhalb von 30 Tagen nach Rechnungseingang (§ 271a BGB), sofern nicht anders vereinbart - aber die Durchsetzung erfordert einen dokumentierten Mahnprozess. Kleinforderungen bis 5.000 Euro lassen sich über das deutsche Mahnverfahren effizient und ohne vollständiges Gerichtsverfahren beitreiben.
Wolf-Tech ist seit über 18 Jahren als Berliner Software-GmbH tätig. Wenn du eine Software-Beratung in Deutschland aufbaust oder skalierst und Fragen zur Strukturierung von Kundenengagements oder zur regulatorischen Landschaft hast, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io - wir teilen gern, was wir gelernt haben.