Software-Dokumentation ist Werkbestandteil: Warum Spezifikationslücken Freiberufler das Honorar kosten

Softwareentwicklung ist ein Prozess permanenter Übersetzung: Abstrakte geschäftliche Vorgaben müssen in ausführbaren Quellcode und stabile Schnittstellen überführt werden. Wenn zwischen den Erwartungen des Auftraggebers und dem Arbeitsergebnis des selbstständigen Entwicklers eine Lücke klafft, wird dies im Projektjargon häufig als Missverständnis verbucht. Im juristischen Gefüge des deutschen Zivil- und Sozialrechts wandelt sich eine solche Unschärfe jedoch schnell in existenzbedrohende Haftungs- und Honorarausfälle. Während Veröffentlichungen wie Wem gehört meine Webseite? Domain, Code und Inhalte (2026) die urheberrechtliche Einräumung von Nutzungsrechten (§ 31 UrhG) behandeln und Was kostet eine Webseite 2026? Preise für kleine Betriebe die wirtschaftlichen Grundlagen von Pflichtenheften analysieren, beleuchtet dieser Beitrag die Haftungsfolgen unzureichender Spezifikation. Die notwendige technische Absicherung berührt dabei Verfahren, wie sie in Gedanken verankern: Warum kryptografische Zeitstempel die Zukunft persönlichen Wissens sind für unveränderbare Prüfketten beschrieben werden, sowie den Übergang zu deterministischen Schnittstellen, der in Typisierte Entscheidungen statt Fließtext: was Jev ist und wann es das richtige Werkzeug ist anhand strenger Schemata gegen sprachliche Missverständnisse abgegrenzt wird.

Stand aller Angaben: Oktober 2026. Grundlage dieser Analyse sind die Urteile des Bundesgerichtshofs (BGH), des Oberlandesgerichts Frankfurt am Main (OLG Frankfurt a. M.), des Landessozialgerichts Baden-Württemberg (LSG Baden-Württemberg) sowie die gesetzlichen Normen des Bürgerlichen Gesetzbuchs (BGB) und des Vierten Buches Sozialgesetzbuch (SGB IV), ergänzt um Erhebungen der Standish Group und Schadensakten gewerblicher IT-Haftpflichtversicherer.

Softwareentwicklung ist im Zweifel Werkvertrag: Ohne Dokumentation gilt das Werk als mangelhaft

Ein verbreiteter Irrtum unter IT-Freiberuflern besteht in der Annahme, dass eine Abrechnung nach Stundensätzen oder die Arbeit in zweiwöchigen agilen Sprints automatisch einen Dienstvertrag nach § 611 BGB begründet. Beim Dienstvertrag schuldet der Auftragnehmer lediglich das fachgerechte Bemühen; das Risiko des Misslingens verbleibt beim Auftraggeber, und das Honorar wird mit Erbringung der Arbeitszeit fällig.

Die Rechtsprechung des Bundesgerichtshofs folgt jedoch einer anderen Linie. Nach gefestigter höchstrichterlicher Entscheidungspraxis (unter anderem BGH, Urteil vom 24.10.2002, Az. VII ZR 332/01) ist die Erstellung oder grundlegende Anpassung von Individualsoftware im Zweifel als Werkvertrag nach § 631 BGB einzustufen. Geschuldet wird nicht das bloße Tätigwerden, sondern ein mangelfreier, funktionstüchtiger Gesamterfolg.

Für die Dokumentation zieht die Rechtsprechung weitreichende Konsequenzen:

1. Dokumentation als Werkerfolg: Der BGH hat bereits mit Urteil vom 14.07.1993 (Az. VIII ZR 147/92) entschieden, dass Individualsoftware erst dann fertiggestellt ist, wenn neben dem Quellcode auch die dazugehörige Dokumentation vollständig übergeben wurde.

2. Mangelhafte Dokumentation als Sachmangel: Mit Urteil vom 18.02.2003 (Az. X ZR 245/00) stellte der BGH klar, dass eine fehlende, unvollständige oder vom tatsächlichen Programmverhalten abweichende Dokumentation einen Sachmangel nach § 633 BGB begründet.

3. Fälligkeit erst bei Abnahme: Nach § 641 Abs. 1 BGB wird die Vergütung erst mit der förmlichen Abnahme des Werks fällig. Verweigert der Kunde die Abnahme wegen unvollständiger Dokumentation oder ungeklärter Anforderungen zu Recht, verliert der Entwickler jeglichen Zahlungsanspruch für die zurückliegenden Entwicklungsmonate.

Die empirische Dimension unklarer Vorgaben belegt die Standish Group in ihren weltweiten CHAOS-Studien an über 50.000 IT-Projekten. Danach scheitern 19 Prozent aller Softwareprojekte vollständig, während 50 Prozent gefährdet sind, weil Zeitpläne, Budgets oder Leistungsziele verfehlt werden. In über 40 Prozent der untersuchten Problemprojekte bilden unvollständige Anforderungen, wechselnde Spezifikationen und lückenhafte Dokumentation die primäre Ursache für die Krise.

Vor der Abnahme trägt der Freiberufler die volle Beweislast für die Mängelfreiheit

Das Bürgerliche Gesetzbuch knüpft an die Abnahme nach § 640 BGB eine strikte Zweiteilung der juristischen Risikosphäre. Vor und nach diesem Meilenstein gelten gegensätzliche Spielregeln für die Beweisführung:

1. Phase vor der Abnahme: Bis zur förmlichen Abnahmeerklärung trägt der Freiberufler die uneingeschränkte Darlegungs- und Beweislast dafür, dass die entwickelte Software mangelfrei ist und exakt den vereinbarten Spezifikationen entspricht. Liegt kein detailliertes Pflichtenheft vor, sondern nur eine lose Sammlung von Diskussionspunkten oder User Stories, kann der Entwickler die Vertragskonformität vor Gericht faktisch nicht belegen. Behauptet der Kunde, eine bestimmte Plausibilitätsprüfung oder Schnittstellenfunktion sei vereinbart gewesen, geht jede Unklarheit zulasten des Entwicklers.

2. Phase nach der Abnahme: Erst mit der Abnahme kehrt sich die Beweislast nach § 363 BGB um. Ab diesem Moment muss der Kunde beweisen, dass die Software von der vertraglichen Vereinbarung abweicht und ein Sachmangel vorliegt. Zugleich wird die Vergütung fällig (§ 641 BGB), und die Verjährungsfrist für Mängelansprüche beginnt zu laufen (§ 634a BGB).

Im agilen Projektalltag führt das sogenannte Scope Creep, das schrittweise Hineinwachsen neuer Anforderungen ohne schriftliche Nachtragsvereinbarungen, in eine Beweisfalle. Werden Änderungswünsche mündlich im Videocall besprochen oder formlos in Chats ausgetauscht, existiert kein rechtsverbindlicher Änderungsnachweis. Kommt es später zum Zerwürfnis, verweigert der Auftraggeber die Abnahme und beruft sich auf den ursprünglichen Projektumfang. Der Entwickler kann weder beweisen, dass die Änderungen beauftragt wurden, noch dass das erweiterte System die vertraglichen Kriterien erfüllt.

Zur Absicherung empfiehlt sich eine lückenlose Dokumentationskette: Jede Spezifikationsänderung verlangt eine formalisierte Bestätigung durch den Kunden (Change Request mit Beschreibung, Mehrkosten und Zeitverschiebung). Technische Nachweise lassen sich durch signierte Git-Commits und kryptografische Zeitstempel absichern, die den genauen Stand einer Freigabe manipulationssicher festhalten.

Bagatellfehler an Schnittstellen lösen sechsstellige Schadensersatzforderungen aus

Zwischen dem vereinbarten Honorar eines Softwareentwicklers und dem potenziellen Schaden, der durch einen Programmierfehler entstehen kann, besteht im Zivilrecht keine Proportionalität. Nach § 280 Abs. 1 und § 634 Nr. 4 BGB haftet der Auftragnehmer bei schuldhafter Pflichtverletzung für den gesamten daraus resultierenden Vermögensschaden des Kunden.

Reale Schadenakten der auf IT-Berufe spezialisierten Exali AG illustrieren, wie minimale syntaktische oder semantische Missverständnisse existenzbedrohende Forderungen nach sich ziehen:

1. Der Fall des Lead-Formulars (750.000 Euro Schadenersatzforderung): Ein freiberuflicher Entwickler erhielt über eine zwischengeschaltete IT-Agentur den Auftrag zur Programmierung eines Formulars zur Lead-Generierung für einen Großkonzern. Das Gesamthonorar des Freiberuflers für diese Kette betrug 15.000 Euro. Der Entwickler testete das Formular im Entwicklungsstadium ausgiebig, konnte den finalen Versand an die echten Zieladressen des Konzerns jedoch nicht prüfen, da diese erst unmittelbar vor dem Live-Gang bereitgestellt wurden. Durch einen einzelnen Tippfehler bei einem Variablenbezeichner (ein versehentlich gesetztes Zeichen $) schlug die Weiterleitung der Formulardaten an das Vertriebssystem fehl. Die Daten wurden zwar in der Datenbank gespeichert, blieben dort jedoch acht Wochen lang unbemerkt liegen. In diesem Zeitraum sammelten sich 2.970 Interessentendaten an. Als der Fehler entdeckt wurde, waren die Leads veraltet und vertrieblich entwertet. Der Großkonzern kürzte das Werbebudget der Agentur drastisch. Die Agentur forderte daraufhin 150.000 Euro für nutzlos aufgewendete Werbeflächen sowie 600.000 Euro wegen entgangenen Gewinns vom IT-Dienstleister und dem Freiberufler ein. Nach acht Monaten außergerichtlicher Verhandlungen schloss der Haftpflichtversicherer einen Vergleich über 200.000 Euro ab, um den Ruin des Entwicklers abzuwenden.

2. Der Fall des Sportverbands (23.000 Euro Neudruckkosten): Ein Programmierer erstellte eine Routine zur automatischen Generierung von Mitgliedsausweisen für einen Sportverband. Aufgrund eines Missverständnisses hinsichtlich des Datumsformats und der Gültigkeitslogik wiesen 30.000 gedruckte Plastikkarten fehlerhafte Gültigkeitszeiträume auf, wodurch den Mitgliedern der Einlass verwehrt wurde. Der Verband forderte die gesamten Kosten für Neudruck, Neuverpackung und Einzelversand in Höhe von 23.000 Euro erfolgreich vom Entwickler zurück.

Beide Fälle verdeutlichen: Missverständnisse an Schnittstellen und Validierungsroutinen entfalten ihre Schadenswirkung erst in der Massenverarbeitung. Ohne spezialisierte IT-Haftpflichtversicherung, die Vermögensschäden und passive Abwehr unberechtigter Ansprüche abdeckt, führt ein einziger Tippfehler in die persönliche Zahlungsunfähigkeit.

Das Urteil des OLG Frankfurt: Warum Schnittstellenentwicklung rechtlich ein Dienstvertrag ist

Während die Erstellung eigenständiger Individualsoftware nach BGH-Rechtsprechung dem Werkvertragsrecht unterfällt, hat das Oberlandesgericht Frankfurt am Main für Schnittstellenprojekte eine grundlegende Schutzentscheidung getroffen.

Mit Urteil vom 19.12.2024 (Az. 10 U 201/22) wies das OLG Frankfurt die Klage eines Auftraggebers ab, der die Rückzahlung von über 33.000 Euro geleisteter Stundenhonorare für eine gescheiterte Schnittstellenprogrammierung verlangt hatte. Der Senat stellte tragende Leitsätze für die Vertragsauslegung auf:

1. Unvorhersehbare Drittsysteme begründen Dienstvertragscharakter: Wenn ein Entwickler beauftragt wird, eine Schnittstelle (API) zwischen zwei komplexen, von Dritten bereitgestellten Softwaresystemen zu bauen, kann typischerweise kein werkvertraglicher Funktionserfolg geschuldet sein. Weil das Zusammenspiel maßgeblich von Parametern, Updates und Fehlern fremder Systeme abhängt, die der Entwickler weder kontrollieren noch modifizieren kann, liegt das Risiko des Gelingens in der Sphäre des Auftraggebers.

2. Abrechnungsmodus und Kündigungsmöglichkeit als Auslegungskriterien: Haben die Vertragspartner eine Vergütung nach Zeitaufwand (Stundensätze) mit monatlicher Abrechnung und beiderseitigen Kündigungsfristen vereinbart, spricht dies entscheidend für einen Dienstvertrag nach § 611 BGB. Der Entwickler schuldet fachgerechtes Bemühen nach dem Stand der Technik, aber keine Garantie für eine reibungslose Systemharmonisierung.

3. Kein Rückforderungsanspruch bei Projektabbruch: Bricht der Auftraggeber das Projekt vorzeitig ab, weil die Schnittstelle nicht wie gewünscht arbeitet, behält der Freiberufler den Anspruch auf das Honorar für alle bis dahin erbrachten Arbeitsstunden.

Diese Position wird durch frühere Rechtsprechung gestützt: Bereits das OLG Koblenz stellte mit Urteil vom 12.11.2015 (Az. 1 U 1331/13) klar, dass Planungs-, Konzeptions- und Dokumentationsleistungen im IT-Bereich ihren wirtschaftlichen Vergütungswert behalten, selbst wenn das übergeordnete Gesamtsystem später nicht realisiert wird. Für Freiberufler folgt daraus die strategische Vertragsregel: Schnittstellen- und Integrationsarbeiten müssen im Vertragstext explizit als abhängige Integrationsdienstleistung nach Zeitaufwand definiert werden, um die werkvertragliche Erfolgsfalle zu meiden.

Engmaschige Jira-Dokumentation schützt vor Mängelhaftung, erzeugt aber Scheinselbstständigkeitsverdacht

Bei dem Versuch, Missverständnisse durch intensive Kommunikation und detaillierte Dokumentation auszuschließen, geraten Software-Freiberufler in ein juristisches Dilemma:

1. Dokumentiert der Entwickler zu wenig, haftet er im Zivilrecht für Mängel und Abnahmeverzögerungen (§§ 633, 640 BGB).

2. Dokumentiert und kommuniziert er zu engmaschig im System des Kunden, stuft die Deutsche Rentenversicherung (DRV) das Auftragsverhältnis als sozialversicherungspflichtige Scheinselbstständigkeit nach § 7 Abs. 1 SGB IV ein.

Die Prüfpraxis der Clearingstelle der DRV bei Statusfeststellungsverfahren nach § 7a SGB IV wertet typische Werkzeuge agiler Softwareentwicklung häufig als Indizien für abhängige Beschäftigung:

• Tägliche Teilnahme an internen Abstimmungen (Daily Standups) wird als Weisungsgebundenheit und zeitliche Kontrolle ausgelegt.

• Das Zuweisen von Aufgaben über Ticket-Systeme wie Jira gilt als Zuweisung von Einzelweisungen durch den Projektleiter.

• Die Nutzung kundeneigener Entwicklungsrechner, GitLab-Instanzen und Kommunikationskanäle (Slack, Teams) wird als Eingliederung in den fremden Betrieb gewertet.

Wird ein Freiberufler rückwirkend als Scheinselbstständiger eingestuft, drohen drastische finanzielle Folgen. Der Auftraggeber muss die Gesamtsozialversicherungsbeiträge (Arbeitgeber- und Arbeitnehmeranteile) für bis zu vier Jahre rückwirkend zuzüglich Säumniszuschlägen nachentrichten. Für den Freiberufler droht der Verlust des steuerlichen Status, die Rückforderung von Vorsteuerbeträgen durch das Finanzamt und die Verpflichtung zur Rückzahlung erhaltener Honorare im Wege des Bereicherungsausgleichs.

Fünf Kriterien des Landessozialgerichts für rechtssichere Selbstständigkeit im Scrum-Team

Dass Agilität und selbstständige Erwerbstätigkeit rechtlich miteinander vereinbar sind, hat das Landessozialgericht Baden-Württemberg in einem richtungsweisenden Urteil vom 17.12.2021 (Az. L 4 BA 75/20) entschieden. Das Gericht hob den Bescheid der DRV auf und stellte fest, dass die Mitarbeit eines Softwareentwicklers in einem agilen Scrum-Team keine Scheinselbstständigkeit begründet, wenn bestimmte Arbeitsweisen eingehalten werden.

Aus dem Urteil lassen sich fünf konkrete Kriterien ableiten, die Freiberufler im Projektalltag zwingend beachten müssen:

1. Das Pull-Prinzip im Backlog: Der Freiberufler darf keine Aufgaben vom Scrum Master oder Product Owner zugewiesen bekommen. Die Dokumentation muss belegen, dass er sich die Arbeitspakete (Tickets) im Backlog eigenverantwortlich nach seiner fachlichen Spezialisierung selbst auswählt (Pull statt Push).

2. Keine Verhaltenskontrolle während der Bearbeitung: Sobald ein Ticket übernommen wurde, agiert der Entwickler fachlich vollkommen autonom. Weder der Kunde noch Teamleiter dürfen Vorschriften darüber machen, wie der Code im Detail strukturiert wird, an welchem Ort gearbeitet wird oder wie die tägliche Zeiteinteilung aussieht. Daily Standups dienen ausschließlich dem fachlichen Informationsaustausch, nicht der Arbeitskontrolle.

3. Getrennte Entwicklungszweige und Code-Lieferung: Der Freiberufler committet seinen Code nicht direkt auf den Hauptzweig (Main Branch) der Stammbelegschaft. Die Übergabe erfolgt über separate Feature-Branches oder ein eigenes Repository. Erst nach einer formalen Qualitätsprüfung (Code Review) wird der Code durch den Kunden integriert. Dies belegt die werk- oder dienstvertragliche Abgrenzung des Arbeitsergebnisses.

4. Deutlich überdurchschnittliches Honorar: Ein marktüblicher Stundensatz oder Tagessatz, der signifikant über dem Bruttogehalt eines vergleichbaren angestellten Entwicklers liegt, ist nach ständiger Rechtsprechung des Bundessozialgerichts ein gewichtiges Indiz für unternehmerische Selbstständigkeit. Das Honorar muss es dem Freiberufler ermöglichen, eigenverantwortlich Rücklagen für Krankheit, Urlaub und Altersvorsorge zu bilden.

5. Unternehmerisches Auftreten und Investitionen: Der Entwickler nutzt eigene Hardware, eigene Entwicklungsumgebungen und Softwarelizenzen. Er betreibt eigenes Marketing und unterliegt keiner Mindestabnahmeverpflichtung, sodass er das unternehmerische Risiko des Leerlaufs selbst trägt.

Was an bisherigen Rechtsratgebern überholt ist: Allgemeine Klauseln schützen Entwickler nicht

Zahlreiche Standardbeiträge im Internet vermitteln Freelancern ein trügerisches Sicherheitsgefühl, indem sie veraltete oder unwirksame Vertragsmuster empfehlen. Drei Annahmen haben sich in der gerichtlichen Praxis als überholt erwiesen:

1. Die Überschrift bestimmt nicht den Vertragstyp: Die bloße Bezeichnung eines Vertrags als freier Dienstvertrag oder Beratervertrag ist juristisch bedeutungslos. Gerichte prüfen nach dem Grundsatz der praktischen Ausgestaltung, was tatsächlich vereinbart und gelebt wurde. Wird die Erstellung eines schlüsselfertigen Webshops vereinbart, greift das Werkvertragsrecht mit voller Mängelhaftung, selbst wenn im Dokumentenkopf das Wort Dienstvertrag steht.

2. Pauschale Haftungsausschlüsse sind unwirksam: Formulierungen in Allgemeinen Geschäftsbedingungen (AGB), die jede Haftung für Programmierfehler oder Folgeschäden ausschließen, halten der richterlichen Inhaltskontrolle nach § 307 BGB nicht stand. Die Freizeichnung von Kardinalpflichten (den wesentlichen Vertragspflichten, deren Erfüllung die ordnungsgemäße Durchführung des Vertrags überhaupt erst ermöglicht) ist nach § 307 Abs. 2 Nr. 2 BGB unzulässig. Ein Haftungsausschluss muss stattdessen differenziert gestaltet sein, etwa durch die Begrenzung auf vorhersehbare, vertragstypische Schäden und den Ausschluss einfacher Fahrlässigkeit bei unkritischen Nebenpflichten.

3. Das Missverständnis des agilen Festpreises: Das Modell eines agilen Festpreisvertrags, bei dem Budget und Fertigstellungstermin starr vorgegeben werden, der Funktionsumfang aber agil im Projektverlauf entstehen soll, stellt das höchste Haftungsrisiko für Freiberufler dar. Vor Gericht wird eine solche Vereinbarung als Werkvertrag mit Festpreis gewertet. Kann der Entwickler den erweiterten Funktionsumfang zum Stichtag nicht mangelfrei vorlegen, gerät er in Verzug, verliert den Anspruch auf Mehrvergütung und schuldet Schadensersatz.

Grenzen der Rechtslage: Wo KI-Code und Haftungsausschlüsse noch ungeklärt sind

Dieser Beitrag stützt sich auf gesicherte Gesetzeslagen und gerichtliche Präzedenzfälle. Die rasante technische Entwicklung bringt jedoch Schnittstellenprobleme hervor, für die es in der deutschen Rechtsprechung bislang an höchstrichterlichen Leitentscheidungen fehlt:

1. Zivilrechtliche Haftung für KI-generierten Quellcode: Wenn Freiberufler Programmierassistenten wie GitHub Copilot oder Cursor einsetzen und durch eine KI-Halluzination eine fehlerhafte Schnittstellenlogik entsteht, stellt sich die zivilrechtliche Frage des Verschuldens. Bislang ist obergerichtlich nicht entschieden, ob die ungeprüfte Übernahme von KI-Code als grobe Fahrlässigkeit gewertet wird, die den Schutz von Haftungsbeschränkungen in Entwicklerverträgen aushebelt.

2. Wirksamkeit von Haftungsbegrenzungssummen in Entwickler-AGB: In Entwicklerverträgen ist es üblich, die Haftung auf das Ein- bis Dreifache der Auftragssumme zu deckeln. Ob eine solche Deckelung vor den Zivilgerichten Bestand hat, wenn durch einen simplen Validierungsfehler ein unverhältnismäßig hoher Schaden (wie im dargestellten 750.000-Euro-Fall) entsteht, wird von den Landgerichten uneinheitlich bewertet, sobald Kunden die Verletzung vertragswesentlicher Pflichten rügen.

3. Statusfeststellung bei vollautomatisierten Agenten-Pipelines: Mit dem Aufkommen autonomer KI-Agenten verschiebt sich die Wertschöpfung bei manchen Freiberuflern von der persönlichen Programmierleistung hin zur Bereitstellung konfigurierter Softwaresysteme. Ob die Deutsche Rentenversicherung bei solchen Systembetreibern weiterhin das Kriterium der höchstpersönlichen Leistungserbringung zur Begründung einer abhängigen Beschäftigung heranziehen kann, ist sozialgerichtlich noch nicht erprobt.

Quellen

Alle Abrufe am 17.10.2026.

• [1] Bundesgerichtshof (BGH), Urteil vom 14.07.1993, Az. VIII ZR 147/92 (Computer und Recht, CR 1993, S. 681). Leitsatz zur Fertigstellung von Individualsoftware erst mit Übergabe der vollständigen Softwaredokumentation. • [2] Bundesgerichtshof (BGH), Urteil vom 18.02.2003, Az. X ZR 245/00 (Neue Juristische Wochenschrift, NJW 2003, S. 1718). Grundsatzurteil zur Einordnung einer mangelhaften Softwaredokumentation als Sachmangel nach § 633 BGB. • [3] Bundesgerichtshof (BGH), Urteil vom 24.10.2002, Az. VII ZR 332/01. Qualifikation von Softwareentwicklungsverträgen als Werkverträge und Fälligkeit des Vergütungsanspruchs erst nach förmlicher Abnahme gemäß § 641 BGB. • [4] Oberlandesgericht Frankfurt am Main (OLG Frankfurt a. M.), Urteil vom 19.12.2024, Az. 10 U 201/22. Qualifikation von Schnittstellenentwicklungen (APIs) nach Zeitaufwand als Dienstvertrag nach § 611 BGB, Ausschluss von Honorarrückforderungen bei vorzeitigem Projektabbruch. • [5] Landessozialgericht Baden-Württemberg (LSG Baden-Württemberg), Urteil vom 17.12.2021, Az. L 4 BA 75/20. Leitentscheidung zur Statusfeststellung im agilen Scrum-Team: Widerlegung der Scheinselbstständigkeit durch Pull-Prinzip, Autonomie und Feature-Branch-Lieferung. • [6] Oberlandesgericht Koblenz (OLG Koblenz), Urteil vom 12.11.2015, Az. 1 U 1331/13. Urteil zum Vergütungsanspruch von Planungs-, Konzeptions- und Dokumentationsleistungen bei abgebrochenen Softwareprojekten. • [7] Bürgerliches Gesetzbuch (BGB), Fassung Stand 2026. §§ 280 (Schadensersatz), 307 (Inhaltskontrolle von AGB), 363 (Beweislast bei Annahme), 611 (Dienstvertrag), 631 (Werkvertrag), 633 (Sachmangel), 634 (Rechte bei Mängeln), 640 (Abnahme), 641 (Fälligkeit der Vergütung). • [8] Sozialgesetzbuch Viertes Buch (SGB IV), Gemeinsame Vorschriften für die Sozialversicherung, Fassung Stand 2026. § 7 Abs. 1 (Beschäftigung, Weisungsgebundenheit und Eingliederung), § 7a (Statusfeststellungsverfahren). • [9] Standish Group, CHAOS Report und Decision Latency Studies, Langzeitstudie an mehr als 50.000 weltweiten IT-Projekten zu Erfolgs- und Scheiternsquoten in der Softwareentwicklung: https://www.standishgroup.com/ • [10] Exali AG, Gewerbliche Schadenakten der IT-Haftpflichtversicherung, Dokumentation von Schadenfällen aus Programmierfehlern, Lead-Formularen und Datumsvalidierungen: https://www.exali.de/Info-Base/passiver-rechtsschutz-schadenfall • [11] Hiscox Deutschland, Vertrags- und Risikoanalyse für IT-Freiberufler, Franz Kupfer, Untersuchung zu Dienst- und Werkverträgen sowie Scheinselbstständigkeit: https://www.hiscox.de/blog/dienstvertrag-vs-werkvertrag/