Online-Vertragsunterzeichnung — papierlos für Dienstleister umsetzen (2026)

Kurzfassung

Statt E-Mail-Threads mit Scans und „welche Word-Version ist aktuell?“: Vertrag aus Vorlage erzeugen, dem Kunden einen einmaligen Link senden, im Browser unterschreiben, System speichert PDF mit Audit-Trail, versendet Transaktions-E-Mail und setzt den Status in der Datenbank. Für IT-Dienstleistungsverträge B2B in der EU reicht meist die einfache elektronische Signatur (Willenserklärung + Logs + Archiv) — qualifizierte Signatur (eIDAS) nur in regulierten Branchen. Im Folgenden: API-Architektur, Sicherheit und ein ehrlicher Rechts-Hinweis.

Für wen ist das

• Softwarestudios, Agenturen und Beratung, die Projekte per Dienstleistungs- oder Werkvertrag verkaufen
• Teams mit Vorlagen (Word/Google Docs), die eine Quelle der Wahrheit wollen (HTML → PDF)
• B2B-Kunden, die Projektstart in Tagen statt Wochen nach „bitte Scan mit Stempel“ erwarten
• Firmen, die ein eigenes Panel statt teurem SaaS mit Nutzerlimits bauen

Keyword (SEO)

vertrag online unterschreiben, elektronischer vertrag unternehmen, kundensignatur website, vertragsworkflow b2b, elektronische signatur werkvertrag, vertragsarchiv pdf

Das Problem, das Sie lösen

Typisches B2B-Chaos: Angebot als PDF → Verhandlung per Mail → Word v3_final_FINAL2.docx → Scan ohne klares Datum → kein Eintrag, wer welche DSGVO-Klausel wann akzeptiert hat. Jeder Tag Verzögerung bedeutet Projektverlust-Risiko und Admin-Kosten.

Ein Online-System ordnet das in fünf Schritten mit einer Vertrags-ID in der Datenbank.

B2B-Workflow — von der Vorlage zum Archiv

1. Vertragsvorlage

Die Vorlage enthält Variablenfelder: Firmenname, USt-IdNr., Leistungsumfang, Betrag, Zeitplan, IP, DSGVO-Klauseln, Versionsnummer in der PDF-Fußzeile. Bei DevStudio übernimmt die Schicht contract-templates die Vorlagen — Inhalt wird programmatisch erzeugt, nicht bei jedem Verkauf manuell aus Word kopiert.

2. Datensatz und Link anlegen

Der Endpoint POST /api/contracts (plus Flow /api/create-contract-link) erzeugt eine eindeutige Vertrags-ID, Startstatus und Kundenmetadaten. Der Admin sendet keine Datei — sondern einen Link zur Seite /contract/[contractId].

3. Versand an den Kunden

POST /api/contracts/[id]/send versendet E-Mail mit Link (Rate Limit und IP-Logging). Status wechselt zu sent_to_client. Der Kunde sieht Inhalt, Zustimmungs-Checkboxen und Signaturfeld (Canvas oder Handschrift).

4. Kundensignatur

POST /api/contracts/[id]/sign nimmt signedData entgegen, prüft Status sent_to_client, speichert Signatur, IP (getClientIp), Timestamp und erzeugt PDF via pdf-lib. Optional folgt /api/contracts/[id]/admin-sign, wenn die Firma nach dem Kunden gegenzeichnet.

5. Archiv und Benachrichtigungen

• GET /api/contracts/[id]/download-pdf — Download mit beiden Exemplaren / vollem PDF
• POST /api/generate-contract — PDF aus Vorschau (ebenfalls mit Rate Limit)
• POST /api/send-contract-email — Bestätigungsmail an Kunden (Endpoint admin-geschützt — requireAdminApi)

Kunde und Firma haben dieselbe Vertragsnummer, Signaturdatum und Audit-Pfad in der DB — nicht „jemand hatte die Datei auf dem Desktop“.

API-Übersicht — wer macht was

Stack: Next.js 15, Prisma, pdf-lib, nodemailer / transaktionale SMTP-Schicht. Das ist kein „Formular mit Anhang“ — eine kleine Workflow-App neben der Marketing-Website.

Einfache vs. qualifizierte Signatur (eIDAS) — ohne Juristenjargon

Rechtlicher Hinweis (wichtig)

Dieser Artikel ist keine Rechtsberatung. Gesetze und Gerichtspraxis hängen von Vertragswert, Branche und Vertragsparteien ab. Bei hochwertigen Verträgen oder regulierten Sektoren Vertragsinhalt und Signaturform mit Anwalt klären. Die technische Umsetzung liefert Audit-Spur und Prozess — ersetzt nicht die Prüfung, ob die Signaturform in Ihrem Fall erforderlich ist.

Für typische Dienstleistungsverträge zwischen Unternehmen in der IT ist sinnvoll: klare Klausel zu Schriftform und elektronischer Signatur, Zustimmung zu Erklärungen über das System, Versionsnummer und Archiv bei beiden Seiten.

Was die Signatur-Anwendung brauchen muss

HTTPS und Rollen

Der gesamte Flow nur über HTTPS. Zwei Rollen: Kunde (öffentlicher Link mit Token/ID) vs. Admin (Panel, Firmensignatur, Mailversand). Admin-Endpoints dürfen nicht anonym erreichbar sein.

Audit-Trail

Bei der Signatur mindestens speichern:

• Vertrags-ID und Vorlagenversionsnummer,
• Datum und Uhrzeit (UTC in DB, lokales Format in PDF),
• IP des Kunden (wie in sign/route.ts),
• Hash oder Inhalt akzeptierter Checkboxen (DSGVO, AGB).

Das ist kein „Spionage“ — Nachweis des Ablaufs bei Streit „ich habe diese Version nicht unterschrieben“.

PDF-Versionierung

Jede Änderung von Umfang oder Preis = neue Vorlagenversion und neuer Datensatz / neuer Link. PDF-Fußzeile: Vorlage 2026-05-28 / Vertragsnr. DS-2026-0142.

Transaktions-E-Mail

Nach signed: Mail an Kunden mit Vertragsnummer, Datum und PDF-Link (oder Anhang — je nach Storage-Policy). Separates Team-Notification (buildContractAdminSignedNotificationEmail).

Die E-Mail sollte klar zwischen Einladung zur Signatur und Bestätigung nach Signatur unterscheiden — unterschiedliche Betreffzeilen, keine verwechselbaren Templates. Kunden suchen Wochen später nach „Vertrag [Firmenname]“; konsistente Betreff-Patterns sparen Support-Zeit. Für B2B-Kunden ist oft ein Link zum Download ausreichend; Anhänge erhöhen Zustellrisiko bei großen PDFs und strengen Mail-Gateways.

Sicherheit — Minimum, das nicht optional ist

Token und Vertrags-ID

Link /contract/[contractId] sollte lange, zufällige ID (UUID) nutzen, nicht sequenzielles id=123. Erraten der URL = Zugriff auf Vertragsinhalt vor Signatur.

Rate Limiting

Bei DevStudio nutzen Signatur-, Versand- und PDF-Endpoints checkEmailRateLimit(ip) — Antwort 429 mit Retry-After bei Missbrauch. Schützt vor Signatur-Spam und Brute-Force auf öffentlichen APIs.

Ablauf und Einmaligkeit

Nach Signatur Status ≠ sent_to_client — erneuter sign liefert Fehler. Link sollte keine unbegrenzten Edits ohne Log erlauben. Optional: Link-Gültigkeit 7–14 Tage in expiresAt.

Keine Google-Indexierung

Layout der Vertragsseite setzt u. a. X-Robots-Tag: noindex, nofollow, noarchive — Verträge und Kundendaten landen nicht im Suchindex. Standard bei vertraulichen Dokumenten.

Admin-Endpoint-Schutz

/api/send-contract-email erfordert requireAdminApi — zufälliger POST aus dem Internet sendet keine Mail im Firmennamen.

Integrationen für später

• CRM / Notion / Slack — Webhook bei Status signed (Projektstart in #delivery)
• Rechnungsstellung — Rechnung erst nach signed, nicht nach „mündlicher Zusage“
• Buchhaltung — Export von Vertragsmetadaten (Nummer, Betrag, USt-IdNr.)
• Dropbox / S3 — Langzeit-PDF-Archiv außerhalb des App-Servers

Einfaches MVP ohne CRM spart gegenüber Scan-Mails trotzdem enorm Zeit. Der Webhook-Payload sollte mindestens contractId, status, signedAt, Kunden-E-Mail und Vertragsbetrag enthalten — damit Buchhaltung und Projektmanagement ohne manuelles Copy-Paste aus dem Admin-Panel starten können. Viele Teams beginnen mit Slack-Benachrichtigung und ergänzen CRM erst, wenn der monatliche Vertragsdurchsatz die manuelle Nacharbeit spürbar macht.

Statusmodell — warum jeder Schritt zählt

Ein klares Statusmodell verhindert Chaos: draft → sent_to_client → signed (optional admin_signed). Jeder Übergang wird serverseitig protokolliert. Der Kunde darf in signed keine Klauseln mehr ändern; Änderungswünsche erfordern neue Version und neuen Link. So bleibt der Audit-Trail konsistent — wichtig, wenn Monate später die Frage kommt, welche AGB-Version unterschrieben wurde.

Häufige Implementierungsfehler

1. Word senden statt einem PDF-Generator — fünf „rechtliche Wahrheiten“.
2. Fehlende Klausel, dass Klick „Ich unterzeichne“ elektronische Willenserklärung ist.
3. Derselbe Link mehrfach ohne Status- und Log-Änderung.
4. Keine PDF-Kopie im Postfach des Kunden — „wo ist der Vertrag?“ eine Woche später.
5. Indexierbare Vertrags-URLs — Metadaten-Leak in Google.
6. Signatur vor Annahme des Umfangs (Checkboxen unter statt über der Signatur).
7. Kein Counter-Sign der Firma, wenn der Kunde sofort beidseitiges PDF erwartet.

Zusätzlich in der Praxis: fehlende Test-Unterschrift im Staging — Teams testen nur den Admin-Flow und vergessen Mobile-Safari mit Touch-Signatur; Zeitzonen in PDF vs. DB (UTC speichern, in PDF lokale Zeit des Kunden anzeigen); Sprachversionen des Vertrags — DE-Kunde soll nicht polnische AGB unterschreiben, weil nur ein Template existiert.

Wie lange dauert die Umsetzung?

Zeiten setzen fertige Rechtsvorlage von der Kanzlei voraus — Klausel-Redaktion dauert oft länger als Code.

FAQ

Ist die Signatur auf dem Bildschirm in Deutschland legal?

Bei B2B-Verträgen zwischen Unternehmen — in der Praxis oft ja, als Willensäußerung mit Systemlogs und PDF. Ausnahmen und hoher Vertragswert → Anwalt. Artikel ersetzt keine Beratung.

Ersetzt das DocuSign / Autenti?

Für internen B2B-IT-Flow oft funktional ja (Link, Signatur, PDF, Mail). Für Rechts-Ökosystem mit qualifizierter Signatur und Konzernvolumen — TCO Lizenz vs. eigenes Modul auf Next.js vergleichen.

Was, wenn der Kunde keine Maus für Handschrift hat?

Checkbox + Vor- und Nachname / Position in signedData reicht — wichtiger ist prozessuale Konsistenz als schönes SVG der Unterschrift.

Wo PDF über Jahre aufbewahren?

Datenbank + Object Storage mit Backups und Retention gemäß DSGVO (Zweck, Löschung nach Aufbewahrungsfrist). Nur E-Mail des Kunden reicht nicht als einziges Archiv.

Sind Chatbot und Kontaktformular derselbe Vertrag?

Nein — Website-Lead ist Lead. Vertrag ist eigener Datensatz nach Angebotsannahme. In einer Mail zu mischen verwischt Marketing und Recht.

Admin-Panel — was Vertrieb sieht

Nach Go-live: Listenansicht mit Status (draft, sent_to_client, signed, …), Versanddatum, Kunde, Betrag, PDF-Link. Admin darf Inhalt nach Versand an Kunden nicht ohne neue Version ändern — sonst bezieht sich die Signatur auf ein anderes Dokument als im Archiv. Sensible Aktionen (z. B. Mail erneut senden) über admin-autorisierte Endpoints, nicht über den öffentlichen Link.

PDF-Inhalts-Normalisierung (pdf-lib)

Umlaute und Sonderzeichen in PDFs brauchen manchmal Normalisierung oder eingebettete Fonts — im Signatur-Code wird Text für PDF teils ASCII-kompatibel normalisiert, um „leere Kästchen“ beim Kunden zu vermeiden. Technisches Detail, aber entscheidend für professionelles Erscheinungsbild gegenüber der Buchhaltung des Kunden.

Vergleich mit SaaS (DocuSign, Autenti usw.)

Bei Dutzenden Verträgen pro Jahr in der IT amortisiert sich Eigenbau; bei einem Vertrag pro Jahr — SaaS oder signiertes PDF per Mail kann reichen.

DSGVO und Administratorrollen

Verträge enthalten personenbezogene Daten (Kundenvertreter, E-Mail, Telefon). In der Datenschutzerklärung Zweck (Vertragsschluss), Rechtsgrundlage (z. B. Vertrag / berechtigtes Interesse), Aufbewahrungsfrist für PDF und Logs beschreiben. Nach Frist — Lösch- oder Anonymisierungsprozedur in der DB. Signatur-Link nicht indexieren — bereits noindex — und nur für URL-Inhaber zugänglich.

Zusammenfassung

Online-Vertragsunterzeichnung im Dienstleister-B2B ist ein Workflow: Vorlage → API → Link → Signatur → PDF → E-Mail → Status signed. Technisch: Next.js API Routes (contracts, sign, generate-contract, send-contract-email), pdf-lib, Rate Limit, noindex. Rechtlich: für typisches B2B-IT reicht meist einfache Signatur mit gutem Audit — bei Zweifeln Anwalt, nicht Blog. Starten Sie mit einer Vorlage und einem Happy Path — erweitern Sie um Admin-Sign und CRM, wenn der Prozess steht.

Signatur-System bei Ihnen?

• Kontakt aufnehmen — Vorlagen und Integrationen besprechen
• Web-Apps — dedizierte B2B-Module in Next.js
• Portfolio ansehen — Projekte mit Prozessautomatisierung