Beispiel SOW Web-Entwickler: Komplette Pauschalvergütungsmission

Warum ein solides SOW für eine Pauschalvergütungs-Web-Entwicklungsmission verfassen?

Wenn ein Unternehmen einen unabhängigen Web-Entwickler oder eine Agentur für eine Pauschalvergütungsmission beauftragt, besteht die Versuchung, sich auf ein einfaches Angebot oder E-Mail-Austausche zu stützen. Dies ist jedoch eine der Hauptquellen für Streitigkeiten in der Kundenbeziehung zwischen Technik-Dienstleister und Auftraggeber: schlecht definierter Projektumfang, umstrittene Lieferungen, unklar spezifizierte Rechte am Quellcode. Das Statement of Work (SOW) ist das Vertragsdokument, das alle diese Risiken verhindert, indem es Punkt für Punkt formalisiert, was jede Partei tun muss, wann, und nach welchen Erfolgskriterien.

Bei einem Festpreisauftrag — im Gegensatz zur Regie — verpflichtet sich der Dienstleister zu einem genau definierten Ergebnis für einen festen Preis. Gerade diese Vertragsnatur macht die Ausarbeitung des SOW noch kritischer: Jede Grauzone verwandelt sich in eine Meinungsverschiedenheit darüber, was im Leistungsumfang „enthalten" war oder nicht. Ein schlecht definierter Leistungsumfang ist eine häufige Quelle für Streitigkeiten bei IT-Dienstleistungsverträgen.

In diesem Leitfaden beschreiben wir die Struktur eines vollständigen Beispiel-SOW für Web-Entwickler für eine Pauschalvergütungsmission und behandeln Leistungen, Akzeptanzkriterien, geistiges Eigentum und Abtretung von Quellcode. Für weitere Informationen zu den Grundlagen konsultieren Sie unseren umfassenden SOW-Leitfaden: Muster, Klauseln und elektronische Signatur.

---

Typische Struktur eines SOW für einen Web-Entwickler in einer Pauschalvergütungsmission

Ein gut strukturiertes SOW folgt einer logischen Architektur, die vom Allgemeinen zum Spezifischen fortschreitet. Hier sind die notwendigen Abschnitte für eine Web-Entwicklungsmission.

1. Kopf- und Identifizierung der Parteien

Das Dokument beginnt mit der genauen Identifizierung der beiden Parteien: der Auftraggeber (Kundenunternehmen mit Rechtsform, SIREN-Nummer, Geschäftsführer und dessen Titel) und der Dienstleister (unabhängiger Entwickler oder Unternehmen). Es wird auch angegeben:

• Die Nummer des SOW (besonders wenn es in einen MSA – Master Services Agreement – eingebettet ist)

• Das Datum des Inkrafttretens

• Die voraussichtliche Dauer der Mission

• Die Projektverantwortlichen auf Kundenseite und auf Dienstleisterseite

Dieser Abschnitt erscheint zwar trivial, ist aber im Streitfall entscheidend: Er bestimmt die Ansprechpartner, die berechtigt sind, Leistungen abzunehmen und Änderungen zu unterzeichnen.

2. Umfang und Beschreibung der Leistungen

Dies ist das Herzstück des Dokuments. Bei einer Pauschalvergütungs-Web-Entwicklungsmission muss der Umfang mit nahezu technischer Präzision beschrieben werden.

Beispiel für eine E-Commerce-Webanwendung:

> Der Dienstleister verpflichtet sich, eine responsive E-Commerce-Webanwendung basierend auf Next.js 14 (React-Framework) zu entwerfen, zu entwickeln und bereitzustellen, verbunden mit einer REST-API Back-End Node.js/Express, mit Stripe-Integration für Online-Zahlungen. Die Anwendung wird folgende Module enthalten: Produktkatalog (bis zu 5.000 Artikel), Warenkorb, Checkout-Prozess in 3 Schritten, sicherer Kundenbereich (JWT), Administrator-Dashboard.

Jede Leistung muss einzeln mit folgenden Angaben aufgelistet werden:

• Ihr Titel (z.B. „Benutzerauthentifizierungsmodul")

• Ihre funktionale Beschreibung (was es tut, nicht wie es umgesetzt wird)

• Geplantes Lieferdatum (oder Meilensteine nach Sprint/Phase)

• Lieferformat (Git-Repository, Staging-URL, ZIP-Datei, technische Dokumentation)

Bei komplexen Projekten wird empfohlen, ein funktionales Anforderungsdokument (CDC) oder Agile User Stories anzuhängen, auf die das SOW ausdrücklich verweist.

3. Akzeptanzkriterien: Wie wird jede Leistung validiert?

Dies ist der am häufigsten vernachlässigte und umstrittenste Abschnitt. Akzeptanzkriterien definieren objektiv die Bedingungen, unter denen der Kunde anerkennt, dass eine Leistung konform ist.

Beispiel von Akzeptanzkriterien für eine Webanwendung:

Das SOW muss auch folgende Punkte klären:

• Abnahmeprozedur: wer testet, mit welchen Werkzeugen, innerhalb welcher Frist nach Lieferung (Beispiel: der Kunde hat 10 Arbeitstage zur Validierung oder um motivierte schriftliche Einwände zu formulieren)

• Umgang mit Einwänden: Geringfügige Einwände (kosmetische Fehler) blockieren nicht die Zahlung; wesentliche Einwände (nicht funktionsfähige Funktionalität) halten die Zahlung an, bis sie behoben sind

• Stillschweigen bedeutet Zustimmung: Nach Ablauf der Abnahmefrist ohne schriftliche Rückmeldung gilt die Leistung als akzeptiert

Dieser formelle Annahmemechanismus ist entscheidend in der Pauschalvergütung. Um die Unterzeichnung von Abnahmeprotokollen zu automatisieren, setzen viele IT-Leiter inzwischen auf elektronische Signaturen im Unternehmen, die gemäß der eIDAS-Verordnung eine mit der handschriftlichen Unterschrift gleichwertige Beweiskraft haben.

4. Finanzielle Bedingungen und Zahlungsmeilensteine

Bei einer Pauschalvergütungsmission ist die Zahlungsstruktur normalerweise an den Projektfortschritt und nicht an die aufgewendete Zeit gebunden.

Beispiel eines Zahlungsplans für ein Projekt mit 24.000 € netto:

• 30 % bei Unterzeichnung des SOW: 7.200 € netto (Anzahlung, deckt Planungs-/Architekturphase ab)

• 30 % bei Lieferung von Sprint 1 (Leistungen 1 bis 4 validiert): 7.200 € netto

• 25 % bei Lieferung von Sprint 2 (Leistungen 5 bis 8 validiert): 6.000 € netto

• 15 % bei finaler Abnahme und Produktionsfreigabe: 3.600 € netto

Das SOW legt Verzugsstrafungen auf Seite des Dienstleisters fest (z.B. 0,5 % des Gesamtbetrags pro Woche Verspätung, begrenzt auf 10 %) und Verzugsstrafungen auf Kundenseite für Validierungsverzögerungen (z.B. Verlängerung der Gesamtfrist um einen Betrag, der dem Validierungsverzug entspricht).

5. Geistiges Eigentum und Abtretung von Quellcode

Dies ist der rechtlich sensibelste Abschnitt für jeden Web-Entwicklungsvertrag. Standardmäßig behält der Autor eines Werkes der Geistestätigkeit – einschließlich einer Software – gemäß französischem Recht (Code de la propriété intellectuelle, Art. L. 111-1) die Rechte, auch nach Lieferung und Zahlung. Mit anderen Worten: Ohne explizite Abtretungsklausel zahlt der Kunde die Entwicklung, besitzt aber rechtlich nicht den Code.

Ein gut formuliertes SOW muss eine vollständige Abtretungsklausel enthalten. Hier ist ein Beispiel für eine Formulierung:

> Im Gegenzug für die vollständige Zahlung des vereinbarten Preises tritt der Dienstleister dem Kunden alle Vermögensrechte an den ursprünglichen Leistungen, die speziell im Rahmen dieses SOW entwickelt wurden, endgültig und ausschließlich ab, einschließlich der Rechte zur Vervielfältigung, Verbreitung, Bearbeitung, Übersetzung, Änderung und kommerziellen Nutzung, für die ganze Welt und für die gesamte gesetzliche Schutzdauer des Urheberrechts.

Das SOW muss auch unterscheiden zwischen:

• Eigenem Code (speziell für dieses Projekt entwickelt → wird dem Kunden abgetreten)

• Komponenten von Drittanbietern (Frameworks, Open-Source-Bibliotheken → der Dienstleister garantiert deren Konformität mit anwendbaren Lizenzen)

• Werkzeuge und Methoden des Dienstleisters (Know-how, Boilerplates → bleiben Eigentum des Dienstleisters)

• Open-Source-Abhängigkeiten: Komponenten und deren Lizenzen auflisten (MIT, Apache 2.0, LGPL...), um Lizenzverletzungen auszuschließen

Bei Missionen mit innovativen Entwicklungen, die gegebenenfalls patentierbar oder als Software geschützt sein könnten, konsultieren Sie unseren INPI-Hub: Signatur, Hinterlegung und Bescheinigung zur Sicherung der Rechte bereits in der Entwicklungsphase.

Abschließend muss das SOW eine Klausel zur Sicherung des Quellcodes (Source Code Escrow) enthalten, wenn der Kunde sich gegen einen Ausfall des Dienstleisters absichern möchte: Der Code wird bei einem unabhängigen Treuhänder hinterlegt und unter vordefinierten Bedingungen freigegeben (Insolvenz des Dienstleisters, Verstoß gegen SLA usw.).

---

Zusätzliche notwendige Klauseln in einem Web-Entwicklungs-SOW

Vertraulichkeit und integrierte NDA

Der Dienstleister hat Zugriff auf vertrauliche Informationen: technische Architektur, Kundendaten, Produktroadmap. Das SOW muss eine Vertraulichkeitsklausel enthalten (oder auf eine separat unterzeichnete NDA verweisen) mit Abdeckung für:

• Die Dauer der Verpflichtung (typischerweise 3 bis 5 Jahre nach Ende der Mission)

• Definition von vertraulichen Informationen

• Ausnahmen (bereits öffentliche Informationen, legitim von Dritten erhalten)

• Rückgabe- oder Vernichtungsverpflichtungen nach Beendigung des Vertrags

Garantien und Post-Liefer-Wartung

Bei Pauschalvergütung gelten Mängelgewährleistungen gesetzlich, aber das SOW präzisiert deren operative Reichweite:

• Gewährleistung der Funktionsfähigkeit: Während X Monate nach finaler Abnahme behebt der Dienstleister kostenlos alle auf seine Entwicklung zurückzuführenden Fehler (ohne Funktionserweiterungen)

• SLA für Fehlerbehebung: Blockierender Fehler innerhalb 24 Arbeitsstunden behoben; wesentlicher Fehler innerhalb 72 Stunden; geringfügiger Fehler in nächstem Zyklus integriert

• Ausschlüsse von der Gewährleistung: Durch den Kunden am Code vorgenommene Änderungen, nicht vom Dienstleister validierte Abhängigkeitsaktualisierungen

Unterauftragsvergabe und Personalressourcen

Der Kunde sollte wissen, ob der Dienstleister alle oder Teile der Entwicklungen unterauftragen kann. Falls eine Zustimmungsklausel nach vorheriger Genehmigung gewünscht ist (besonders aus Gründen der Vertraulichkeit oder DSGVO-Konformität), muss sie im SOW enthalten sein. Bei kritischen Missionen verlangen einige Kunden sogar die Benennung der beteiligten Entwickler und vorherige Zustimmung bei Team-Wechseln.

Für SOWs, die mit ausländischen Dienstleistern oder in multipartiter Konstellation unterzeichnet werden, ermöglicht die eIDAS-konforme elektronische Signaturfunktion von Certyneo die Fernunterzeichnung mit in allen 27 EU-Mitgliedstaaten anerkannter Beweiskraft.

---

Best Practices zum Finalisieren und Unterzeichnen Ihres SOW

Review- und Änderungsprozess

Vor der Unterzeichnung muss das SOW von folgenden Parteien überprüft werden:

• Technischer Projektmanager auf Kundenseite (Validierung des funktionalen Umfangs)

• Jurist oder CFO (Validierung finanzieller, IP- und Strafklauseln)

• CISO bei Verarbeitung personenbezogener oder sensibler Daten (DSGVO-Konformität)

Jede während des Projekts erfolgende Umfangsänderung muss Gegenstand einer unterzeichneten Change Order (Änderung) sein und legt die Auswirkungen auf Fristen und Preis fest. Ohne unterzeichnete Änderung gilt jede Änderungsanforderung als außerhalb des Umfangs.

Elektronische Unterzeichnung des SOW

Die handschriftliche Unterzeichnung eines SOW führt zu zeitaufwendigen Papierwechseln und ist fehleranfällig (nicht aktualisierte Version unterzeichnet, fehlende Unterschrift). Die fortgeschrittene oder qualifizierte elektronische Signatur, konform zur eIDAS-Verordnung, bietet mehrere entscheidende Vorteile für diesen Dokumenttyp:

• Verstärkte Beweiskraft: Qualifizierter Zeitstempel, sichere Identifizierung der Unterzeichner

• Geschwindigkeit: Ein SOW kann in wenigen Minuten unterzeichnet werden, auch mit einem Dienstleister im Home Office oder im Ausland

• Automatische Archivierung: Das unterzeichnete Dokument wird unfälschbar gespeichert

• Versionsverfolgung: Verhindert die Unterzeichnung einer alten Version

Unser Vergleich elektronischer Signaturfunktionen hilft Ihnen, das der Wert und Sensibilität Ihrer SOWs entsprechende Signaturlevel zu wählen. Bei Missionen über 50.000 € oder mit erweiterten IP-Abtretungsklauseln wird qualifizierte Signatur (höchstes eIDAS-Level) empfohlen.

Um die Dokumentenerstellung zu beschleunigen, ermöglicht unser KI-gestützter Vertragsassistent die Erstellung eines personalisierten SOW-Entwurfs in wenigen Minuten basierend auf Ihren Missionsparametern.

Anwendbares Rechtsrahmenwerk für Web-Entwicklungs-SOWs

Zivilgesetzbuch und verbindliche Kraft von Verträgen

Das SOW ist zunächst ein Vertrag im Sinne von Artikel 1101 des französischen Zivilgesetzbuches: „Ein Vertrag ist eine Übereinkunft zwischen zwei oder mehr Personen, die dazu bestimmt ist, Verpflichtungen zu schaffen, zu ändern, zu übertragen oder auszulöschen." Seine verbindliche Kraft wird in Artikel 1103 festgestellt: „Legale gebildete Verträge sind Gesetz für diejenigen, die sie geschlossen haben." Sobald es von beiden Parteien unterzeichnet ist, ist das SOW rechtlich bindend, einschließlich seiner technischen Anhänge und Leistungstabellen.

Die elektronische Unterzeichnung des SOW wird durch die Artikel 1366 und 1367 des Zivilgesetzbuches geregelt, die dem elektronisch unterzeichneten Dokument die gleiche Beweiskraft wie papiergebundenen Schriftstücken zuerkennen, vorausgesetzt, dass die Identität des Unterzeichners ordnungsgemäß überprüft ist und die Dokumentintegrität garantiert ist.

eIDAS-Verordnung Nr. 910/2014 und ETSI-Norm

Für zwischen europäischen Unternehmen elektronisch unterzeichnete SOWs definiert die eIDAS-Verordnung (Nr. 910/2014 des Europäischen Parlaments und des Rates) drei Stufen elektronischer Signaturen: einfach, fortgeschritten und qualifiziert. Die fortgeschrittene elektronische Signatur (FES) basiert auf ETSI-Normen EN 319 132 (XAdES) und ETSI EN 319 122 (CAdES), die die Dokumentintegrität und die Identifizierung des Unterzeichners garantieren. Für vertragliche Verpflichtungen mit hohem finanziellen Einsatz oder mit Quellcode-Abtretungsklauseln wird die qualifizierte Signatur (QES), basierend auf einem von einem qualifizierten Vertrauensdiensteanbieter (QTSP) in der europäischen Vertrauensliste (TSL) eingetragenen Zertifikat, empfohlen.

Code de la propriété intellectuelle (CPI)

Die Abtretung von Rechten am Quellcode wird durch den Code de la propriété intellectuelle geregelt. Artikel L. 111-1 CPI begründet die urheber- und Vermögensrechte des Autors an jedem Werk der Geistestätigkeit, einschließlich Software (Artikel L. 112-2, 13°). Die Abtretung von Vermögensrechten muss gemäß Artikel L. 131-3 CPI jedes abgetretene Recht, Territorium, Dauer und Nutzungsart explizit erwähnen. Jedes SOW, das einer dieser Erwähnungen entbehrt, risikiert, dass die Abtretungsklausel durch ein Gericht für ungültig erklärt wird, was die Rechte beim Dienstleister belässt.

Darüber hinaus gehört Software, die ein Arbeitnehmer im Rahmen seiner Funktionen erstellt, dem Arbeitgeber (Artikel L. 113-9 CPI). Diese Regel gilt nicht für unabhängige Dienstleister, daher die zwingende Notwendigkeit einer vertraglichen Abtretungsklausel.

DSGVO (Verordnung Nr. 2016/679) und Datenverarbeitung

Wenn der Dienstleister personenbezogene Daten im Namen des Kunden verarbeitet (z.B. Zugriff auf eine Kundendatenbank zur Entwicklung eines CRM), gilt er als Auftragsverarbeiter im Sinne von Artikel 28 der DSGVO. Das SOW muss dann eine Datenverarbeitungsvereinbarung (DPA) integrieren oder referenzieren, die folgende Punkte präzisiert: Art und Zweck der Verarbeitung, Kategorien betroffener Daten, technische und organisatorische Sicherheitsmaßnahmen, und Verpflichtungen des Dienstleisters bei Datenverletzung. Andernfalls setzen sich der Kunde und der Dienstleister CNIL-Strafen aus, die bis zu 4 % des weltweiten Jahresumsatzes erreichen können.

Handelsrecht und vertragliche Haftung

Im Fall von Nichterfüllung von Lieferungen oder Fristen ist die vertragliche Haftung des Dienstleisters gemäß den Artikeln 1231-1 und folgende des Zivilgesetzbuches (alte Artikel 1147 ff.) begründet. Haftungsbeschränkungsklauseln (Begrenzung auf X Monate Abrechnung) sind zwischen Fachleuten gültig, vorausgesetzt, dass sie den Vertrag nicht seiner Substanz berauben (Artikel 1170 des Zivilgesetzbuches).

Illustrative Anwendungsszenarien: der Web-Entwickler-SOW

Szenario 1 — Ein SaaS-Startup beauftragt ein maßgeschneidertes Abrechnungsmodul

Diese Szenarien sind illustrativ: Sie beschreiben typische Situationen und berichten über keine gemessenen Ergebnisse bei einem Kunden. Ein B2B-Scale-up, das eine HR-Management-Software entwickelt, mit rund 40 Mitarbeitenden und 500 aktiven Kunden, möchte die Entwicklung eines automatischen Abrechnungsmoduls, das in sein Hauptprodukt integriert wird, auslagern – zu einem im Voraus festgelegten Pauschalbudget und einer Entwicklungsdauer von einigen Monaten.

Ohne formalisiertes SOW zeigen sich bereits in den ersten Wochen gravierende Meinungsverschiedenheiten: Der Dienstleister betrachtet die Integration mit der Stripe-API als außerhalb des Leistungsumfangs, während der Kunde sie als implizit enthalten ansieht. Bereits in den ersten Sprints entbrennt ein Streit über die Budgetüberschreitung.

Mit einem strukturierten SOW, das eine Liefergegenstandstabelle, präzise Abnahmekriterien und eine Liste der ausdrücklich eingeschlossenen Drittintegrationen enthält, wird diese Art von Konflikt begrenzt. Die Change-Order-Klausel verpflichtet dazu, für jede Erweiterung des Leistungsumfangs einen Nachtrag zu unterzeichnen. Streitigkeiten während des Projekts und Verzögerungen bei der Inbetriebnahme sollen dadurch abnehmen. Das Ausmaß des Gewinns ist auf Ihren eigenen Projekten zu messen, vor und nach der Einführung eines strukturierten SOW.

Szenario 2 — Ein Industriekonzern sichert die Abtretung von Rechten an einer individuellen ERP-Lösung

Ein mittelgroßer Industriekonzern (rund 800 Mitarbeitende, 3 Produktionsstandorte) beauftragt eine Webentwicklungsagentur mit einem maßgeschneiderten ERP-System für die Produktionssteuerung, zu einem erheblichen Pauschalbudget und einem Auftrag, der sich über eine lange Dauer erstreckt. Am Ende des Projekts wird die Agentur von einem Konkurrenten übernommen. Der Konzern stellt daraufhin fest, dass die Klausel zum geistigen Eigentum im ursprünglichen Vertrag die Übertragung der Rechte an den Modulen, die von zwei im Projekt eingesetzten Freelancern in Unterauftrag entwickelt wurden, nicht abdeckte.

Ein gut formuliertes SOW hätte Folgendes vorgesehen: eine Übertragungsklausel, die alle Liefergegenstände abdeckt, einschließlich jener, die von Unterauftragnehmern erstellt wurden, eine Verpflichtung des Hauptdienstleisters, gleichwertige Übertragungen von seinen eigenen Unterauftragnehmern zu erwirken, sowie einen Quellcode-Escrow-Mechanismus, der bei einem Kontrollwechsel aktivierbar ist. In einer solchen Situation können die Kosten für Streitigkeiten und teilweise Neuentwicklung einen erheblichen Anteil des ursprünglichen Projektbudgets ausmachen. Das Ausmaß der Abweichung ist am tatsächlichen Umfang des Projekts zu messen.

Szenario 3 — Eine Digitalagentur standardisiert ihre SOWs zur Beschleunigung des Vertriebsprozesses

Eine Webagentur mit 15 Mitarbeitenden realisiert im Durchschnitt 25 Pauschalprojekte pro Jahr, mit variablen Budgets. Die Geschäftsführung stellt fest, dass die Verhandlung und Unterzeichnung der SOW pro Projekt auf Vertriebs- und Rechtsseite einen nicht unerheblichen Zeitaufwand binden, was in Summe ein beachtliches jährliches Stundenvolumen ergibt.

Durch die Einführung eines standardisierten SOW-Modells, ergänzt um einen Klauselgenerator, der auf jede Art von Auftrag (Vitrinenseite, Webanwendung, E-Commerce, API) zugeschnitten ist, sowie durch den Einsatz der elektronischen Signatur zur Fernfertigstellung der Dokumente, kann die Agentur den Zeitaufwand pro SOW verringern. Multipliziert mit der Anzahl der Jahresprojekte stellt diese gewonnene Zeit einen Nutzen dar, der anhand des eigenen Volumens zu beziffern ist. Die elektronische Signatur verkürzt zudem die Zeitspanne zwischen Versand und tatsächlicher Unterzeichnung, was den Projektstart beschleunigt und die Liquidität verbessert. Das Ausmaß des Gewinns ist am tatsächlichen Umfang der Agentur zu messen, vor und nach einem Pilotprojekt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem pauschalen SOW und einem Zeitaufwandsvertrag für einen Webentwickler?

Bei einem Zeitaufwandsvertrag berechnet der Auftragnehmer eine bestimmte Anzahl von Stunden oder Tagen, ohne sich auf ein genaues Ergebnis zu verpflichten. Bei einer Pauschalvergütung verpflichtet sich der Auftragnehmer, einen definierten Leistungsumfang zu einem festgelegten Preis zu erbringen, unabhängig von den tatsächlich aufgewendeten Stunden. Ein pauschales SOW muss daher die Liefergegenstände und Abnahmekriteria mit großer Präzision beschreiben, da jede Unklarheit über den Umfang zu Meinungsverschiedenheiten darüber führen kann, was in dem vereinbarten Preis enthalten war.

Was geschieht, wenn der Auftraggeber einen Liefergegenstand nicht innerhalb der im SOW vorgesehenen Abnahmefrist abnimmt?

Die meisten SOW sehen eine sogenannte „Zustimmung durch Schweigen"-Klausel vor: Wenn der Auftraggeber innerhalb der festgesetzten Frist (häufig zwischen 5 und 15 Arbeitstagen) keinen schriftlichen Einwand vorbringt, gilt der Liefergegenstand automatisch als angenommen. Diese Regelung schützt den Auftragnehmer vor sich endlos hinziehenden Abnahmeprozessen und ermöglicht es ihm, die Zahlung des entsprechenden Meilensteins auszulösen, ohne auf eine ausdrückliche Bestätigung zu warten.

Wem gehört der im Rahmen eines Pauschalauftrags entwickelte Quellcode?

Nach französischem Recht ist der Urheber eines Werkes grundsätzlich dessen Eigentümer, auch wenn es vom Auftraggeber in Auftrag gegeben wurde. Damit der Auftraggeber die Rechte am Code erwirbt, muss das SOW eine ausdrückliche Klausel zur Abtretung der Immaterialgüterrechte enthalten, in der der Umfang der Abtretung (Nutzung, Änderung, Unterlizenzierung), das Gebiet und die Dauer festgelegt sind. Ohne diese Klausel behält der Auftragnehmer die Urheber- und Verwertungsrechte am Code, auch nach vollständiger Bezahlung des Auftrags.

Hat ein elektronisch unterzeichnetes Abnahmeprotokoll denselben Rechtswert wie eine handschriftliche Unterschrift?

Ja, sofern die verwendete Lösung der europäischen eIDAS-Verordnung entspricht. Eine fortgeschrittene oder qualifizierte elektronische Signatur wird in allen Mitgliedstaaten der Europäischen Union, einschließlich Frankreich, rechtlich als äquivalent zur handschriftlichen Unterschrift anerkannt. Sie stellt einen zulässigen Beweis dar, um vor Handelsgerichten zu attestieren, dass ein Liefergegenstand an einem bestimmten Zeitpunkt durch eine identifizierte Person förmlich angenommen wurde.

Kann man den Leistungsumfang eines pauschalen SOW während eines Auftrags ändern?

Ja, aber nur durch eine von beiden Parteien unterzeichnete schriftliche Nachtrag. Eine Anfrage zur Umfangsänderung – etwa Hinzufügen von Funktionalitäten, technologische Änderungen oder Fristverlängerung – kann nicht auf Basis eines einfachen E-Mail-Austauschs oder eines mündlichen Gesprächs berücksichtigt werden. Der Nachtrag muss die Auswirkungen auf den Preis, den Zeitplan und die Abnahmekriteria angeben. Dieses formale Verfahren schützt sowohl den Auftragnehmer vor „Scope Creep" als auch den Auftraggeber vor unerwarteten Kostenüberschreitungen.

Schlussfolgerung

Ein vollständiges SOW für einen Web-Entwickler für eine Pauschalvergütungsmission zu verfassen ist keine verwaltungstechnische Formalität: Es ist das Gründungsdokument der vertraglichen Beziehung, das Streitigkeiten über Leistungen verhindert, die effektive Abtretung des Quellcodes garantiert und beide Parteien im Streitfall schützt. Durch Strukturierung Ihres SOW um fünf Säulen – Identifizierung der Parteien, Umfang der Leistungen, objektive Akzeptanzkriterien, jalonierte Finanzierungsbedingungen und detaillierte IP-Klauseln – geben Sie Ihrem Projekt die besten Chancen für einen reibungslosen Ablauf.

Certyneo begleitet Sie in jedem Schritt: von der Generierung des Entwurfs mit unserem KI-gestützten Vertragsassistent bis zur eIDAS-konformen elektronischen Signatur auf unserer Plattform, einschließlich der sicheren Archivierung Ihrer unterzeichneten Dokumente. Entdecken Sie unsere Tarife auf der Certyneo-Preisseite und beginnen Sie noch heute, Ihre Missionen zu sichern.