Wann Bulk wirklich sinnvoll ist: der Test auf Wiederholbarkeit
Bulk-Signaturen klingen nach einem Mengenproblem, sind aber zuerst ein Prozessproblem. Ein Unternehmen, das jeden Monat zweitausend Verträge, Nachträge oder Bestätigungen zur Unterschrift versendet, hat nicht zu viele Dokumente, sondern zu viele Handgriffe. Wer jede Einladung einzeln in einem Portal anlegt, Unterzeichner manuell einträgt und Status in Tabellen nachpflegt, betreibt Portal-Hopping: ständiges Wechseln zwischen Fachsystem, Portal und Postfach. Eine Bulk-Signatur-API ersetzt diese Handarbeit durch einen Ablauf, den das Fachsystem selbst steuert.
Nicht jeder Vorgang eignet sich dafür. Die Leitfrage lautet: Ist der Prozess wiederholbar und regelbasiert? Wenn Dokumente nach einem festen Muster entstehen, Unterzeichner aus Stammdaten kommen und die Folgeschritte klar sind, lohnt Automatisierung. Typische Beispiele sind Vertragsverlängerungen, Preisanpassungsschreiben, Datenschutzeinwilligungen für Bestandskunden, Arbeitsvertragsnachträge, Lieferantenvereinbarungen, Policen und Vollmachten. Wenn dagegen jedes Dokument individuell verhandelt wird, ist Bulk der falsche Ansatz, und eine einzelne, gut gestaltete Strecke ist besser.
Die eine harte Unterscheidung dieses Beitrags lautet: Bulk heißt nicht „viele auf einmal“, sondern „viele ohne Handarbeit“. Das ist ein Unterschied, der Architekturentscheidungen prägt. Entscheidend ist nicht, wie viele Vorgänge pro Sekunde möglich sind, sondern ob Anlage, Versand, Nachverfolgung und Abschluss ohne menschliches Eingreifen laufen, solange nichts Ungewöhnliches passiert. Der Mensch kümmert sich um Ausnahmen, nicht um den Normalfall.
Deshalb nennen wir bewusst keine Durchsatzzahlen. Zahlen wie „X Signaturen pro Minute“ klingen beeindruckend, sind aber ohne Kontext wertlos: Sie hängen von Dokumentgröße, Signaturstufe, Identifikationsverfahren, Ihren Fachsystemen und der Zeit ab, die Unterzeichner zum Handeln brauchen. Im Bulk-Fall ist der Engpass fast nie die API, sondern der Mensch, der unterschreiben muss, und Ihr eigenes System, das Ereignisse verarbeitet. Eine seriöse Aussage zu Last entsteht erst aus Tests mit Ihrem Profil.
Wichtig ist auch die Signaturstufe. Bulk-Szenarien laufen häufig mit SES oder AES, weil die Identifikation je Unterzeichner den Aufwand begrenzt. Bei QES kommen Identifikation und Partner-QTSP hinzu, was den Prozess verlängert und die Planung von Wartezuständen wichtiger macht. Sign2x ist kein QTSP, QES läuft über einen Partner wie Sign8. Eine Einführung in die Stufenwahl liefert der Beitrag AES vs QES per API.
Ein Prüfstein für Ihren Bedarf: Zählen Sie, wie viele Minuten Ihr Team pro Vorgang mit Anlage und Nachverfolgung verbringt, und multiplizieren Sie mit der Monatsmenge. Wenn das Ergebnis in Arbeitstagen gemessen wird, lohnt der Aufbau einer Strecke fast immer. Wenn es um wenige Stunden geht, genügt oft ein einfacherer Weg. Eine Einordnung Ihrer Lage kann das Sign2x Quiz unterstützen, Anwendungsfälle sammeln wir unter Use Cases.
Batch-Muster: von der Liste zum steuerbaren Ablauf
Ein tragfähiges Bulk-Muster besteht aus vier Bausteinen: Quelle, Planer, Ausführer und Rückmelder. Die Quelle ist Ihr Fachsystem, das die zu signierenden Dokumente und Unterzeichner liefert. Der Planer teilt die Menge in überschaubare Pakete, den Batches, und legt fest, in welcher Reihenfolge und mit welchen Abständen sie verarbeitet werden. Der Ausführer legt über die API Vorgänge an, hängt Dokumente an und startet den Versand. Der Rückmelder nimmt Ereignisse entgegen und überträgt Zustände zurück ins Fachsystem.
Die Aufteilung in Batches hat mehrere Gründe. Sie begrenzt den Schaden bei Fehlern: Wenn in einem Paket von zweihundert Vorgängen ein Dokument defekt ist, sollen nicht tausend andere liegen bleiben. Sie macht Fortschritt sichtbar: Sie sehen, dass Paket drei von zehn abgeschlossen ist. Und sie gibt Ihnen die Chance, vorsichtig zu starten: Ein kleines Pilotpaket vor dem Rest zeigt, ob Texte, Vorlagen und Empfängerdaten stimmen. Unsere Empfehlung ist, nie mit der vollen Menge zu starten, sondern mit einem Paket, das Sie in Ruhe prüfen.
Jeder Vorgang braucht eine eindeutige Referenz aus Ihrem System. Diese Referenz sorgt dafür, dass ein Wiederholungslauf keine Duplikate erzeugt: Bevor der Ausführer einen Vorgang anlegt, prüft er, ob zu dieser Referenz schon einer existiert. Dieses Muster nennt man Idempotenz, und es ist im Bulk-Fall unverzichtbar, weil Läufe unterbrochen und neu gestartet werden. Wer es versäumt, versendet im schlimmsten Fall zweimal denselben Vertrag an dieselbe Person.
Beim Versand sollten Sie Last und Wahrnehmung bedenken. Tausend Einladungen in derselben Minute können bei Empfängern als Spam wirken und bei Mailanbietern Filter auslösen. Verteilen Sie den Versand sinnvoll, und achten Sie auf Absenderkonfiguration und Betreffzeilen, die zum Anlass passen. In White-label-Szenarien gilt zusätzlich: Absender, Texte und Marke sollten dem Mandanten entsprechen, damit die Mail als vertrauenswürdig erkannt wird. Mehr zu diesem Thema im Beitrag White-label Signatur-API ohne Medienbruch.
Die Rückmeldung läuft über Webhooks, nicht über Polling. Bei hohen Volumen ist das nicht nur eleganter, sondern notwendig, denn Abfragen für tausend offene Vorgänge belasten alle Beteiligten ohne Gewinn. Die Ereignisse landen in Ihrer Warteschlange und werden vom Rückmelder in Zustände übersetzt. Die Grundlagen, einschließlich Idempotenz, Zustandsautomat und Fehlerablage, haben wir im Beitrag Webhook State Management für E-Signatur-Events ausgeführt. Im Bulk-Fall gilt jede dort genannte Regel verschärft.
Für die Steuerung brauchen Sie eine Sicht auf den Gesamtlauf: wie viele Vorgänge angelegt, versendet, geöffnet, signiert, abgelehnt, abgelaufen oder fehlerhaft sind. Diese Sicht ist nicht nur Controlling, sondern Betriebsinstrument. Sie zeigt, wann eine Erinnerung sinnvoll ist, wann ein Paket auffällig hohe Ablehnungen hat und wann ein technischer Fehler vorliegt. Bauen Sie sie früh, auch als einfache Tabelle, denn ohne sie arbeiten Sie im Blindflug.
Auch die Dokumentenerzeugung gehört zum Muster. Dokumente sollten vor dem Versand final und geprüft sein. Eine automatische Vorabprüfung, etwa auf fehlende Pflichtangaben, leere Platzhalter oder unplausible Beträge, verhindert, dass fehlerhafte Verträge versendet werden. Das Zurückrufen eines bereits versendeten Dokuments ist möglich, aber unangenehm: Empfänger sind verunsichert, und Sie müssen den Widerruf nachvollziehbar dokumentieren. Prävention ist hier deutlich billiger als Korrektur.
Fehler und Retries: was bei Volumen schiefgeht
Bei einzelnen Vorgängen sind Fehler Ausnahmen, bei Volumen sind sie Normalität. Mit tausend Vorgängen treffen Sie fast sicher auf ungültige E-Mail-Adressen, nicht lesbare Dokumente, Unterzeichner, die nicht reagieren, und kurzzeitige Störungen auf einer der beteiligten Seiten. Ein Bulk-Prozess muss damit rechnen und darf deshalb nicht als Gesamtheit scheitern, sobald ein Teil ausfällt.
Die erste Unterscheidung ist die zwischen dauerhaften und vorübergehenden Fehlern. Ein defektes Dokument oder eine syntaktisch ungültige Adresse wird auch beim zehnten Versuch scheitern, ein kurzer Netzausfall oder eine Überlastung dagegen nicht. Vorübergehende Fehler wiederholen Sie automatisch mit wachsenden Abständen und einer Obergrenze. Dauerhafte Fehler landen sofort in einer Fehlerliste, die ein Mensch prüft, ohne dass der Rest des Batches aufgehalten wird. Diese Trennung ist das wichtigste Qualitätsmerkmal einer Bulk-Strecke.
Die zweite Unterscheidung betrifft Fehler auf Seite des Unterzeichners. Nicht erreichbare Postfächer, abgelaufene Einladungen, abgebrochene Identifikationen und Ablehnungen sind keine technischen Störungen, sondern Teil des Prozesses. Ihr System sollte sie als Zustände abbilden, etwa „Zustellung fehlgeschlagen“ oder „Unterzeichner reagiert nicht“, und fachliche Folgeschritte vorsehen: Erinnerung, alternativer Kontaktweg, Eskalation an einen Ansprechpartner. Wer das nicht modelliert, hat am Ende hunderte Vorgänge im Zustand „offen“, ohne zu wissen, warum.
Beim Wiederanlauf hilft ein klarer Grundsatz: Jeder Lauf muss gefahrlos wiederholbar sein. Das erreichen Sie über die erwähnten Referenzen und über ein Protokoll, das je Vorgang festhält, wie weit er gekommen ist. Nach einem Absturz startet der Lauf neu, überspringt Fertiges und setzt Offenes fort. Testen Sie diesen Fall gezielt, indem Sie einen Lauf absichtlich unterbrechen. Viele Teams entdecken erst im Ernstfall, dass ihr Wiederanlauf Duplikate erzeugt.
Ratenbegrenzungen gehören ebenfalls dazu. Jede Schnittstelle begrenzt Anfragen, um sich zu schützen. Ihr Ausführer sollte diese Grenzen respektieren, statt sie zu testen, und bei entsprechenden Rückmeldungen die Geschwindigkeit drosseln. Das ist keine Schwäche, sondern gute Betriebspraxis. Die genauen Grenzen und Empfehlungen entnehmen Sie der Dokumentation im Developer Hub, und wir nennen hier bewusst keine Zahlen, die bei Änderungen veralten und falsche Erwartungen wecken würden.
Für die Beobachtbarkeit empfehlen wir einige wenige Kennzahlen: Anteil abgeschlossener Vorgänge je Paket, Anteil abgelehnter und abgelaufener, Größe der Fehlerliste, Dauer von Versand bis Signatur. Diese Zahlen zeigen schnell, ob etwas nicht stimmt, etwa wenn ein Paket plötzlich viele Ablehnungen hat, weil ein Vertragstext missverständlich war. Alarme sollten bei Abweichungen von Ihrer eigenen Baseline anschlagen, nicht bei erfundenen Standardwerten.
Ein oft übersehener Punkt ist die Reihenfolge der Unterzeichner. Bei Verträgen mit mehreren Parteien kann es fachlich nötig sein, dass zuerst die interne und dann die externe Seite unterschreibt, oder umgekehrt. Im Bulk-Fall multipliziert sich jede falsche Einstellung. Legen Sie Rollen und Reihenfolge deshalb in der Vorlage fest, nicht im einzelnen Vorgang, und prüfen Sie sie im Pilotpaket. Gleiches gilt für Fristen: Eine Einladung, die nach sieben Tagen verfällt, braucht eine Erinnerung nach drei bis vier Tagen, sonst erzeugen Sie selbst die Menge an abgelaufenen Vorgängen, die Ihr Team später mühsam nachbearbeitet.
Planen Sie außerdem Zeitfenster für große Läufe. Versendet Ihr System am Freitagabend zehntausend Einladungen, treffen Antworten und Rückfragen am Montagmorgen auf ein Team, das darauf nicht vorbereitet ist. Wählen Sie Zeitpunkte, zu denen Support und Fachbereich erreichbar sind, und informieren Sie diese vorab über Umfang, Inhalt und Erwartung. Das ist keine Technik, aber es entscheidet über die Akzeptanz des Verfahrens im Unternehmen.
Compliance bei Volumen: Nachweis, Datenschutz, Aufbewahrung
Hohe Volumen erhöhen den Druck auf Compliance, weil Fehler sich vervielfachen. Drei Themen verdienen Aufmerksamkeit. Das erste ist der Nachweis: Bei tausend Vorgängen können Sie nicht jeden einzeln manuell dokumentieren. Ihre Ereignishistorie muss deshalb vollständig und abfragbar sein. Jeder Vorgang braucht eine lückenlose Kette von Ereignissen mit Zeit, Rolle und Dokumentprüfsumme. Wie diese Kette im Kontext von Lieferkettenpflichten funktioniert, beschreibt der Beitrag DORA Artikel 30 und der Signatur-Audit-Trail. Es ist Evidence, keine Zertifizierung.
Das zweite Thema ist der Datenschutz. Bulk-Läufe verarbeiten viele personenbezogene Daten gleichzeitig, und Fehler wirken sich breit aus: Eine falsche Zuordnung kann hunderte Personen betreffen. Prüfen Sie vor dem Lauf, ob die Rechtsgrundlage für alle Empfänger trägt, ob die Daten minimiert sind und ob Löschfristen definiert sind. Die DSGVO gilt unabhängig vom Volumen, aber bei Masse wird jede Nachlässigkeit sichtbarer. Ein Vieraugenprinzip für den Start eines Laufs ist eine einfache, wirksame Maßnahme.
Das dritte Thema ist die Aufbewahrung. Signierte Dokumente und Ereignisprotokolle müssen so lange verfügbar bleiben, wie Gesetz und Vertrag es verlangen, und zugleich gelöscht werden, wenn der Zweck entfällt. Bei Volumen brauchen Sie dafür automatisierte Regeln: Aufbewahrungsklassen je Dokumenttyp, Löschläufe, Nachweis der Löschung. Klären Sie früh, wo signierte Dokumente langfristig liegen, im Fachsystem, in einem Archiv oder in beidem, und wie Sie sie bei einem Anbieterwechsel exportieren können.
Bei regulierten Kunden kommen Vorgaben zur Lieferkette hinzu. Wenn Ihre Software von Finanzunternehmen eingesetzt wird, fragen diese nach Standort, Eigentümerstruktur und Ausstieg des Signaturdienstes. Die Antworten sollten für alle Läufe und Mandanten einheitlich gelten. Wie Sie solche Nachweise strukturieren, zeigt auch der Beitrag NIS-2 Nachweis über den Audit-Trail. Wir betonen: Nachweise sind Evidence, keine Zertifizierung, und weder DORA noch NIS-2 kennen ein Siegel für Signatur-APIs.
Schließlich die Kommunikation: Bei Masseversand erwarten Empfänger Klarheit. Wer schickt das Dokument, warum, bis wann ist zu handeln, an wen wende ich mich bei Fragen? Gute Texte senken Rückfragen und Abbrüche erheblich. Pflegen Sie sie zentral, versionieren Sie sie und passen Sie sie je Mandant an. Hilfreiche Antworten für Endnutzer lassen sich im Help Center bündeln, auf die Sie in der Einladung verweisen können.
Hosting und Jurisdiktion: Rahmen für große Mengen
Große Dokumentmengen erhöhen die Bedeutung der Frage, wo sie liegen. Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Für Unternehmen, die Verträge, Personal- oder Kundendaten in großen Mengen verarbeiten, ist das eine klare Antwort auf die Frage nach Eigentum und Zugriffsrecht. Die Hintergründe zur rechtlichen Einordnung finden Sie im Beitrag Cloud Act vs Datensouveränität und in der Vertiefung Open Sovereign Cloud für die E-Signatur-API.
Hosting auf OSC ist eine Aussage über Betrieb und Jurisdiktion. Sie ersetzt weder Ihre Datenschutzprüfung noch eine Lastplanung. Wenn Sie sehr große Läufe planen, sprechen Sie vorab mit uns über Zeitfenster, Paketgrößen und Besonderheiten Ihres Profils, statt auf pauschale Aussagen zu vertrauen. Wir arbeiten mit Ihnen ein Vorgehen aus und sagen offen, wo wir keine Garantien geben können. Das ist uns lieber als ein Versprechen, das im Ernstfall nicht trägt.
Für Unternehmen mit Vorgaben, die auch einen souveränen Cloud-Betrieb ausschließen, besteht die Option, die Strecke im eigenen Rechenzentrum zu betreiben. Dann liegt die Dimensionierung bei Ihnen, und Sie planen Rechenleistung, Speicher und Datensicherung nach Ihrem Bedarf. Bei QES bleibt der Partner-QTSP Teil der Kette. Ob dieser Betriebsmodus für Ihren Fall sinnvoll ist, klären wir im Gespräch. Für die meisten Unternehmen ist der Standardbetrieb die schlankere Lösung.
Wenn Sie wissen möchten, wie ein Bulk-Ablauf zu Ihrem Fachsystem passt, beginnen Sie mit einem kleinen Piloten: ein Dokumenttyp, ein Paket von einigen hundert Vorgängen, eine klare Erfolgsdefinition. Technische Grundlagen finden Sie im Developer Hub, und der Weg zur ersten funktionierenden Strecke ist im Beitrag Von der Sandbox zur ersten QES-Strecke beschrieben. Weitere Fachbeiträge liefert der Sign2x Blog.
Bulk-Szenario mit uns durchsprechen
Verwandte Beiträge: Silent Tech: Signatur ohne Medienbruch in ERP-Oberflächen und QTSP-Partner für ISVs. Rechtsgrundlagen der Signaturstufen in der eIDAS-Verordnung, Sicherheitshinweise beim BSI.
Häufige Fragen
Wann lohnt sich eine Bulk-Signatur-API?
Wenn Vorgänge wiederholbar und regelbasiert sind, etwa Vertragsverlängerungen, Einwilligungen oder Nachträge, und Ihr Team viel Zeit mit Anlage und Nachverfolgung verbringt.
Welche Durchsatzzahlen garantiert Sign2x?
Wir nennen keine pauschalen Durchsatzzahlen. Sie hängen von Dokumentgröße, Signaturstufe, Identifikation und Ihren Fachsystemen ab. Belastbare Aussagen entstehen aus Tests mit Ihrem Profil.
Wie vermeide ich Duplikate bei Wiederholungsläufen?
Geben Sie jedem Vorgang eine eindeutige Referenz aus Ihrem System und prüfen Sie vor der Anlage, ob dazu schon ein Vorgang existiert. Ein Protokoll je Vorgang ermöglicht sicheren Wiederanlauf.
Wo wird Sign2x gehostet?
Auf der Open Sovereign Cloud (OSC) von T-Systems. Für besondere Anforderungen ist ein Betrieb im eigenen Rechenzentrum im Einzelfall möglich.
Unterstützt Bulk auch QES?
Ja, grundsätzlich. Bei QES kommen Identifikation und Partner-QTSP hinzu, was Prozesse verlängert. Sign2x ist kein QTSP, die Qualifikation läuft über einen Partner wie Sign8.
