Was einfach klingt, stellt viele Shop-Betreiber vor ein technisches Dilemma: Wann beginnt die Frist eigentlich?
Versanddatum ≠ Fristbeginn. Laut BGB startet die 14-tägige Widerrufsfrist mit dem Eingang der Ware beim Verbraucher – also dem Zustelldatum. Doch genau dieses Datum ist in den meisten Shop-Systemen und ERPs schlicht nicht vorhanden. Es liegt ausschließlich beim Versanddienstleister vor.
Viele Shop-Erweiterungen berechnen die Frist auf Basis des Erstelldatums der Lieferung – das ist nicht das Zustelldatum und damit rechtlich unvollständig. Ein Blind Spot hierbei sind auch Teillieferungen. Bei getrennten Sendungen beginnt die Frist des Widerrufs erst mit Erhalt der letzten Ware. Dies muss bei der Berechnung der Widerrufsfrist ebenfalls berücksichtigt werden.
Drei Datenquellen kommen für ein belastbares Bezugsdatum infrage: das ERP-System (liefert i. d. R. das Übergabedatum an den Carrier), die Carrier-Tracking-API (z. B. DHL, UPS, Spedition) als einzige Quelle für das echte Zustelldatum sowie das Bestelldatum oder Versanddatum im Shop als konservative Fallback-Basis mit definiertem Puffer.
Kurzfristig ist ein kalkulierter Puffer auf das Bestelldatum die pragmatische Lösung. Mittel- bis langfristig empfehlen wir die Rückübertragung des ERP-Versanddatums und Zustelldatums an den Shop (wo sinnvoll, direkte Integration der Carrier-API).
Technische Checkliste – Was auf Systemseite geplant und umgesetzt werden muss
1. Rechtliche & organisatorische Voraussetzungen
Widerrufsrecht prüfen: Gilt für alle Produkte im Sortiment? Ausnahmen identifizieren (Sonderanfertigungen, verderbliche Waren etc.).
Widerrufsbelehrung auf Aktualität prüfen: Muss auf den neuen Button-Prozess und die elektronische Widerrufsmöglichkeit verweisen.
Internen Widerrufsprozess definieren: Wer bearbeitet eingehende Widerrufserklärungen? Welches System ist führend?
Datenschutzerklärung prüfen: Verarbeitung der Widerrufsdaten (Name, E-Mail, Bestellnummer) muss dokumentiert sein.
2. Shop-System (Frontend)
Geeignete Extension auswählen und testen: Auf zweistufigen Prozess, Formularpflichtfelder und Bestätigungs-E-Mail prüfen.
Startdatum der Fristberechnung konfigurieren: Rechnet die Extension ab Shipment-Datum, Bestelldatum oder einem Custom-Attribut? Bei Teillieferung die Zustellung der zuletzt ausgehenden Ware einer Bestellung. Bestelldatum + Puffer ist kurzfristig die sicherste Option.
Fristpuffer festlegen Empfehlung: Bestelldatum + 20–25 Tage, bis ein Zustelldatum verfügbar ist. Für Auslandslieferungen ggf. länger.
Hervorgehobene Button-Platzierung und Wortlaut prüfen: Pflichtbeschriftung „Vertrag widerrufen" / „Widerruf bestätigen". Auch Gastbesteller:innen müssen einen sichtbaren Zugang zu dem Widerruf erhalten z. B. auf einer separaten Seite für den Widerruf, die über das Suchformular und das Shopmenü auffindbar ist.
Zweistufigen Prozess und Bestätigungs-E-Mail testen: Schritt 1: Button → Formular. Schritt 2: Bestätigen → automatische E-Mail-Eingangsbestätigung an den Kunden.
Teilwiderruf abbilden: Können Kunden einzelne Positionen aus einer Bestellung widerrufen? Extension und Prozess müssen das unterstützen.
3. Datenverfügbarkeit: Versand- & Zustelldatum
Klären: Wo liegt das Versand- und Zustelldatum? Liegt es im Shop-System, im ERP, beim Carrier oder gar nicht strukturiert vor? Wird es an den Shop übertragen?
ERP-Shop-Schnittstelle prüfen: Überträgt das ERP bei Versandanlage einen Zeitstempel an den Onlineshop? Falls nicht: Erweiterung der Schnittstelle planen.
Carrier-Tracking-API evaluieren: DHL, UPS, DPD bieten Tracking-APIs. Liefert deren API ein Zustelldatum zurück? Welche Carrier sind im Einsatz?
Zustelldatum als Custom-Attribut im Shop einplanen: Wenn die Carrier-API integriert wird: Zustelldatum als Order- oder Shipment-Attribut speichern, damit die Extension darauf zugreifen kann.
Fallback-Strategie definieren: Was passiert, wenn Tracking-Daten nicht abrufbar sind? Puffer-Logik als Fallback dokumentieren.
4. ERP & interne Systemintegration
Widerrufsstatus im ERP abbilden: Eingehende Widerrufserklärungen müssen im ERP verarbeitet werden, u. A. Retoure anlegen, Erstattung auslösen, Bestand zurückbuchen. Kritisch dabei der Zeitversatz zwischen dem Auslösen des Widerrufs im Frontend und der Übergabe an das ERP. Wenn der Kunde den Button klickt, muss der Status im ERP eigentlich in Echtzeit auf "Widerruf" springen. Nur so kann verhindert werden, dass die Logistik die Ware (falls noch im Lager) trotzdem rausschickt.
Automatischen Datenaustausch prüfen: Wird der Widerruf aus dem Shop automatisch ins ERP übertragen oder erfolgt das manuell? Prozessbrüche identifizieren.
Retourenprozess: Wie erfolgt die Rücksendung der Ware, wenn diese bereits versendet wurde? Wie wird diese Information an die entsprechenden Käufer:innen übermittelt?
Erstattungslogik klären 14-Tage-Frist für Rückzahlung nach Widerruf (§ 357 BGB). Wer löst die Erstattung aus – Shop, ERP oder manuell? Häufig wird ignoriert, dass ein Widerruf im Shop-Backend keine automatische Rückzahlung bei PayPal, Klarna & Co. auslöst, wenn die Bearbeitung des Widerrufs in einem ERP erfolgt.
Fazit: Der Widerrufsbutton ist keine reine Frontend-Aufgabe
Die Einführung des Widerrufsbuttons zum 19. Juni 2026 ist weit mehr als eine optische Anpassung im Frontend. Die wahre Herausforderung liegt in der Datenintegrität: Nur wer das tatsächliche Zustelldatum systemisch im Griff hat, entgeht dem Risiko von Abmahnungen oder unberechtigt langen Widerrufsfristen.
Während ein großzügiger Puffer auf das Bestelldatum eine pragmatische Soforthilfe bietet, führt langfristig kein Weg an einer tiefen Integration von ERP, Shop und Carrier-APIs vorbei. Werden diese Hausaufgaben ignoriert, drohen prozessuale Brüche und ein massiver manueller Aufwand im Kundenservice. Online-Händler sollten jetzt handeln, um ihre Systeme rechtssicher und effizient zu synchronisieren.
Sie sind unsicher, wo in Ihrem System die relevanten Daten liegen oder wie die Integration aussehen soll? Wir analysieren gemeinsam mit Ihnen die Prozesse hinter dem Button.
