Kostenloser Word-Download • Online bearbeiten • Mit Drive speichern und teilen • Als PDF exportieren
Ein Software-Entwicklungs- und Lizenzvertrag regelt die Zusammenarbeit zwischen einem Softwareentwickler oder IT-Dienstleister und einem Auftraggeber bei der Entwicklung von maßgeschneiderter Software. Das Dokument definiert präzise die zu entwickelnden Funktionen (funktionale Spezifikationen), den Entwicklungsprozess (detaillierte Spezifikationen), Abnahmetest-Kriterien, Termine und Gebühren. Die Vorlage liegt als bearbeitbare Word-Datei vor, kann mit individuellen Daten und Anhängen gefüllt und als PDF exportiert werden. Sie ist für deutschsprachige Unternehmen in Deutschland, Österreich und der Schweiz geeignet und folgt dem Werkvertragsrecht des Bürgerlichen Gesetzbuchs (BGB).
Ohne einen klaren schriftlichen Vertrag entstehen häufig Meinungsverschiedenheiten: Der Kunde meint, eine bestimmte Funktion gehöre zum Leistungsumfang; der Entwickler sieht dies anders. Die Abnahme verzögert sich unbegrenzt, Gebühren werden strittig, Änderungswünsche führen zu Konflikten über Zusatzkosten. Ein Software-Entwicklungs- und Lizenzvertrag schafft Klarheit für alle Parteien: welche Spezifikationen maßgeblich sind, wie Tests ablaufen, wann die Software abgenommen ist und wann Gebühren fällig werden. Dies schützt sowohl den Entwickler (vor unbegrenzten Überarbeitungen und Zahlungsrisiken) als auch den Kunden (vor versteckten Kosten und nicht erfüllter Funktionalität). Der Vertrag ist auch eine Voraussetzung für professionelle Projektverwaltung und reduziert rechtliche Risiken erheblich.
| Wenn Ihre Situation ist… | Diese Vorlage verwenden |
|---|---|
| Gesamtlösung mit Spezifikationen, Entwicklung, Tests und Lizenzgebühren | Vollständiger Entwicklungs- und Lizenzvertrag |
| Wenn die Grundentwicklung bereits erfolgt ist, nur Lizenzierung festlegen | Nur Lizenzvertrag (ohne Entwicklung) |
| Projekte mit Sprint-basiertem Ansatz und regelmäßiger Kundenfeedback | Agile Entwicklungsvertrag (iterativ) |
| Vertrieb von entwickelter Software unter eigenem Branding des Kunden | White-Label-Softwarevereinbarung |
| Erwerbung von Wartungs-, Bug-Fix- und technischem Support nach Abnahme | Wartungs- und Support-Ergänzungsvertrag |
| Festlegung von System-Anforderungen, Tests auf Kundeninfrastruktur | Hardwareanforderungs- und Installationsvertrag |
Warum es wichtig ist: Der Entwickler und der Kunde interpretieren die Anforderungen unterschiedlich, was zu falscher Software führt und Streitigkeiten auslöst.
Fix: Nutzen Sie konkrete, messbare Kriterien; lassen Sie den Kunden die funktionalen Spezifikationen vor Entwicklung schriftlich genehmigen.
Warum es wichtig ist: Der Entwickler wartet unbegrenzt auf Feedback, oder der Kunde blockiert absichtlich, ohne Konsequenzen.
Fix: Definieren Sie klare Fristen (z. B. 10 Werktage); legen Sie fest, dass Stillschweigen als Annahme gilt, um Verzögerungen zu vermeiden.
Warum es wichtig ist: Es ist unklar, wann die Software 'fertig' ist, und der Kunde kann beliebig lange weitere Anpassungen fordern.
Fix: Vereinbaren Sie objektive Test-Kriterien (z. B. alle Funktionen müssen [X] Test-Cases bestehen) schriftlich im Vertrag.
Warum es wichtig ist: Unerwartete Kosten entstehen nach Vertragsunterzeichnung; Streitigkeiten über Zahlungspflicht.
Fix: Erstellen Sie in Anhang B eine detaillierte Gebührenübersicht mit Entwicklungsgebühr, Lizenzgebühr, Supportgebühren und Erstattungsregelungen.
Warum es wichtig ist: Der Kunde fordert zusätzliche Funktionen, der Entwickler muss ohne zusätzliche Bezahlung liefern.
Fix: Definieren Sie, dass Änderungen außerhalb der genehmigten Spezifikationen nur nach schriftlicher Vereinbarung und Zusatzzahlung erfolgen.
Warum es wichtig ist: Nach Lieferung funktioniert die Software auf der Kundeninfrastruktur nicht; niemand ist verantwortlich.
Fix: Spezifizieren Sie die exakten Hardware-Anforderungen und führen Sie einen Installationstest auf Kundeninfrastruktur durch.
In einfacher Sprache: Festlegung des Vertragsdatums, Identifizierung der Vertragsparteien (Unternehmen und Kunde) und deren rechtlicher Status.
Dieser Software-Entwicklungs- und Lizenzvertrag (die 'Vereinbarung') ist wirksam zum [DATUM] ZWISCHEN: [NAME IHRES UNTERNEHMENS] (das 'Unternehmen'), ein Unternehmen, gegründet und bestehend unter den Gesetzen von [BUNDESLAND], dessen Hauptniederlassung sich in [ADRESSE] befindet UND: [NAME DES KUNDENUNTERNEHMENS] (der 'Kunde')...
Häufiger Fehler: Unvollständige oder fehlerhafte Angaben zu den Parteien führen später zu Unklarheiten bei der Vertragsauslegung oder Klagebefugnis.
In einfacher Sprache: Begründung des Vertragszwecks (der Kunde beauftragt Entwicklung, das Unternehmen erklärt sich zur Durchführung bereit) und gegenseitige Verpflichtungen.
Das Unternehmen ist im Bereich der IT-Beratung und Software-Entwicklung tätig; der Kunde hat das Unternehmen gebeten, kundenspezifische Software mit [FUNKTIONEN BESCHREIBEN] zu entwickeln und zu lizenzieren...
Häufiger Fehler: Zu vage Beschreibung des Leistungsumfangs führt zu späteren Meinungsverschiedenheiten über Umfang und Qualität der Software.
In einfacher Sprache: Klarstellung von Schlüsselbegriffen wie 'Vereinbarung', 'Werktag', 'Gebühren', 'Funktionale Spezifikationen', 'Detaillierte Spezifikationen' und 'Lizenzierte Software'.
'Datum der Abnahme' bezeichnet das Datum, an dem die Software alle Abnahmetests in Übereinstimmung mit [ANGEBEN] bestanden hat oder vom Kunden gemäß [ABSCHNITT] abgenommen wurde.
Häufiger Fehler: Fehlende oder mehrdeutige Definitionen führen zu Auslegungsstreitigkeiten beim Vertragsmanagement.
In einfacher Sprache: Das Unternehmen erstellt detaillierte Design-Spezifikationen auf Basis der funktionalen Anforderungen, der Kunde genehmigt diese innerhalb einer Frist oder sie gelten als genehmigt.
Am Beginndatum wird das Unternehmen mit der Erstellung detaillierter Spezifikationen und Abnahmetest-Kriterien beginnen. Die detaillierten Spezifikationen werden dem Kunden innerhalb von [NUMMER] Werktagen zur Genehmigung vorgelegt. Der Kunde hat [NUMMER] Werktage Zeit, diese zu genehmigen, teilweise abzulehnen oder Änderungen zu fordern.
Häufiger Fehler: Keine Festlegung von Genehmigungsfristen führt zu unbegrenzten Verzögerungen und unklaren Verantwortlichkeiten.
In einfacher Sprache: Regelung des iterativen Prozesses bei Ablehnung oder Änderungswünschen: Unternehmen überarbeitet, Kunde genehmigt erneut, bis Einigung oder Abnahmetest-Kriterien vereinbart sind.
Wenn die Spezifikationen abgelehnt werden, hat das Unternehmen einen weiteren Zeitraum von [NUMMER] Werktagen, geänderte Spezifikationen vorzulegen. Der Kunde hat wiederum [NUMMER] Werktage zur Genehmigung oder Ablehnung. Stillschweigendes Akzeptieren gilt als Annahme.
Häufiger Fehler: Unbegrenzte Änderungsrunden ohne Kostenregelung führen zu Schwebezuständen und finanziellen Konflikten.
In einfacher Sprache: Sobald detaillierte Spezifikationen genehmigt sind, werden sie Teil der Vereinbarung und maßgeblich für die Softwareentwicklung; bei Konflikten haben sie Vorrang.
Wenn der Kunde die detaillierten Spezifikationen akzeptiert oder sie als akzeptiert erachtet werden, gelten die detaillierten Spezifikationen als in die funktionalen Spezifikationen integriert und bilden einen Teil derselben. Bei Konflikt haben die detaillierten Spezifikationen Vorrang.
Häufiger Fehler: Unklar bleibt oft, welches Dokument (funktional vs. detailliert) bei Widerspruch maßgeblich ist, was zu unterschiedlichen Entwicklungsversionen führt.
In einfacher Sprache: Lehnt der Kunde nur die Abnahmetest-Kriterien (nicht die gesamten Spezifikationen) ab, trägt der Kunde die Kosten für die Entwicklung von alternativen Test-Kriterien.
Wenn der Kunde jenen Teil der geänderten detaillierten Spezifikationen ablehnt, die mit den Abnahmetest-Kriterien zu tun haben, ist der Kunde allein verantwortlich, auf eigene Kosten alternative Abnahmetest-Kriterien zu entwickeln.
Häufiger Fehler: Keine Regelung der Kostenverantwortung führt zu Uneinigkeit, wer für Test-Überarbeitungen zahlt.
In einfacher Sprache: Das Unternehmen erhält Lizenzgebühren und Erstattung aller Auslagen (Reisen, Telefon, Kuriere); hinzu kommen anwendbare Steuern. Die exakten Beträge sind in Anhang 'B' festgehalten.
'Gebühren' bezeichnet die Lizenzgebühr, wie in Anhang 'B' aufgeführt, gemeinsam mit Erstattung aller Auslagen des Unternehmens (Reise, Unterkunft, Telefon, Kurier, Fax) plus anwendbare Bundes-, Landes- und Gemeindesteuern.
Häufiger Fehler: Vage Gebührenegelung führt zu Streitigkeiten über erwartete vs. tatsächliche Kosten.
In einfacher Sprache: Definition der Hardware-Anforderungen und des Zeitplans für Implementierung, Konfiguration und Inbetriebnahme der Software auf der Kundeninfrastruktur.
'Hardware' bezeichnet die zentrale Recheneinheit und das Betriebssystem, wie in Anhang [ANGEBEN] beschrieben, auf dem die Software vom Kunden betrieben wird. Der Terminplan ist in Anhang [ANGEBEN] beigefügt.
Häufiger Fehler: Fehlende Hardware-Spezifikationen führen zu Inkompatibilität oder Leistungsproblemen nach Lieferung.
Füllen Sie die vollständigen Namen, rechtlichen Formen (GmbH, AG, Einzelunternehmer) und Adressen beider Parteien aus. Geben Sie das Beginndatum des Vertrags an.
💡 Stellen Sie sicher, dass die Angaben mit den Handelsregistereinträgen oder der Firmenregistrierung übereinstimmen.
Beschreiben Sie detailliert, welche Funktionen, Features und Fähigkeiten die Software haben soll. Nutzen Sie Anhang A oder ein separates Dokument für die Auflistung.
💡 Seien Sie so konkret wie möglich — nutzen Sie User-Stories oder Use-Cases, um Mehrdeutigkeiten zu vermeiden.
Spezifizieren Sie, auf welcher Hardware und welchem Betriebssystem die Software ausgeführt werden soll (z. B. Windows Server 2022, Linux, Cloud-Infrastruktur).
💡 Klären Sie auch Anforderungen wie Speicher, Processor, Netzwerk und Datenbank ab, um später keine Kompatibilitätsprobleme zu haben.
Legen Sie Meilensteine, Fristen für Entwicklungsphasen, Tests und Inbetriebnahme fest. Nutzen Sie Anhang C oder ein Projektplan-Dokument.
💡 Bauen Sie Buffer für unvorhergesehene Probleme ein; zu enge Fristen führen zu Qualitätsmängeln und Streitigkeiten.
Erstellen Sie eine Liste oder einen Standard, wie die Software getestet wird und wann sie als erfolgreich angenommen gilt (z. B. Anzahl erfolgreicher Test-Cases, Performance-Schwellenwerte).
💡 Beziehen Sie den Kunden in die Entwicklung dieser Kriterien ein, um späteren Konflikte über Abnahme zu vermeiden.
Beschreiben Sie die Lizenzgebühr (Pauschalbetrag, Staffel, Abschlagszahlungen), Erstattungsregelungen (Reise, Material) und Steuern. Legen Sie auch Zahlungsfristen und Zahlungsweisen fest.
💡 Unterscheiden Sie zwischen Entwicklungskosten (einmalig) und Lizenzgebühren (wiederkehrend oder lebenslang, je nach Modell).
Setzen Sie realistische Fristen für die Genehmigung von Spezifikationen durch den Kunden (z. B. 10, 15 oder 20 Werktage, je nach Komplexität).
💡 Kürzere Fristen für einfache Änderungen, längere für umfangreiche Überarbeitungen — besprechen Sie dies mit dem Kunden ab.
Füllen Sie alle Platzhalter in der Vorlage aus, ergänzen Sie Anhänge A (Funktionale Spezifikationen), B (Gebühren) und C (Terminplan). Lassen Sie beide Parteien unterzeichnen.
💡 Eine digitale oder handschriftliche Unterschrift jedes Vertreters beider Parteien ist erforderlich, um den Vertrag rechtsverbindlich zu machen.
Funktionale Spezifikationen beschreiben, WAS die Software tun soll (z. B. 'Das System soll Kundenaufträge verwalten und automatisch Rechnungen generieren'). Detaillierte Spezifikationen beschreiben, WIE es implementiert wird (z. B. Datenbankstruktur, API-Design, Benutzeroberflächen-Layout). Der Vertrag regelt, dass der Entwickler zunächst detaillierte Spezifikationen auf Basis der funktionalen Vorgaben erstellt und der Kunde diese genehmigt, bevor die Entwicklung beginnt. So wird vermieden, dass der Entwickler eine technisch falsche Lösung liefert.
Der Vertrag regelt einen Genehmigungsprozess mit Fristen (z. B. 10 Werktage pro Runde). Wenn der Kunde nach mehreren Überarbeitungen nicht zustimmt, sollte eine Klausel festhalten, dass der Entwickler nach [X] Ablehnungsrunden die Kosten für weitere Überarbeitungen dem Kunden in Rechnung stellen kann, oder dass der Vertrag gekündigt wird. Dies ist im Standard-Template nicht enthalten und sollte ggf. hinzugefügt werden, um unbegrenzte Überarbeitungsschleifen zu vermeiden.
Dies sollte vorab geklärt sein. Der Vertrag spezifiziert die Hardware-Anforderungen (Anhang A oder B). Wenn die tatsächliche Hardware des Kunden nicht ausreicht, ist der Kunde verantwortlich, diese zu aktualisieren — die Kosten trägt der Kunde. Dies sollte explizit in der Hardware-Anforderungs-Klausel festgehalten werden.
Ja, aber nur gegen Zusatzbezahlung. Der Vertrag sollte klar regeln, dass die in Anhang A genehmigten Spezifikationen die Leistung definieren. Wünsche nach Abnahme sind 'Änderungen' oder 'Erweiterungen' und erfordern einen Zusatzvertrag oder eine Amendment-Klausel mit neuer Gebührenabsprache. Ohne diese Regelung könnte der Kunde beliebig viele kostenlose Anpassungen fordern.
Das Datum der Abnahme ist der Zeitpunkt, an dem die Software alle vereinbarten Abnahmetest-Kriterien erfolgreich bestanden hat. Dies kann z. B. sein: 'Alle 150 vordefinierten Test-Cases bestehen', 'Performance-Tests zeigen Antwortzeiten unter 2 Sekunden', 'Alle Dateneingabe-Formulare funktionieren fehlerfrei'. Der Vertrag sollte festhalten, wer die Tests durchführt (meist der Kunde oder ein unabhängiger Tester) und wer das Ergebnis dokumentiert. Erst nach bestandenen Tests und schriftlicher Bestätigung beginnt die Lizenzgebührenfälligkeit oder erste Abschlagszahlung.
Der Standard-Template regelt hauptsächlich die Entwicklung und Abnahme. Support, Wartung und Bug-Fixes sind in der Regel nicht enthalten. Dies sollte in einer separaten 'Support & Maintenance'-Klausel oder in einem eigenen Vertrag festgehalten werden. Typisch ist eine erste kostenlose Wartungsphase (z. B. 30–90 Tage) nach Abnahme, danach kostenpflichtiger Support.
Der Vertrag sollte eine 'Terminplan'-Klausel enthalten, die Meilensteine und Fristen festlegt (in Anhang C). Für Verzögerungen sollte eine Regelung gelten, z. B.: 'Bei Überschreitung um mehr als [X] Arbeitstage kann der Kunde Schadensersatz fordern oder den Vertrag kündigen' oder 'eine Vertragsstrafe von [Y]% pro Tag Verzögerung'. Der Standard-Template hat dies nicht explizit enthalten; es sollte als Zusatzklausel hinzugefügt werden.
Dies ist im Standard-Template nicht explizit geregelt und muss verhandelt werden. Typisch sind zwei Modelle: (1) Der Entwickler behält das Copyright, der Kunde erhält eine Lizenz zur Nutzung; (2) Der Kunde erhält vollständiges Eigentum/Copyright an der Software. Dies sollte klar in einer separaten 'Intellectual Property' oder 'Ownership'-Klausel festgehalten werden, um später Streitigkeiten zu vermeiden.
Ein allgemeiner Werkvertrag regelt die Leistung und Bezahlung, ohne spezifische technische Details. Ein Software-Entwicklungsvertrag ist spezialisiert auf IT-Projekte mit detaillierten Spezifikationen, Abnahmetest-Kriterien und Lizenzierungsmodellen. Nutzen Sie die spezialisierte Software-Vorlage, wenn Funktionalität und Tests zentral sind; einen einfachen Werkvertrag, wenn nur die Fertigstellung zählt.
Ein SLA regelt Support, Verfügbarkeit und Reaktionszeiten NACH dem Go-Live (z. B. '99,9% Verfügbarkeit', '24-Stunden-Support'). Ein Entwicklungsvertrag regelt die Entwicklung, Spezifikationen und Abnahme VOR dem Go-Live. Beide sind sinnvoll: Nutzen Sie diesen Vertrag für Entwicklung + Abnahme, danach ein SLA für laufenden Support.
Ein Standard-Lizenzvertrag (z. B. für Microsoft Office, SAP) regelt die Nutzung von bestehender Software. Ein Entwicklungsvertrag kombiniert Entwicklung MIT Lizenzierung für Custom-Software. Nutzen Sie diesen Vertrag, wenn Software maßgeschneidert ist; einen Standard-Lizenzvertrag, wenn Sie Off-the-Shelf-Produkte kaufen.
Ein NDA schützt vertrauliche Informationen und ist oft ein ZUSATZ zu einem Entwicklungsvertrag (z. B. zur Sicherheit von Geschäftslogik, Quellcode, Kundendaten). Ein Entwicklungsvertrag regelt Leistung und Bezahlung. Nutzen Sie BEIDE: den Entwicklungsvertrag als Hauptdokument, ein NDA als Zusatz, falls Vertraulichkeit zentral ist.
Dienstleister und Entwickler regeln Leistung, Spezifikationen und Lizenzgebühren mit Kunden rechtsverbindlich.
Regulierte Finanzunternehmen benötigen detaillierte Verträge für Custom-Software mit hohen Sicherheitsanforderungen und Compliance-Dokumentation.
ERP-, MES- oder Steuerungssoftware für Produktionsprozesse erfordern präzise Spezifikationen und Abnahmetest-Kriterien.
Regulierte Software (z. B. Praxissoftware, Patientenverwaltung) braucht nachweisbare Qualitätskontrolle und Dokumentation gemäß Medical Devices Directive.
Online-Shop-Systeme, Lagerbestands-Software und Payment-Integrationen benötigen genaue Funktionsspezifikationen und schnelle Abnahme-Zyklen.
Tracking-, Lagerverwaltungs- und Routenplanungs-Software mit exakten Schnittstellen-Anforderungen und Tests unter Last.
Der Vertrag folgt deutschem BGB (Bürgerliches Gesetzbuch), insbesondere § 631 ff. BGB (Werkvertrag). Abnahmetest-Bestimmungen entsprechen der deutschen Praxis für IT-Projekte. Für regulierte Branchen (z. B. Finanzinstitute) sollte eine Anwaltsprüfung erfolgen.
In Österreich gelten ähnliche Werkvertrags-Regelungen (ABGB). Der Vertrag ist anpassbar; beachten Sie jedoch österreichische Besonderheiten (z. B. Umsatzsteuer-Identifikationsnummer für inländische Kunden). Lokale Anwaltsprüfung empfohlen.
| Weg | Am besten für | Kosten | Zeit |
|---|---|---|---|
| Vorlage verwenden | Einfache, standardisierte Projekte (z. B. Website-Entwicklung, kleine App) mit klaren Anforderungen und etabliertem Entwickler-Kunde-Verhältnis. | 0–100 EUR (nur Vorlage) | 2–4 Stunden zum Ausfüllen |
| Vorlage + Rechtsprüfung | Mittlere Projekte (5.000–50.000 EUR) mit komplexeren Funktionen oder kritischen Anforderungen; Anwalt überprüft Klauseln und lokale Rechtssprechung. | 500–1.500 EUR (Anwaltshonorar für Review) | 1–2 Wochen (Anwalt-Review, Überarbeitungen) |
| Maßgeschneidert | Große, kritische Projekte (über 50.000 EUR), regulierte Industrie (Banking, Medizintechnik), M&A-Transaktionen oder hohe IP-/Sicherheitsanforderungen. | 2.000–5.000 EUR+ (individueller Entwurf und Verhandlung) | 2–4 Wochen (individueller Entwurf + mehrfache Überarbeitungen) |
Dieses Dokument ist eine von 3,000+ Geschäfts- und Rechtsvorlagen, die in Business in a Box enthalten sind.
Greifen Sie auf über 3,000+ geschäftliche und rechtliche Vorlagen für jede Aufgabe, jedes Projekt oder jede Initiative zu.
Passen Sie Ihre vorgefertigte Geschäftsdokumentvorlage an und speichern Sie sie in der Cloud.
Teilen Sie Ihre Dateien und Ordner mit Ihrem Team. Erstellen Sie einen Raum für nahtlose Zusammenarbeit.
"Fantastischer Wert! Ich kann nicht mehr darauf verzichten. Es ist Gold wert und hat sich schon vielfach bezahlt gemacht."
"Ich benutze Business in a Box seit 4 Jahren. Es ist die beste Quelle für Vorlagen, die ich je gesehen habe. Ich kann es jedem nur empfehlen."
"Es war so oft ein Lebensretter, dass ich es gar nicht mehr zählen kann. Business in a Box hat mir so viel Zeit gespart und wie Sie wissen, Zeit ist Geld."
Hören Sie auf, Dokumente herunterzuladen. Beginnen Sie, mit Klarheit zu arbeiten. Business in a Box bietet Ihnen das Business Operating System, das von über 250.000 Unternehmen weltweit genutzt wird, um ihr Geschäft zu strukturieren, zu führen und auszubauen.
Kostenlos starten · Keine Kreditkarte erforderlich
