Chargeback-Nachweispaket als Muster: ein SaaS-Kündigungsfall

Ein fiktives Paket zum Nachvollziehen

Fiktives Lernbeispiel. Alle Kennungen, Ereignisse, Auszüge, Beträge und Ergebnisse wurden für diesen Leitfaden erfunden. Es enthält keine echten Kundendaten, Bankentscheidung, Produktausgabe oder gemessene Rückgewinnung. Das Paket zeigt eine interne Prüfung und darf nicht als Nachweis für eine echte Zahlung eingereicht werden.

Das fiktive Nachweispaket als PDF herunterladen (Deutsch).

Das vollständige Beispiel steht auch unten und in der Markdown-Version dieses Artikels. Zum Lesen benötigen Sie weder Anmeldung noch JavaScript.

Falldeckblatt

• Fall: DEMO-CASE-001; Prüfversion 1, 6. Oktober 2026.
• Händler: Example Workspace, ein fiktiver Anbieter von Abo-Software.
• Kundenkonto: DEMO-ACCOUNT-042; Abonnement DEMO-SUB-009.
• Beanstandete Zahlung: DEMO-PAY-001, 96 EUR, eingezogen am 1. Oktober 2026 um 08:00 Uhr UTC.
• Leistungszeitraum: 1.–31. Oktober 2026.
• Beschwerde: „Ich habe vor der Verlängerung gekündigt, und mir wurde zugesagt, dass keine Abbuchung mehr erfolgt.“
• Arbeitskategorie: gekündigte wiederkehrende Zahlung; im echten Fall den tatsächlichen Anbietercode prüfen.
• Prüfstand: interne Feststellung vorbereitet; in diesem Beispiel wurde keine Antwort eingereicht.

Der Fall verwendet ein einzelnes Abokonto, damit die Belegkette übersichtlich bleibt. Bei B2B-SaaS braucht es zusätzlich die Zuordnung von Zahler und Unternehmen sowie Mitglied und Workspace. Die Methode lässt sich auf ein B2C-SaaS-Konto anwenden, ohne diese Beziehungen gleichzusetzen.

1. Der Zeitverlauf

Alle Beispielzeiten sind UTC. Jeder Eintrag verweist auf den Auszug im nächsten Abschnitt.

1. 28. September, 10:12 Uhr — E3: Der Kunde bittet den Support, DEMO-SUB-009 vor Oktober zu beenden.
2. 28. September, 10:30 Uhr — E3: Der Support bestätigt das Ende zum 30. September und sagt zu, dass keine Oktoberverlängerung abgebucht wird.
3. 1. Oktober, 08:00 Uhr — E1: Die Abrechnung zieht 96 EUR für Oktober ein. Die Kündigung wurde noch nicht umgesetzt.
4. 2. Oktober, 11:05 Uhr — E2: Das Konto meldet sich an und lädt eine ältere Rechnung herunter.
5. 3. Oktober, 09:20 Uhr — E4: Ein Administrator setzt die Kündigung um.
6. 5. Oktober, 14:00 Uhr — E5: Für DEMO-PAY-001 wird ein Streitfall erfasst.
7. 6. Oktober, 09:00 Uhr — E6: Die Prüfung der Geldbewegungen ergibt im Beispiel keine separat abgeschlossene Erstattung.

Die Reihenfolge ist entscheidend. Die Belastung lag vor der administrativen Kündigung, aber nach der Supportzusage. Eine Zusammenfassung nur aus Zahlung und Bearbeitungsereignis würde die wichtigste Tatsache auslassen.

2. Die Belegauszüge

E1 — Zahlung und Rechnung

Fiktive Quelle: Zahlungsjournal, DEMO-PAY-001, mit Rechnung DEMO-INV-010 und Abo DEMO-SUB-009 verknüpft.

Eingezogen: 96,00 EUR. Erfasst: 2026-10-01, 08:00 Uhr UTC. Leistungszeitraum: 2026-10-01 bis 2026-10-31. Kundenkonto: DEMO-ACCOUNT-042.

Stützt: Der Betrag wurde für den genannten Zeitraum eingezogen und gehört zum geprüften Abo.

Belegt nicht: Dass die Verlängerung nach der Supportzusage weiterhin angemessen war.

E2 — Kontoaktivität

Fiktive Quelle: Ereignisprotokoll von DEMO-ACCOUNT-042.

2026-10-02, 11:05 Uhr UTC: authentifizierte Sitzung. Aktion: Rechnung DEMO-INV-009 für September heruntergeladen.

Stützt: Das Konto war erreichbar und führte diese Verwaltungsaktion aus.

Belegt nicht: Nutzung einer kostenpflichtigen Oktoberfunktion, Zustimmung zur Verlängerung oder Rücknahme der Kündigung. Eine alte Rechnung herunterzuladen ist etwas anderes als die gekaufte Leistung zu nutzen.

E3 — Die Kündigungszusage

Fiktive Quelle: Supportgespräch DEMO-SUPPORT-017, verknüpft mit DEMO-ACCOUNT-042 und DEMO-SUB-009.

Kunde, 28. September, 10:12 Uhr UTC: „Bitte beenden Sie dieses Abo vor Oktober. Es soll sich nicht verlängern.“

Support, 28. September, 10:30 Uhr UTC: „Ich habe veranlasst, dass dieses Abo am 30. September endet. Eine Oktoberverlängerung wird nicht abgebucht.“

Stützt: Die Darstellung des Kunden, dass die Kündigung vor der beanstandeten Verlängerung angefragt und bestätigt wurde.

Widerspricht: Einer vorgeschlagenen Aussage, es habe keine Kündigungsanfrage gegeben oder die Oktoberzahlung habe der Supportzusage entsprochen.

E4 — Die administrative Änderung

Fiktive Quelle: Abo-Prüfprotokoll von DEMO-SUB-009.

Kündigung durch einen Administrator umgesetzt: 2026-10-03, 09:20 Uhr UTC. Verknüpftes Supportgespräch: DEMO-SUPPORT-017.

Stützt: Die Systemänderung erfolgte nach der Verlängerung.

Belegt nicht: Dass der 3. Oktober der erste Kündigungswunsch oder der vereinbarte Wirksamkeitstag war. Der Eintrag zeigt die Bearbeitung, nicht die gesamte Vereinbarung.

E5 — Der Streitfalldatensatz

Fiktive Quelle: Fallnotiz DEMO-CASE-001 zur Zahlung DEMO-PAY-001.

Erfasst: 2026-10-05, 14:00 Uhr UTC. Kundenerklärung: vor Verlängerung gekündigt. Prüfstand: Antwort nicht eingereicht.

Damit ist der Einwand der geprüften Zahlung zugeordnet. Ein echtes Paket braucht zusätzlich tatsächlichen Anbieterstand, Antwortfrist, Zeitzone und berechtigten Verantwortlichen aus dem konkreten Fall, nicht aus diesem Lernbeispiel.

E6 — Prüfung der Geldbewegungen

Fiktive Quelle: Abgleichsnotiz vom 6. Oktober, 09:00 Uhr UTC.

Für DEMO-PAY-001 wurde keine separate Erstattung abgeschlossen. Die Kartenanfechtung befindet sich im Anbieterverfahren. Eine Zahlung außerhalb dieses Verfahrens wurde nicht freigegeben.

Dies ist ein Prüfzeitpunkt, keine Vorhersage des endgültigen Geldflusses. Prüfen Sie den aktuellen Anbieterstand vor einer echten Aktion erneut.

3. Die Feststellung mit entgegenstehenden Tatsachen

Vorgeschlagene interne Feststellung: Die Beispielunterlagen stützen die Kündigungsbeschwerde. E1 bestätigt den Einzug, E2 den Kontozugang. E3 enthält die konkrete Zusage, dass dieses Abo im Oktober nicht verlängert wird. E4 erklärt das Auseinanderfallen von Abrechnung und Zusage. Weder der Zahlungsbeleg noch der Rechnungsdownload lösen diesen Widerspruch zugunsten des Händlers auf.

Der Prüfer sollte keine Stellungnahme freigeben, die eine erfolgte Kündigung bestreitet. Der Fallverantwortliche folgt dem verfügbaren Anbieterverfahren zur Anerkennung der berechtigten Beschwerde und gleicht die daraus folgende Geldbewegung ab. Eine zusätzliche Erstattung ist nach Eröffnung des Streitfalls nicht automatisch die passende Aktion.

Das nützliche Ergebnis des Pakets ist eine besser belegte Entscheidung, auch wenn daraus keine Verteidigung entsteht. Der Kündigungsleitfaden erklärt die zugrunde liegende Untersuchung.

4. Was aufbewahrt und was eingereicht wird

Bewahren Sie das interne Paket mit Originalauszügen, Referenzen, Lücken, Entscheidung und Prüfversion auf. Im echten Fall braucht die nächste prüfende Person berechtigte Kopien, anhand derer sie die Aussagen nachvollziehen kann. Eine interne Datensatzkennung ist allein kein für die Bank lesbarer Anhang.

Stripe empfiehlt, relevante Unterlagen geordnet darzustellen und ihre Aussage zu erklären. Ist in einem anderen Fall eine Verteidigung begründet, bereiten Sie Anhänge und Erklärung für dessen konkreten Einwand vor. Der Antwortleitfaden enthält dafür ein getrenntes fiktives Beispiel zur behaupteten Nichtbereitstellung.

Stripes Antwortanweisungen beschreiben die Einreichung als endgültig; Banken sollen für Nachweise keinen externen Links folgen müssen. Fügen Sie die nötigen berechtigten Auszüge im akzeptierten Format ein. Artikel und PDF sind Lernmaterial, keine Belege zur Zahlung eines echten Kunden.

Für wen Evidenz gedacht ist und was verfügbar ist

Evidenz wird für B2B- und B2C-SaaS-Teams entwickelt, die Abo-Zahlungen über Abrechnung, Kontoaktivität und Support hinweg untersuchen. Der vorgesehene Ablauf führt diese Unterlagen in einer Kunden-Timeline zusammen und unterstützt KI-gestützte Entwürfe zur menschlichen Prüfung.

Öffentliche Website, Leitfäden und dieses fiktive Muster sind jetzt verfügbar. Öffentliche Selbstregistrierung und Preise sind noch nicht verfügbar. Das Muster demonstriert keine veröffentlichten Integrationen, automatische Anbietereinreichung oder abgeschlossene CE3.0-Eignungsprüfung.

Wenn Ihre schwierige Arbeit der fehlenden Verbindung zwischen E3 und E1 ähnelt, erklärt der SaaS-Produktartikel den vorgesehenen Ansatz. Sie können sich mit diesem Verfügbarkeitsstand für den frühen Zugang vormerken lassen.