Ein mittelständisches Unternehmen beauftragt einen Softwaredienstleister mit der Entwicklung einer maßgeschneiderten ERP-Lösung. Nach zwölf Monaten und erheblichen Vorauszahlungen ist das System noch immer nicht produktionsreif – und der Auftragnehmer beruft sich auf laufende Sprints, fehlende Abnahmeprotokolle und unklare Anforderungen. Szenarien dieser Art begegnen uns in der Mandatspraxis regelmäßig.
Ob agile Softwareentwicklung dem Werkvertragsrecht des BGB unterliegt oder als Dienstvertrag zu qualifizieren ist, entscheidet über Abnahmepflichten, Mängelrechte und Vergütungsansprüche. Für Geschäftsführer im Mittelstand hängt daran die persönliche Haftung ebenso wie die Liquidität des Unternehmens. Eine sorgfältig gestaltete Vertragsgrundlage und eine klare Eskalationsstrategie bilden den wirksamsten Schutz.
Dieser Beitrag erläutert die vertragsrechtliche Einordnung von IT-Projekten nach dem BGB, zeigt typische Risiken agiler Entwicklungsmodelle auf und beschreibt, wie BRANDT & FALK Rechtsanwälte Geschäftsführer in der Vertragsgestaltung, Abwicklung und streitigen Auseinandersetzung begleitet.
Werkvertrag oder Dienstvertrag – welches Recht gilt für Ihren IT-Projektvertrag?
Die Vertragstypenfrage ist für jeden IT-Projektvertrag die erste und wichtigste Weichenstellung. Schuldet der Entwickler einen funktionsfähigen, abnahmefähigen Erfolg – etwa eine lauffähige Anwendung mit definierten Anforderungen –, liegt nach den §§ 631 ff. BGB ein Werkvertrag vor. Schuldet er lediglich eine zeitliche Arbeitsleistung ohne garantierten Erfolg, liegt ein Dienstvertrag nach §§ 611 ff. BGB nahe.
Die Unterschiede sind erheblich. Beim Werkvertrag hat der Auftraggeber nach Abnahme Mängelrechte (§§ 634 ff. BGB), darunter Nacherfüllung, Minderung, Rücktritt und Schadensersatz. Die Verjährungsfrist für Mängelansprüche beträgt nach der gesetzlichen Regelverjährung grundsätzlich drei Jahre ab Kenntnis (§ 195 BGB); bei einem Software-Werkvertrag mit körperlichem Trägermedium kommen die besonderen werkvertraglichen Regelungen in Betracht. Beim Dienstvertrag hingegen gibt es keine werkvertragliche Abnahme, keinen Erfolgseintritt und folglich keine Mängelhaftung im technischen Sinne.
In der Mandatspraxis sehen wir, dass viele IT-Rahmenverträge bewusst offen formuliert sind: Sie enthalten Elemente beider Vertragstypen. Gerichte, insbesondere der Bundesgerichtshof in gefestigter Senatsrechtsprechung, nehmen eine Gesamtschau vor und qualifizieren nach dem Schwerpunkt der geschuldeten Leistung. Wer als Auftraggeber einen Erfolg – also ein funktionierendes System – erwartet, sollte diesen Erwartungsinhalt vertraglich ausdrücklich als geschuldetes Werk definieren, andernfalls läuft er Gefahr, lediglich Dienstleistungsrechte zu haben.
Wie verändert agile Entwicklung (Scrum, Kanban) die Vertragsstruktur?
Agile Methoden wie Scrum oder Kanban sind auf Flexibilität ausgelegt: Anforderungen werden iterativ verfeinert, Sprints ersetzen das klassische Pflichtenheft, und der Leistungsumfang steht bewusst nicht von Beginn an fest. Das kollidiert strukturell mit dem BGB-Werkvertragsmodell, das einen bestimmten Erfolg voraussetzt.
Wer einen agilen IT-Projektvertrag schließt, ohne diese Spannung rechtlich aufzulösen, schafft Raum für Streit. Ein Sprint ist kein eigenständiges Werk im Sinne des § 631 BGB, solange keine ausdrückliche Sprint-Abnahme vereinbart und ein abnahmefähiger Deliverable definiert ist. Fehlt ein solches Regelwerk, kann der Auftragnehmer nach Abschluss jedes Sprints Vergütungsansprüche geltend machen, ohne dass der Auftraggeber ein abnahmepflichtiges Werk erhalten hat.
Nach unserer Erfahrung lassen sich diese Risiken durch eine sogenannte hybride Vertragsstruktur erheblich reduzieren: Der Gesamtauftrag wird als Rahmenwerk formuliert, einzelne Sprints oder Release-Zyklen werden als abnahmefähige Teilerfolge definiert, und für jeden Lieferzyklus werden klare Akzeptanzkriterien (Acceptance Criteria) als Abnahmevoraussetzung vereinbart. Ergänzend empfiehlt sich eine Änderungsmanagementklausel (Change-Request-Verfahren), die den Umgang mit Anforderungsänderungen dokumentiert und vergütungsrechtlich regelt.
Welche Vertragsklausel schützt Sie, wenn der Auftragnehmer nach dem fünften Sprint die Mitarbeit einstellt? Diese Frage sollte vor Vertragsunterzeichnung beantwortet sein – nicht erst im Eskalationsfall.
Abnahme, Mängelrüge und Verjährung: Fristen, die Geschäftsführer kennen müssen
Die Abnahme ist im Werkvertragsrecht die Schlüsselhandlung: Mit ihr beginnen Verjährungsfristen zu laufen, geht die Preisgefahr über und werden Vergütungsansprüche fällig. Wird die Abnahme ohne schriftliches Protokoll erklärt oder durch schlüssiges Verhalten (Inbetriebnahme, produktiver Einsatz) erteilt, verliert der Auftraggeber Einwendungen, die er nicht ausdrücklich vorbehalten hat.
Für Geschäftsführer im Mittelstand ergibt sich daraus eine konkrete Pflicht: Jede Abnahme sollte schriftlich und mit einem Vorbehaltskatalog für bekannte Mängel dokumentiert werden. Die gesetzliche Regelverjährung beträgt drei Jahre (§ 195 BGB) ab Schluss des Jahres, in dem der Anspruch entstanden ist und der Gläubiger Kenntnis erlangt hat. Bei Mängelansprüchen aus Werkverträgen gilt die zweijährige Verjährungsfrist des § 634a Abs. 1 Nr. 1 BGB für bewegliche Sachen – ob Software auf einem Trägermedium darunter fällt, ist höchstrichterlich nicht abschließend entschieden; die dreijährige Regelverjährung ist hier die sicherere Kalkulationsgrundlage.
Mängelansprüche setzen eine ordnungsgemäße Mängelrüge voraus. Im kaufmännischen Verkehr sollte diese unverzüglich erfolgen, sobald ein Mangel bekannt oder bei ordnungsgemäßer Prüfung erkennbar wird – auch wenn die handelsrechtliche Rügepflicht des § 377 HGB auf Softwareverträge nicht automatisch anwendbar ist, empfiehlt sich eine dokumentierte, zeitnahe Rüge schon aus Beweisgründen.
Urheberrecht, Code-Eigentum und Quellcode-Herausgabe – wer hat nach Projektende die Rechte?
Softwarecode ist urheberrechtlich geschützt. Ohne ausdrückliche vertragliche Regelung verbleiben die Nutzungsrechte beim Entwickler. Das Nutzungsrecht des Auftraggebers entsteht nicht automatisch, sondern muss vertraglich eingeräumt werden (§ 31 UrhG). Fehlt eine solche Klausel, kann der Auftraggeber die erstellte Software zwar nutzen, nicht aber modifizieren, weiterentwickeln oder für Dritte lizenzieren.
Für Geschäftsführer, die ein unternehmenskritisches System in Auftrag geben, hat das weitreichende Folgen. Nach unserer Erfahrung entstehen in der Praxis drei Haupt-Konfliktfelder: erstens die Frage, ob Nutzungsrechte auf zukünftige, noch nicht bekannte Nutzungsarten erstreckt werden; zweitens die Herausgabe von Quellcode und Entwicklungsartefakten nach Projektabschluss oder Kündigung; drittens die Rechtelage bei Verwendung von Open-Source-Bibliotheken (Copyleft-Effekt).
Ein vollständiger IT-Projektvertrag regelt daher zwingend: die Einräumung ausschließlicher oder einfacher Nutzungsrechte, den Umfang (Bearbeitung, Weiterentwicklung, Sublizenzierung), den Zeitpunkt der Rechteübertragung (mit oder nach vollständiger Zahlung), die Herausgabepflicht für Quellcode, Dokumentation und Build-Umgebungen sowie die Behandlung von Drittkomponenten und Open-Source-Lizenzen.
Was passiert bei Projektstillstand, Kündigung und Streit?
IT-Projekte scheitern. Nach der in der Praxis beobachtbaren Häufung von Eskalationen lässt sich sagen: Die typischen Auslöser sind unklare Anforderungen, Zahlungsstreitigkeiten nach Meilensteinverfehlung und wechselseitige Vorwürfe hinsichtlich Verzug oder mangelnder Mitwirkung des Auftraggebers. Was tun, wenn das Projekt zum Stillstand kommt?
Der Werkvertrag kann vom Auftraggeber jederzeit gekündigt werden (§ 648 BGB); der Auftragnehmer behält dann seinen Vergütungsanspruch, muss sich aber ersparte Aufwendungen und anderweitigen Erwerb anrechnen lassen. Die freie Kündigung nach § 648 BGB ist kein kostenloses Ausstiegsrecht: Der verbleibende Vergütungsanspruch kann erheblich sein. Eine außerordentliche Kündigung aus wichtigem Grund (§ 648a BGB) setzt einen schwerwiegenden Vertragsverstoß voraus, der eine Fortsetzung unzumutbar macht.
Bevor ein Streit eskaliert, empfiehlt sich ein strukturierter Eskalationsprozess: formelle Mängelanzeige mit Fristsetzung, Protokollierung des Projektstands, rechtliche Prüfung der Kündigungsvoraussetzungen. Gerade bei laufenden Scrum-Projekten ist die Beweissicherung entscheidend: Wer hat welche Anforderungen wann freigegeben? Welche Sprints wurden durch wen abgenommen? Ein anwaltlich begleiteter Projektstatus kann hier die Verhandlungsposition erheblich stärken.
Die vorstehende Darstellung betrifft die typischen Fallkonstellationen. Ihr konkretes Projekt erfordert die Prüfung der Vertragsdokumentation, der Kommunikationshistorie und der einschlägigen Rechtsprechung. Für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Wie gestaltet BRANDT & FALK einen rechtssicheren IT-Projektvertrag?
Ein IT-Projektvertrag, der vor Gericht standhält und Ihnen als Auftraggeber die notwendigen Steuerungsinstrumente gibt, ist mehr als eine Auflistung von Leistungsmerkmalen. Er verbindet Vertragstypenklarheit, Abnahmeregime, Vergütungsstruktur, Urheberrechtsklauseln, Datenschutzanforderungen und Eskalationsregeln zu einem konsistenten Regelwerk.
In der Mandatspraxis begleiten wir Geschäftsführer in drei Phasen: erstens bei der Vertragsgestaltung vor Projektbeginn (Vertragstypenanalyse, Pflichtenheft-/Acceptance-Criteria-Klauseln, Urheberrechtseinräumung, Change-Request-Verfahren, SLA-Regelungen, Datenschutz-Verarbeitungsvertrag nach Art. 28 DSGVO); zweitens bei der laufenden Begleitung während des Projekts (Abnahmedokumentation, Mängelrügen, Vertragsanpassungen bei Scope-Änderungen); drittens bei der Streitbeilegung und Kündigung (Kündigung aus wichtigem Grund, Schadensersatz, einstweiliger Rechtsschutz, Mediation).
Darüber hinaus beraten wir zu datenschutzrechtlichen Anforderungen, die häufig in IT-Projekten übersehen werden: Wird personenbezogene Software entwickelt oder werden Daten verarbeitet, ist ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO erforderlich. Verstöße können Bußgelder von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes nach sich ziehen (Art. 83 DSGVO). Die DSGVO-konforme Vertragsgestaltung ist daher keine optionale Ergänzung, sondern integraler Bestandteil eines professionellen IT-Projektvertrags.
Aus der Mandatspraxis: In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Handelsunternehmen, das im Rahmen einer Digitalisierungsinitiative eine Cloud-basierte Warenwirtschaftslösung in Auftrag gegeben hatte. Ausgangslage: Nach mehreren Sprints stellte das Unternehmen fest, dass die Kernanforderungen – unter anderem die Schnittstellen zum bestehenden ERP-System – weder im Vertrag noch in den Sprint-Backlogs vollständig definiert waren. Der Entwickler forderte erhebliche Nachvergütungen für Zusatzleistungen. Vorgehen: Die Kanzlei analysierte sämtliche Sprint-Protokolle, E-Mail-Kommunikation und Change-Request-Dokumentation auf Anzeichen einer stillschweigenden Leistungserweiterung ohne formelle Vertragsanpassung. Parallel wurde eine förmliche Mängelanzeige mit Nacherfüllungsfrist formuliert. Ergebnis: Die außergerichtliche Einigung erfolgte auf Basis eines neu strukturierten Restleistungsvertrags mit klaren Abnahmekriterien und einer reduzierten Nachvergütungspflicht; das Projekt wurde erfolgreich abgeschlossen. Keine Angaben zu konkreten Beträgen oder Quoten.
Welche typischen Fehler sollten Geschäftsführer in IT-Projekten vermeiden?
Aus der Beratung von Unternehmen, die mit gescheiterten oder eskalierten IT-Projekten zu uns kommen, lassen sich wiederkehrende Strukturfehler identifizieren. Kenntnis dieser Fehler ist der erste Schritt zur Vermeidung.
- Fehlende Vertragstypenklarheit: Der Vertrag enthält weder eine ausdrückliche Werkvertragsnatur noch klare Erfolgsmerkmale; die Parteien streiten nach Monaten über das Grundprinzip der Haftung.
- Keine dokumentierten Abnahmen: Sprints werden mündlich „freigegeben", ohne schriftliche Abnahme mit Vorbehaltskatalog; Mängelansprüche sind später schwer durchsetzbar.
- Unzureichende Urheberrechtsklauseln: Die Nutzungsrechtseinräumung fehlt oder ist auf eine enge Nutzungsart beschränkt; das Unternehmen kann die Software bei einem Anbieterwechsel nicht weiterverwenden.
- Kein Change-Request-Verfahren: Anforderungsänderungen werden per E-Mail kommuniziert und führen zu unkontrollierbaren Nachvergütungsforderungen.
- Fehlender Datenschutzvertrag (AVV): Personenbezogene Daten werden im Rahmen der Entwicklung verarbeitet, ohne dass ein AVV nach Art. 28 DSGVO geschlossen wurde – mit entsprechendem Bußgeldrisiko.
- Keine Quellcode-Herausgabepflicht: Bei Kündigung oder Insolvenz des Dienstleisters fehlt die vertragliche Grundlage für die Herausgabe von Quellcode, Dokumentation und Deployment-Umgebung.
- Ungeregelte SLA-Verletzungsfolgen: Service-Level-Agreements sind vereinbart, aber Verletzungsfolgen (Vertragsstrafen, Minderungsrechte) fehlen – die SLA bleibt damit zahnlos.
Wie viele dieser Punkte finden sich in Ihrem aktuellen IT-Projektvertrag? Diese Frage lohnt sich, bevor ein Konflikt ausbricht.
Entscheidungsmatrix: Welches Instrument passt zu welcher Projektsituation?
Die richtige rechtliche Reaktion auf eine IT-Projektkrise hängt von der konkreten Konstellation ab. Folgende Zuordnung dient als erste Orientierung:
Konstellation A – Auftragnehmer liefert vereinbarte Sprints nicht ab: Instrument: Nacherfüllungsforderung mit angemessener Fristsetzung (§§ 634 Nr. 1, 635 BGB), anschließend Rücktritt oder Minderung. Frist: angemessen im Einzelfall, mindestens nach Mahnung. Folge: Vergütungsanspruch des Auftragnehmers entfällt anteilig, Schadensersatzanspruch entsteht.
Konstellation B – Auftraggeber akzeptiert Sprints produktiv, ohne formelle Abnahme: Instrument: Nachträgliche schriftliche Fixierung der Abnahme mit ausdrücklichem Vorbehalt bekannter Mängel. Frist: unverzüglich nach Inbetriebnahme. Folge: Erhalt der Mängelrechte trotz faktischer Nutzung.
Konstellation C – Streit über Anforderungsumfang / Mehrvergütung: Instrument: Auswertung der Change-Request-Dokumentation; im Zweifel ergänzende Vertragsauslegung nach §§ 133, 157 BGB. Frist: vor Abnahme geltend machen. Folge: Einschränkung oder Abwehr ungerechtfertigter Nachforderungen.
Konstellation D – Projektabbruch durch Auftraggeber: Instrument: freie Kündigung nach § 648 BGB mit sofortiger Leistungsstandaufnahme; gegebenenfalls Kündigung aus wichtigem Grund nach § 648a BGB. Frist: keine gesetzliche Mindestfrist, aber Dokumentation des wichtigen Grundes vor Kündigung. Folge: Vergütungsreduzierung um ersparte Aufwendungen; Beweislast beim Auftragnehmer.
Verwandte Leistungen
Häufig gestellte Fragen zum IT-Projektvertrag und zur agilen Softwareentwicklung
Unterliegt ein agiler IT-Projektvertrag dem Werkvertragsrecht des BGB?
Das hängt von der geschuldeten Leistung ab. Schuldet der Entwickler einen funktionsfähigen Erfolg – etwa eine lauffähige Anwendung –, liegt in der Regel ein Werkvertrag nach §§ 631 ff. BGB vor. Reine Zeitarbeit ohne garantierten Erfolg ist dagegen als Dienstvertrag einzuordnen. Bei agilen Projekten ist die Grenze oft fließend; eine ausdrückliche vertragliche Klarstellung ist dringend zu empfehlen, um im Streitfall Mängelrechte zu sichern.
Was gilt, wenn ein Sprint produktiv eingesetzt wird, ohne formal abgenommen zu werden?
Die produktive Inbetriebnahme einer Software kann als konkludente Abnahme gewertet werden. Mit der Abnahme – auch der stillschweigenden – beginnen Verjährungsfristen zu laufen und Mängeleinwendungen, die nicht vorbehalten wurden, können verwirken. Geschäftsführer sollten daher jeden Inbetriebnahmevorgang schriftlich dokumentieren und Mängelvorbehalte ausdrücklich erklären, um Rechtsverluste zu vermeiden.
Wer ist nach Abschluss des Projekts Eigentümer des Quellcodes?
Ohne ausdrückliche vertragliche Regelung verbleibt das Urheberrecht am Quellcode beim Entwickler. Der Auftraggeber erhält nur ein Nutzungsrecht in dem Umfang, den der Vertrag vorsieht. Für eine uneingeschränkte Weiterverwendung, Anpassung und Weitergabe an Dritte muss eine entsprechende Rechteeinräumung nach § 31 UrhG vertraglich vereinbart werden. Fehlt diese, ist die Rechtslage im Streitfall zu prüfen.
Welche Datenschutzpflichten bestehen bei der Beauftragung eines Software-Entwicklers?
Werden im Rahmen der Entwicklung personenbezogene Daten verarbeitet – etwa durch den Einsatz von Testdaten oder Produktionsdaten –, ist zwingend ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO zu schließen. Verstöße können mit Bußgeldern von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes geahndet werden. Der AVV sollte Gegenstand des IT-Projektvertrags sein, nicht eine nachträgliche Ergänzung.
Kann ein IT-Projektvertrag während eines laufenden Sprints gekündigt werden?
Ja. Der Auftraggeber kann einen Werkvertrag nach § 648 BGB jederzeit frei kündigen. Der Auftragnehmer behält jedoch seinen Vergütungsanspruch für die erbrachte und die nicht erbrachte Leistung, abzüglich ersparter Aufwendungen und anderweitigen Erwerbs. Die freie Kündigung ist daher kein kostenloses Ausstiegsrecht. Eine Kündigung aus wichtigem Grund nach § 648a BGB setzt einen schwerwiegenden Vertragsverstoß voraus und ist sorgfältig zu prüfen.
Was ist ein Change-Request-Verfahren und warum ist es wichtig?
Ein Change-Request-Verfahren regelt vertraglich, wie Anforderungsänderungen während des Projekts beantragt, bewertet, freigegeben und vergütet werden. Ohne ein solches Verfahren entstehen unkontrollierbare Nachvergütungsansprüche des Entwicklers für Leistungen, die der Auftraggeber als selbstverständlich ansieht. In der Praxis ist das Change-Request-Verfahren eine der wirkungsvollsten Schutzmaßnahmen gegen Budgetüberschreitungen und Streit über den Leistungsumfang.
Die vorstehende Darstellung betrifft die Regelfälle des IT-Projektvertragsrechts. Ihr konkreter Fall erfordert die individuelle Prüfung von Vertragsdokumentation, Fristen und der einschlägigen Rechtsprechung. Zur Klärung, wie die vorstehenden Instrumente auf Ihr Unternehmen wirken, wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Er ersetzt nicht die anwaltliche Prüfung Ihres konkreten Sachverhalts. Für eine auf Ihre Situation zugeschnittene Beratung wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag ist eine allgemeine Information und stellt keine Rechtsberatung dar. Für eine Prüfung Ihres Falls kontaktieren Sie info@brandtfalk.com.