Settlement Reports verbinden Bestellungen, Zahlungen, Gebühren, Erstattungen und tatsächliche Auszahlungen. Die operative Aufgabe besteht darin, jede Auszahlung so aufzuschlüsseln, dass ihre Bestandteile vollständig nachvollziehbar sind. Dafür braucht es keinen manuellen Abgleich jeder einzelnen Bestellung, sondern ein stabiles Datenmodell, eindeutige Referenzen und einen wiederholbaren Abstimmungsprozess.
Ein belastbarer Ablauf beantwortet für jeden Abrechnungszeitraum vier Fragen:
Ein Settlement Report ist die Abrechnung eines Zahlungsdienstleisters oder Marktplatzes für einen bestimmten Auszahlungslauf. Er enthält typischerweise mehrere Transaktionsarten, die gemeinsam den überwiesenen Nettobetrag ergeben.
Die grundlegende Abstimmungslogik lautet:
Verkäufe minus Erstattungen minus Gebühren plus oder minus Korrekturen und Einbehalte ergibt den Auszahlungsbetrag.
Ein vereinfachtes Zahlenbeispiel:
Wenn auf dem Bankkonto 113.000 Euro eingehen und alle Bestandteile eindeutig zugeordnet sind, ist der Auszahlungslauf rechnerisch geschlossen. Ist der Bankeingang korrekt, aber ein Teil der Gebühren oder Erstattungen nicht zuordenbar, bleibt der Lauf fachlich offen.
Für eine saubere Abstimmung reichen drei Datenebenen:
Optional kommen Gebührenrechnungen, Chargeback-Dateien oder separate Reserve-Reports hinzu. Entscheidend ist nicht die Anzahl der Dateien, sondern die gemeinsame Referenzlogik.
Mindestens folgende Felder sollten je Transaktion verfügbar sein:
Nicht jeder Anbieter verwendet dieselben Feldnamen. Deshalb sollte jedes Quellsystem einmal auf ein einheitliches internes Datenmodell abgebildet werden. Aus order_id, merchant_reference und shop_reference wird dann beispielsweise überall das Feld Bestellnummer.
Zuerst werden alle Settlement-Dateien des Abrechnungszeitraums importiert. Die Vollständigkeit lässt sich über fortlaufende Payout-IDs, Exportzeiträume und die Anzahl der Bankeingänge prüfen.
Ein häufiger Prozessfehler ist ein fehlender Auszahlungslauf zwischen zwei vorhandenen Dateien. Deshalb sollte der Import nicht nur Dateinamen prüfen, sondern auch den abgedeckten Zeitraum und die enthaltenen Payout-IDs.
Datumsformate, Dezimaltrennzeichen, Währungen und Vorzeichen müssen vereinheitlicht werden. Erstattungen können je nach Quelle als negativer Betrag oder als positiver Betrag mit dem Typ refund geliefert werden. Intern sollte nur eine Logik gelten.
Beispiel für eine Normalisierung:
sale wird als positiver Betrag geführt.refund wird als negativer Betrag geführt.fee wird als negativer Betrag geführt.reserve_release wird als positiver Betrag geführt.reserve_hold wird als negativer Betrag geführt.So lassen sich die Bestandteile unabhängig vom Dateiformat addieren.
Jeder Datensatz braucht einen eindeutigen Schlüssel. Geeignet ist häufig eine Kombination aus Anbieter, Transaktions-ID, Transaktionstyp und Ereigniszeitpunkt.
Eine reine Bestellnummer reicht nicht aus. Zu einer Bestellung können Verkauf, Teil-Erstattung, zweite Erstattung und Gebühr als separate Bewegungen existieren. Werden Dateien erneut importiert, muss das System bestehende Schlüssel erkennen und den doppelten Import blockieren.
Anschließend werden alle Bewegungen je Payout-ID gruppiert. Die Summe der Nettobeträge muss dem im Report ausgewiesenen Auszahlungsbetrag entsprechen.
Die erste Kontrollstufe prüft damit die Datei gegen sich selbst:
Summe aller Transaktionen je Payout-ID = ausgewiesener Payout-Betrag
Schon hier sichtbare Differenzen deuten meist auf Filterfehler, ausgelassene Transaktionstypen, falsche Vorzeichen oder abgeschnittene Exporte hin.
Danach wird der errechnete Payout-Betrag dem passenden Bankeingang zugeordnet. Idealerweise enthält der Verwendungszweck die Payout-ID. Fehlt sie, kann über Betrag, Währung und ein definiertes Datumsfenster zugeordnet werden.
Betragsgleichheit allein ist kein sicherer Schlüssel. Zwei Auszahlungen können denselben Betrag haben. Deshalb sollte eine automatische Zuordnung mindestens zwei unabhängige Merkmale verwenden, etwa Betrag plus Payout-ID oder Betrag plus Anbieter und Auszahlungsdatum.
Nun werden Settlement-Bewegungen mit den operativen Bestelldaten verbunden. Ziel ist nicht zwingend eine Eins-zu-eins-Beziehung. Eine Bestellung kann mehrere Zahlungsbewegungen enthalten, während eine Auszahlung viele Bestellungen bündelt.
Der Abgleich sollte deshalb auf Transaktionsebene erfolgen und folgende Zustände unterscheiden:
Diese Statuswerte machen offene Punkte sichtbar, ohne den gesamten Lauf zu blockieren.
Gebühren sollten nicht als unerklärte Differenz zwischen Verkauf und Auszahlung stehen bleiben. Sie werden nach Transaktionstyp, Anbieter und Zeitraum aggregiert.
Eine sinnvolle operative Auswertung zeigt beispielsweise:
Die Gebührenquote dient als Plausibilitätswert, nicht als Ersatz für die Einzelabstimmung. Ein ungewöhnlicher Ausschlag kann auf eine geänderte Gebührenstruktur, einen unvollständigen Export oder eine falsche Klassifizierung hinweisen.
Abweichungen gehören nicht in lose Nachrichten oder persönliche Tabellen. Jede Abweichung sollte als eigener Vorgang mit klaren Feldern erfasst werden:
Geeignete Fehlerkategorien sind etwa fehlende Datei, kein Banktreffer, unbekannter Transaktionstyp, Duplikat, fehlende Bestellreferenz und Betragsabweichung.
Ein Auszahlungslauf ist geschlossen, wenn die Settlement-Summe zum Bankeingang passt, alle wesentlichen Bewegungen klassifiziert sind und verbleibende Abweichungen dokumentiert wurden.
Für den Abschluss sollten mindestens gespeichert werden:
Damit bleibt der Prozess auch bei Personalwechsel oder einer späteren Rückfrage reproduzierbar.
Automatisierung lohnt sich besonders bei wiederkehrenden Prüfungen mit klaren Regeln. Dazu gehören:
Die Automatisierung sollte keine Differenzen verstecken. Kleine Restbeträge automatisch auszubuchen, nur damit ein Lauf als abgeschlossen erscheint, verschlechtert die Datenqualität. Besser ist eine transparente Toleranzlogik mit eigener Kennzeichnung und nachvollziehbarer Freigabe.
Vier Kennzahlen reichen für die operative Steuerung meist aus:
Ergänzend kann die Zahl unbekannter Transaktionstypen gemessen werden. Steigt sie nach einer Systemänderung, muss das Mapping aktualisiert werden.
Der beschriebene Prozess passt nicht, wenn nur wenige Zahlungen pro Monat direkt per Banküberweisung eingehen und keine gebündelten Auszahlungen, Gebührenabzüge oder Korrekturen entstehen. In diesem Fall wäre ein eigenes Settlement-Modell unnötig komplex.
Er passt ebenfalls nicht unverändert, wenn die Quelldaten keine stabilen Transaktions- oder Payout-Referenzen enthalten. Dann muss zuerst die Datenbereitstellung verbessert werden. Ohne eindeutige Schlüssel kann auch ein technisch sauberer Import keine verlässliche Zuordnung herstellen.
Bei sehr vielen Plattformen, mehreren Währungen und stark unterschiedlichen Dateiformaten sollte der Ablauf nicht dauerhaft in manuellen Tabellen betrieben werden. Dann wird die Tabelle schnell selbst zur Fehlerquelle. Das Prozessmodell bleibt sinnvoll, sollte aber in einer zentralen Datenpipeline oder einem dafür geeigneten System umgesetzt werden.
Settlement Reports lassen sich zuverlässig abstimmen, wenn jede Auszahlung als geschlossener Datenfluss behandelt wird: Quelldaten einsammeln, normalisieren, gegen Duplikate sichern, je Payout summieren, mit dem Bankeingang verbinden und Abweichungen strukturiert klären. Der größte Hebel liegt in eindeutigen Referenzen und einem einheitlichen Transaktionsmodell.
SPIELMANN kann E-Commerce-Teams dabei unterstützen, diesen operativen Abstimmungsprozess sauber zu strukturieren und in bestehende Datenabläufe einzubetten.
Dieser Artikel wurde mit KI-Unterstützung erstellt und redaktionell geprüft.