# Digitale Leistung nicht erhalten: passende Nachweise auswählen

[Von Evidenz](https://evidenz.dev/de)  4 Minuten Lesezeit

Bei einem Streit über eine digitale Leistung zählt, was gekauft wurde und ob diese Leistung das richtige Konto im abgerechneten Zeitraum erreichte. Anmeldung, abgeschlossener Hintergrundauftrag und abrufbares Ergebnis belegen unterschiedliche Dinge. Diese Unterschiede gehören in die Prüfung.

## Was bedeutete „geliefert“ bei diesem Kauf?

Ein SaaS-Abonnement kann eine kostenpflichtige Funktion, einen erzeugten Bericht, einen Firmen-Workspace oder eine bestimmte Menge API-Aufrufe umfassen. Beginnen Sie mit dem gekauften Tarif und der damaligen Beschreibung. Welche Unterlagen könnten zeigen, dass genau dieses Versprechen erfüllt wurde?

Die Bereitstellung eines Kontos kann einen Schritt erklären. Sie zeigt noch nicht, dass der bezahlte Export funktionierte. Auch verbrauchte Credits beweisen kein nutzbares Ergebnis, wenn der Vorgang nach dem Abzug scheiterte.

[Stripe nennt für nicht erhaltene digitale Produkte unter anderem Zugriffs- und Nutzungsprotokolle mit Bezug zum Kunden.](https://docs.stripe.com/disputes/categories) Entscheidend ist die Verbindung zwischen Behauptung, Kauf und relevantem Ereignis. Möglichst viele Protokolle zusammenzutragen ist kein Ersatz dafür.

## Den Weg vom Kauf zum nutzbaren Ergebnis prüfen

Rekonstruieren Sie die Schritte, die Ihre Leistung voraussetzte. Eine Prüfung kann Zahlung, Kontobereitstellung, Rechtevergabe, Nutzungsversuch, abgeschlossene Arbeit und Zugriff auf das Ergebnis umfassen. Je nach Produkt sieht dieser Ablauf anders aus.

Was Unterlagen zu digitalen Leistungen zeigen können

| Unterlage | Nützliche Aussage | Wichtige Grenze |
| --- | --- | --- |
| Konto bereitgestellt | Das System hat ein Konto oder eine Berechtigung angelegt. | Anmeldung oder Zugriff auf die bezahlte Funktion könnten trotzdem gescheitert sein. |
| Authentifizierte Sitzung | Eine Sitzung griff zu einem bestimmten Zeitpunkt auf das Konto zu. | Sie könnte zu einem Kollegen, Administrator oder kompromittierten Konto gehören. |
| Auftrag abgeschlossen | Der Dienst hat eine bestimmte Aufgabe beendet. | Ein geplanter Auftrag oder interner Test ist nicht automatisch Kundenaktivität. |
| Download oder Ergebnisabruf | Ein bestimmtes Konto hat das relevante Ergebnis angefordert. | War der Abruf erfolgreich und lieferte er die richtige Ausgabe? |
| Fehler oder Support-Vorgang | Ein Hindernis ist dokumentiert. | Ein späterer Erfolg beseitigt den früheren Ausfall nicht rückwirkend. |

Nutzen Sie die tatsächliche Bedeutung Ihrer Ereignisse. Wird „Bericht angesehen“ schon beim Öffnen einer leeren Seite ausgelöst, beschreiben Sie genau dieses Verhalten. Stellen Sie es nicht als Beleg dar, dass jemand den Bericht gelesen hat. Bei unklarer Instrumentierung hilft die Rückfrage an das zuständige Produkt- oder Entwicklungsteam.

## Aktivität der Zahlung und dem Zeitraum zuordnen

Verbinden Sie Unterlagen über stabile Konto- und Abrechnungskennungen. Prüfen Sie Mitgliedschaft, Arbeitsbereich und Tarifumfang. Wer zwischen mehreren Konten wechseln kann, könnte einen Download im kostenlosen Arbeitsbereich ausgeführt haben. Damit ist die Lieferung einer bezahlten Teamfunktion noch nicht belegt.

Halten Sie den abgerechneten Zeitraum sichtbar. Ein Konto kann im Vormonat funktioniert haben und unmittelbar nach der Verlängerung ausfallen. Frühere Nutzung liefert Hintergrund; sie klärt nicht allein die Lieferung im beanstandeten Monat.

Notieren Sie außerdem, wer oder was eine Aktion ausgelöst hat. Trennen Sie Kundensitzungen von Support-Zugriffen, Überwachung, Importen, geplanten Integrationen und Wiederholungsversuchen. Sonst erscheint die eigene Fehlersuche des Unternehmens als Nutzung durch den Kunden.

Nutzen Sie diese Schritte als Prüfmethode. Die geltenden Anforderungen an Nachweise ergeben sich weiterhin aus den Vorgaben Ihres Zahlungsdienstleisters und dem Reklamationsgrund.

## Ein Auftrag kann fertig sein, während das Ergebnis unerreichbar bleibt

**Fiktives Beispiel.** Ein Kunde bezahlt 80 € für ein SaaS-Abonnement mit dem Export eines Rechercheberichts. Im Worker-Protokoll steht um 14:02 UTC „abgeschlossen“. Der anschließende Download um 14:04 wird wegen fehlender Berechtigung abgewiesen. Um 14:20 kann der Support den Fehler nachvollziehen.

Eine Stellungnahme mit ausschließlich dem erfolgreichen Hintergrundauftrag würde das Zugriffsproblem auslassen. Die Behauptung, die Leistung nicht erhalten zu haben, passt zum fehlgeschlagenen Abruf, obwohl die Berechnung ausgeführt wurde.

Das interne Ergebnis sollte beide Tatsachen benennen: Der Dienst erzeugte einen Bericht, aber der Kunde konnte ihn über den gekauften Ablauf nicht abrufen. Prüfen Sie, ob der Fehler behoben wurde, ab wann nutzbarer Zugang bestand und was der Support zusagte. Diese Punkte helfen bei der Entscheidung. Das Wort „abgeschlossen“ entscheidet sie nicht.

Zeigen die Unterlagen stattdessen den erfolgreichen Download des richtigen Berichts und eine anschließende Nachricht über dessen Inhalt, spricht das für einen anderen Ablauf. Prüfen Sie dennoch den Bezug zum beanstandeten Kauf und halten Sie auch Beschwerden über unvollständige oder unbrauchbare Ergebnisse fest.

Funktionierte der Zugang, fehlte aber eine zugesagte Fähigkeit, prüfen Sie, [ob die SaaS-Leistung der Beschreibung entsprach](https://evidenz.dev/de/articles/saas-service-not-as-described). Der Zugriff auf das Konto beantwortet keine Beschwerde über die bereitgestellte Funktion.

## Den tatsächlichen Streitgrund beantworten

Lieferung und Zahlungsautorisierung sind unterschiedliche Fragen. Ein Berichtdownload kann bei „Ich habe die Leistung nicht erhalten“ relevant sein. Er beantwortet nicht automatisch „Ich habe die Zahlung nicht autorisiert“ oder „Ich hatte vor der Verlängerung gekündigt“.

[Stripe unterscheidet Streitkategorien mit unterschiedlichen Nachweisanforderungen.](https://docs.stripe.com/disputes/categories) Lesen Sie den konkreten Fall und die Erklärung des Kunden, bevor Sie Unterlagen auswählen. Geht es um die Qualität, sollte die Antwort nicht stillschweigend daraus eine Zugangsfrage machen, nur weil die Zugriffsprotokolle günstiger aussehen.

[Shopify nennt Zugriffs- und Nutzungsprotokolle als mögliche zusätzliche Nachweise für digitale Produkte und Leistungen.](https://help.shopify.com/en/manual/payments/chargebacks/chargeback-process) Erläutern Sie den Bezug zum Kauf und stellen Sie die Unterlagen so bereit, dass ein externer Prüfer sie verstehen kann.

## Technische Ereignisse verständlich erklären

Beschreiben Sie die gekaufte Leistung kurz und stellen Sie die relevanten Ereignisse mit Datum dar. Erklären Sie die Bedeutung jedes ausgewählten Eintrags und fügen Sie den Nachweis selbst bei. Unkommentiertes JSON, interne Dashboard-Links oder unbelegte Aussagen über die Absicht des Kunden erschweren die Prüfung.

[Stripe empfiehlt knappe, relevante Nachweise und lesbare Anhänge.](https://docs.stripe.com/disputes/best-practices) Lassen Sie die Unterlagen vor dem Einreichen von jemandem außerhalb des Entwicklungsteams lesen. Kaufversprechen, geliefertes Ergebnis und offene Einschränkungen sollten ohne Kenntnis Ihrer internen Ereignisnamen verständlich sein.

Bewahren Sie die umfassendere Untersuchung getrennt auf. Sie kann einen Ausfall, eine fehlerhafte Berechtigung oder eine Lücke in der Protokollierung erklären, die auch nach dem Streit behoben werden sollte. Der [Leitfaden zum Kundenverlauf](https://evidenz.dev/de/articles/customer-activity-timeline) behandelt Quellen und Unsicherheit; der [Nachweisleitfaden](https://evidenz.dev/de/articles/chargeback-evidence) die Auswahl für die Stellungnahme.

Für B2B- und B2C-SaaS-Teams ist Evidenz darauf ausgerichtet, die gekaufte Leistung zum Mittelpunkt der Prüfung zu machen. Der Kundenverlaufsansatz verbindet Zahlung und Konto mit den zugehörigen Berechtigungsänderungen, Zugriffsversuchen, nutzbaren Ergebnissen und Supportgesprächen. Support und Finanzteam brauchen eine Erklärung, die sie gemeinsam prüfen können, ohne jedes technische Ereignis als Lieferung zu werten. Im Berichtsbeispiel gehört deshalb der fehlgeschlagene Download neben den abgeschlossenen Auftrag. Die Entscheidung kann dann einen tatsächlichen Zugangsfehler anerkennen oder die bestätigte Bereitstellung anhand der Unterlagen erklären, die wirklich zur beanstandeten Leistung gehören.

## Quellen und Einordnung

Quellenstand Oktober 2026

Veröffentlicht von Evidenz. Die Beispiele erläutern den Prüfablauf. Prüfen Sie aktuelle Vorgaben und den konkreten Fall in den verlinkten Quellen.

- [Stripe: Dispute reason code categories](https://docs.stripe.com/disputes/categories)
- [Stripe: Dispute evidence best practices](https://docs.stripe.com/disputes/best-practices)
- [Shopify: Responding to chargebacks and inquiries](https://help.shopify.com/en/manual/payments/chargebacks/chargeback-process)

Kundenkontext ist unser Ausgangspunkt.

Evidenz wird für B2B- und B2C-SaaS entwickelt: eine gemeinsame Kundenhistorie aus Abo-Abrechnung, Konten, Support und digitaler Produktnutzung. Melden Sie sich für Neuigkeiten zum frühen Zugang an.

[Zur Warteliste](https://evidenz.dev/de#hero)

## Weiterlesen

[4 Minuten Lesezeit

### 3D Secure und Chargebacks: Was die Authentifizierung tatsächlich belegt](https://evidenz.dev/de/articles/three-d-secure-and-disputes)[5 Minuten Lesezeit

### Chargeback-Nachweise für Unternehmen mit Abonnements](https://evidenz.dev/de/articles/chargeback-evidence)[4 Minuten Lesezeit

### Eine Kunden-Timeline für die Prüfung von Zahlungsanfechtungen aufbauen](https://evidenz.dev/de/articles/customer-activity-timeline)

Canonical page: https://evidenz.dev/de/articles/digital-service-not-received