Ihr erstes Projekt mit einem Kunden lief unter einem zweiseitigen Angebot problemlos. Jetzt ist das zweite Projekt größer, der Kunde schickt seine eigene Leistungsbeschreibung, die auf seine Standard-Lieferantenbedingungen verweist, und irgendwo mitten im Projekt kommt ein Deliverable zu spät und eine Rechnung bleibt unbezahlt. Sie zeigen auf Ihr Angebot. Er zeigt auf seine Lieferantenbedingungen. Wessen Papier regelt die Sache eigentlich? Wenn Sie das nicht in einem Satz beantworten können, sind Ihre Verträge der Beziehung längst hinterhergelaufen — und die Lösung ist kein längeres Angebot, sondern eine Zwei-Dokument-Struktur: ein Master Services Agreement plus eine Leistungsbeschreibung für jedes Engagement.
Dieser Leitfaden erklärt, was in jedes Dokument gehört, warum die Aufteilung Sie davor bewahrt, dieselben Klauseln bei jedem Projekt neu zu verhandeln, und welche Fehler die ganze Struktur zunichtemachen. Eine übliche Klarstellung vorab: Dies sind allgemeine Informationen darüber, wie Dienstleistungsverträge funktionieren, keine Rechtsberatung für Ihre spezifische Situation.
Die zwei Dokumente auf einen Blick
Ein Master Services Agreement (MSA) enthält alle Bedingungen, die über alle Engagements mit demselben Kunden hinweg konstant bleiben: wie Sie bezahlt werden, wem die Arbeit gehört, wer wofür haftet, wie beide Seiten aussteigen können. Eine Leistungsbeschreibung (Statement of Work, SOW) beschreibt genau ein Engagement: was Sie bauen oder liefern werden, bis wann, für wie viel und wie der Kunde es abnimmt.
| Master Services Agreement | Statement of Work | |
|---|---|---|
| Beantwortet | Wie arbeiten wir zusammen? | Was machst du diesmal? |
| Lebensdauer | Monate bis Jahre, über viele Projekte | Ein Projekt, dann archiviert |
| Neu verhandelt | Selten, wenn überhaupt | Neu für jedes Engagement |
| Typische Inhalte | Zahlungsmodalitäten, Vertraulichkeit, IP-Rahmen, Gewährleistungen, Freistellung, Haftungsbeschränkungen, Laufzeit und Kündigung | Umfang, Deliverables, Meilensteine, Vergütung, Abnahmekriterien, Änderungskontrolle |
| Unterzeichnet von | Beiden Parteien, einmalig | Beiden Parteien, pro Projekt |
Stellen Sie sich das MSA als Betriebssystem vor und jede SOW als App, die darauf läuft. Wenn das dritte, vierte und fünfte Projekt kommt, verhandeln Sie nur noch die SOW — die Haftungsbeschränkung, die IP-Übertragung und die Zahlungsbedingungen, die Sie bereits ausgehandelt haben, bleiben bestehen.
Was in den Mastervertrag gehört
Alles im MSA sollte für jedes Projekt gelten, das Sie jemals für diesen Kunden durchführen werden. Wenn eine Bedingung von einem Engagement zum nächsten wechseln würde, gehört sie stattdessen in die SOW.
Umfang der Beziehung. Paradoxerweise enthält das MSA normalerweise gar keinen Projektumfang — nur einen Rahmensatz, der festhält, dass der Kunde Sie für Dienstleistungen beauftragen kann, die in künftigen Leistungsbeschreibungen beschrieben werden. Widerstehen Sie der Versuchung, Projektdetails hier einzufügen. In dem Moment, in dem Projektspezifika in den Mastervertrag einsickern, müssen Sie den Mastervertrag jedes Mal ändern, wenn sich die Arbeit ändert — genau die Mühsal, die die Struktur beseitigen soll.
Zahlungsmodalitäten. Nicht der Preis eines Projekts, sondern die Maschinerie des Bezahltwerdens: Rechnungen fällig innerhalb wie vieler Tage, was als verspätete Zahlung gilt, die Verzugsgebühr oder der Zinssatz, wer Ausgaben trägt und wie sie belegt werden, und ob Anzahlungen vor Arbeitsbeginn erforderlich sind. Legen Sie die Verzugsgebühr hier einmal fest — eine gängige Formulierung ist 1,5 Prozent pro Monat auf überfällige Salden — und jede künftige SOW erbt sie ohne neue Diskussion.
Vertraulichkeit. Eine gegenseitige Verpflichtung, die die nicht-öffentlichen Informationen beider Seiten abdeckt, wie lange sie nach Beendigung fortbesteht und die üblichen Ausnahmen für Informationen, die bereits öffentlich waren oder unabhängig entwickelt wurden. Freelancer lassen das in eigenständigen Angeboten oft weg; in einem MSA kostet es nichts und schützt beide Seiten über alle Engagements hinweg.
Rahmen für geistiges Eigentum. Das MSA legt die Eigentumsregel fest — typischerweise, dass Sie die fertigen Deliverables an den Kunden übertragen, idealerweise mit vollständiger Zahlung — plus die Ausnahme für Ihr vorbestehendes IP: die Frameworks, Vorlagen, Code-Bibliotheken und Methoden, die vor dem Engagement existierten und Ihnen gehören, dem Kunden nur lizenziert, soweit sie in den Deliverables eingebettet sind. Die SOW benennt dann, welche Deliverables jede Beauftragung umfasst. Halten Sie die Regel im Mastervertrag und das Inventar in der SOW.
Gewährleistungen und Freistellung. Eine kurze Gewährleistung, dass Sie die Dienstleistungen professionell erbringen und dass die Deliverables keine IP-Rechte Dritter verletzen, gepaart mit einer Freistellungsklausel, die jede Seite verpflichtet, die andere gegen definierte Ansprüche Dritter zu verteidigen. Diese Klauseln lesen sich wie Boilerplate, bis ein geliehener Code eines Subunternehmers oder ein nicht lizenziertes Stockfoto ein Abmahnschreiben auslöst — dann entscheiden sie, wer die Verteidigung bezahlt.
Haftungsbeschränkung. Die Klausel, die Ihre Worst-Case-Exposition begrenzt, fast immer festgelegt als die unter der betreffenden SOW in den vorangegangenen 12 Monaten gezahlten Vergütungen, plus ein gegenseitiger Verzicht auf mittelbare und Folgeschäden. Verhandeln Sie dies einmal im MSA und es deckt jedes Projekt ab. Akzeptieren Sie hier eine unbegrenzte Haftungsklausel, haben Sie sie auch für alle zukünftigen Arbeiten akzeptiert — dies ist also die Bedingung, um die auf Master-Ebene am härtesten gekämpft werden sollte.
Laufzeit, Kündigung und Abwicklung. Wie lange das MSA gilt, wie jede Partei es kündigen kann (üblicherweise 30 Tage schriftliche Kündigungsfrist), ob die Kündigung laufende SOWs beendet oder sie bis zur Fertigstellung weiterlaufen lässt, und was am Ende passiert: Rückgabe vertraulicher Materialien, Zahlung für bis zum Kündigungsdatum erbrachte Leistungen und etwaige Übergangshilfe. Der wertvollste einzelne Satz für Freelancer ist die Ausfallgebühr: Wenn der Kunde ein Projekt mittendrin abbricht, werden die bis zum Abbruch abgeschlossenen Arbeiten plus eine definierte Abwicklungsgebühr unabhängig davon bezahlt.
Rangfolge. Die Klausel, die das Eingangsszenario beantwortet: Wenn Dokumente sich widersprechen, welches gewinnt? Eine typische Rangfolge ordnet die SOW über das MSA für projektspezifische Bedingungen und beide über etwaiges Kleingedrucktes in Bestellungen oder Rechnungen. Ohne diese Klausel kann das Beschaffungsportal des Kunden Ihre ausgehandelten Bedingungen mit jeder Bestellung stillschweigend überschreiben.
Was in die Leistungsbeschreibung gehört
Wenn das MSA die Verfassung ist, ist die SOW die Gesetzgebung — spezifisch, datiert und verzichtbar. Jede SOW sollte für sich als vollständige Beschreibung eines Engagements stehen, während sie für alles andere auf das MSA zurückverweist. Fünf Elemente tragen fast das gesamte Gewicht.
Umfang plus die Out-of-Scope-Liste. Beschreiben Sie die Deliverables, die Meilensteine, den Zeitplan und die Verantwortlichkeiten jeder Seite — einschließlich dessen, was der Kunde Ihnen schuldet, wie Datenzugang, Feedback innerhalb von fünf Werktagen und ein einziger Entscheider. Schreiben Sie dann das Spiegelbild: eine explizite Liste dessen, was nicht enthalten ist. Zusätzliche Überarbeitungsrunden, Implementierungsunterstützung, Eilbearbeitungen, Arbeit in Tools, denen Sie nie zugestimmt haben — benennen Sie sie und erklären Sie, dass alles außerhalb des Umfangs einen schriftlichen Change Order mit zusätzlichen Gebühren erfordert. Dieser Absatz verwandelt den größten Teil von Scope Creep von einer Diskussion in eine Rechnung.
Vergütung für dieses Engagement. Der Festpreis, der Stundensatz und die Obergrenze oder der Retainer-Betrag — nur die Zahlen dieser SOW, aufbauend auf der Zahlungsmaschinerie des MSA. Binden Sie jede Zahlung an einen Meilenstein mit einem Kalenderdatum oder einem verifizierbaren Ereignis und legen Sie fest, ob die Anzahlung nicht erstattungsfähig ist und gegen die Gesamtsumme verrechnet wird. Ein Meilensteinplan leistet Doppelarbeit: Er taktet Ihren Cashflow und gibt dem Kunden einen Grund, Feedback in Bewegung zu halten, da seine Verzögerung sichtbar seine eigenen Termine verschiebt.
Abnahmekriterien. Wie der Kunde jedes Deliverable abnimmt und — entscheidend — was passiert, wenn er schweigt. Eine Deemed-Acceptance-Klausel, üblicherweise zehn Werktage ohne schriftlichen Widerspruch, hindert einen Kunden daran, die Abnahme unbegrenzt hinauszuzögern und Ihren letzten Meilenstein als Geisel zu halten. Vage SOWs ohne Abnahmekriterien sind die häufigste Quelle von Scope Creep: Wenn „fertig" undefiniert ist, ist alles noch im Umfang.
Änderungskontrolle. Ein einabsätziger Prozess: Änderungen an Umfang, Zeitplan oder Vergütung müssen schriftlich beantragt, von Ihnen bepreist und von beiden Seiten unterzeichnet werden, bevor die geänderte Arbeit beginnt. Kein unterzeichneter Change Order, keine geänderte Arbeit. Freelancer, die dies konsequent durchsetzen, berichten, dass es die meisten Creep-Diskussionen beendet, bevor sie beginnen, weil der Kunde den Preis des Umwegs sieht, bevor er sich dazu verpflichtet.
Abhängigkeiten und Schlüsselpersonen. Wenn Ihr Zeitplan von Kundenbeiträgen abhängt, legen Sie fest, dass sich der Zeitplan Tag für Tag bei Kundenverzögerungen verlängert. Wenn der Kunde Ihre Agentur wegen bestimmter Personen beauftragt, benennen Sie sie und legen Sie fest, was passiert, wenn jemand aussteigt. Beide Sätze verhindern, dass das dreiwöchige Schweigen der anderen Seite zu Ihrer verpassten Frist wird.
Meilensteine, Zahlungsbedingungen und Abnahme: Wo Geld auf Papierkram trifft
Der Meilensteinplan der SOW ist nicht nur ein Projektplan — er ist Ihre Umsatzprognose in Vertragsform, und Ihre Buchhaltung sollte ihn widerspiegeln. Wenn jeder Meilenstein einen definierten Betrag und einen Abnahmeauslöser hat, wird die Rechnungsstellung mechanisch: Meilenstein abgenommen, Rechnung versandt, Zahlungsuhr unter den Bedingungen des MSA gestartet. Wenn Meilensteine schwammig sind, wird die Rechnungsstellung jedes Mal eine Verhandlung.
Verfolgen Sie jede SOW als eigenen Einkommensstrom in Ihren Büchern. Eine vor Arbeitsbeginn erhaltene Anzahlung ist noch kein Umsatz — sie ist eine Verbindlichkeit (unearned revenue), bis Sie den Meilenstein liefern, gegen den sie verrechnet wurde. Meilensteinzahlungen lassen sich sauber datierten Rechnungen zuordnen, was Ihren Forderungsalterungsbericht zu einem Frühwarnsystem macht: Wenn die SOWs eines Kunden immer wieder überfällig werden, während andere pünktlich zahlen, liegt das Problem beim Kunden, nicht bei Ihrem Abrechnungsprozess. Und zur Steuerzeit machen Aufzeichnungen pro SOW es trivial, zu zeigen, welches Einkommen zu welchem Jahr gehört, anstatt es aus einem Jahr Bankeinzahlungen zu rekonstruieren. Die Beancount-Dokumentation zeigt, wie Plain-Text-Hauptbücher diese Art von Projektverfolgung prüfbar halten, ohne einen Monatsabschluss-Krimi.
IP-Eigentum über zwei Dokumente hinweg
Die Aufteilung der IP-Bedingungen zwischen MSA und SOW verwirrt Menschen, daher hier die Arbeitsteilung. Das MSA legt die Eigentumsregel und die Ausnahmen fest: Deliverables gehen bei vollständiger Zahlung an den Kunden über, Ihr vorbestehendes Toolkit bleibt unter Lizenz Ihr eigenes, und Sie behalten Portfoliorechte, falls verhandelt. Die SOW identifiziert die Deliverables, auf die die Regel anzuwenden ist — die Designs, Codes, Berichte oder Inhalte, die dieses Engagement produziert.
Zwei Fallen erwischen Freelancer hier. Die erste ist, sich allein auf „Work made for hire"-Formulierungen zu verlassen. Nach US-Urheberrecht deckt diese Doktrin Arbeitnehmer ab und nur enge Kategorien speziell beauftragter Werke; die meisten freiberuflichen Deliverables qualifizieren sich nicht, und Gerichte haben wiederholt entschieden, dass die Bezeichnung von etwas als Work for Hire in einem Vertrag es nicht dazu macht. Was tatsächlich Eigentum überträgt, ist die schriftliche Übertragungsklausel in Ihrem MSA — behalten Sie sie und behandeln Sie Work-for-Hire-Formulierungen als Backup statt als Mechanismus.
Die zweite Falle ist die Subunternehmer-Lücke. Wenn irgendjemand anderes die Arbeit berührt, muss Ihr Subunternehmervertrag dessen Arbeitsergebnis die Kette hinauf an Sie übertragen. Andernfalls versprechen Sie dem Kunden Eigentum an Deliverables, die Ihnen rechtlich nicht gehören, und die IP-Gewährleistung des MSA wird zu einem Verstoß, der auf ein Entdeckungsdatum wartet.
Haftungsbeschränkung: Einmal deckeln, jedes Projekt abdecken
Haftungsbedingungen belohnen die MSA-Struktur mehr als jede andere Klausel, weil sie am schwersten zu verhandeln und am gefährlichsten falsch zu machen sind. Setzen Sie auf Master-Ebene drei Dinge durch.
Erstens eine Deckelung, die an das geknüpft ist, was der Kunde tatsächlich gezahlt hat — typischerweise die unter der betroffenen SOW in den 12 Monaten vor dem Anspruch gezahlten Vergütungen. Widerstehen Sie Deckelungen, die an alle Vergütungen unter dem MSA geknüpft sind, wenn Sie hochvolumige Arbeit für einen Kunden leisten, da diese Zahl jedes Jahr zu einem größeren Ziel anwächst. Zweitens ein gegenseitiger Ausschluss mittelbarer, zufälliger und Folgeschäden: Ohne ihn kann ein verspätetes Deliverable Sie theoretisch für den entgangenen Launch-Umsatz des Kunden haftbar machen. Drittens enge Ausnahmen, in denen die Deckelung nicht gilt — üblicherweise Vertraulichkeitsverstöße, IP-Verletzungen und vorsätzliches Fehlverhalten. Halten Sie diese Liste kurz. Jede Ausnahme ist ein Loch im Schutz, und ein Kundenmarkup, das „oder jede Verletzung dieses Vertrags" zu den Ausnahmen hinzufügt, hat stillschweigend Ihre Deckelung komplett gestrichen.
Solo-Freelancer nehmen manchmal an, diese Klauseln seien Enterprise-Theater. Sind sie nicht. Eine Haftungsdeckelung, die auf gezahlte Vergütungen gesetzt ist, bedeutet, dass Ihr Worst Case bei einem 15.000-Dollar-Engagement etwa 15.000 Dollar beträgt — schmerzhaft, überlebbar. Ohne Deckelung ist Ihr Worst Case das, was ein Richter für die Schäden des Kunden hält. Unterschreiben Sie die Deckelung einmal, und jede SOW, die Sie jemals unter diesem MSA unterschreiben, trägt sie mit.
Häufige Fehler, die die ganze Struktur zunichtemachen
Das Zwei-Dokument-System funktioniert nur, wenn die Dokumente tatsächlich verbunden sind. Dies sind die Fehler, die am häufigsten auftreten.
Eine SOW unterschreiben, die nie auf das MSA verweist. Eine SOW, die frei vom Mastervertrag schwebt, ist nur ein weiteres eigenständiges Angebot — keiner Ihrer ausgehandelten Schutzmaßnahmen haften ihr an. Jede SOW sollte damit beginnen, das MSA nach Datum und Titel einzubeziehen. Ein Satz genügt.
Kleingedrucktes von Bestellungen gewinnen lassen. Viele Kunden leiten jedes Engagement durch die Beschaffung, und Bestellungen kommen mit auf der Rückseite gedruckten Bedingungen, die Ihrem MSA bei Zahlungszeitpunkt, Haftung und IP widersprechen. Die Rangfolgeklausel Ihres MSA sollte die Bestellung an letzter Stelle einordnen, und Sie sollten niemals eine Bestellung unterzeichnen, deren Vorderseite der SOW widerspricht, ohne es zu kennzeichnen. Die Bestellung ist ein Zahlungsinstrument, keine Neuverhandlung.
Handschlag-Change-Orders. Jeder außerhalb des Umfangs geleistete Gefallen auf ein mündliches „wir klären das später" trainiert den Kunden darauf, Ihre Änderungskontrollklausel zu umgehen — und lässt Sie ohne unterzeichneten Nachweis zurück, wenn die Rechnung kommt. Bepreisen Sie die Änderung, holen Sie die Unterschrift, dann machen Sie die Arbeit. Keine Unterschrift, keine Arbeit.
Immerwährende Verlängerung ohne Tarifüberprüfung. MSAs, die Jahr für Jahr automatisch verlängert werden, sind praktisch, bis Sie merken, dass Ihre SOW-Sätze seit 2023 eingefroren sind, während Ihre Kosten um 20 Prozent gestiegen sind. Koppeln Sie die automatische Verlängerung mit einem jährlichen Tarifüberprüfungsfenster, damit Ihre Preise sich mit dem Markt bewegen können.
Ein Großunternehmens-MSA als Solo-Freelancer kopieren. Enterprise-MSAs setzen Versicherungen, Sicherheitszertifizierungen und Rechtsabteilungen voraus, die Sie nicht haben. Eines wortgetreu zu unterschreiben, kann Sie zu jährlichen SOC-2-Audits, 99,9-Prozent-Uptime-SLAs oder siebenstelliger Versicherungsdeckung verpflichten. Lesen Sie jede Verpflichtung als ein Versprechen, das Sie persönlich einhalten müssen, und streichen oder verengen Sie diejenigen, die für Anbieter gebaut wurden, die hundertmal größer sind als Sie.
Brauchen Sie überhaupt schon ein MSA?
Nicht jedes Engagement braucht die volle Struktur. Ein einmaliges Projekt mit einem definierten Deliverable und einem sauberen Ende ist unter einer einzigen gut geschriebenen eigenständigen Vereinbarung in Ordnung — ein MSA für einen Kunden zu bauen, den Sie vielleicht nie wiedersehen, ist Prozess-Overhead ohne Nutzen.
Die Signale, dass Sie das einzelne Dokument überwachsen haben, sind Wiederholungsgeschäfte mit demselben Kunden, Retainer- oder laufende Support-Arbeit, bei der „fertig" kein Datum ist, Subunternehmer, die zu Ihren Engagements stoßen, und Beschaffungspapiere, die mit Bedingungen auf der Rückseite ankommen. Agenturen erreichen diese Signale schnell, oft mit ihrem ersten Multi-Projekt-Kunden. Solo-Freelancer erreichen sie normalerweise um das zweite oder dritte Engagement mit einem guten Kunden — genau dann, wenn ein MSA vorzuschlagen am einfachsten ist, weil beide Seiten die Beziehung bereits fortsetzen wollen. Rahmen Sie es als Effizienz, nicht als Eskalation: „Lass uns die stehenden Bedingungen an einem Ort bündeln, damit zukünftige Projekte nur eine kurze SOW brauchen."
Halten Sie Ihre Projektfinanzen so organisiert wie Ihre Verträge
Ein MSA plus SOWs pro Projekt geben jedem Engagement einen definierten Umfang, einen Meilensteinplan und einen Papierweg — genau der Rohstoff, auf dem gute Buchhaltung läuft. Wenn jede SOW auf ihren eigenen Einkommensstrom abbildet, Anzahlungen in unearned revenue liegen, bis sie verdient sind, und Meilensteinrechnungen in Ihren Forderungen sichtbar altern, sagen Ihnen Ihre Bücher die Rentabilität pro Kunde statt eines einzigen verschwommenen Mischbilds. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen vollständige Transparenz und Kontrolle über Ihre Finanzdaten gibt — keine Blackbox, kein Vendor-Lock-in. Starten Sie kostenlos und sehen Sie, warum Entwickler und Finanzfachleute zu Plain-Text-Buchhaltung wechseln.
