Accounting-Workflow für Stripe Connect Marktplätze

Die meisten Buchhaltungsprobleme bei Marktplätzen lassen sich auf einen einzigen Fehler zurückführen: Die Stripe-Auszahlung (Payout) wird als Umsatz gebucht. Die Auszahlung ist lediglich der Nettosaldo aus Dutzenden separaten wirtschaftlichen Vorgängen. Wenn man sie als einzige Umsatzzeile verbucht, unterschlägt man die Provision der Plattform, die Verbindlichkeit gegenüber dem Verkäufer sowie sämtliche darin enthaltenen Gebühren und Dispute. Ein korrekter Workflow zerlegt die Auszahlung in ihre Bestandteile, bevor sie das Hauptbuch berührt.

Dieser Leitfaden verfolgt jede Kategorie von Stripe Connect Balance-Transaktionen zu ihrem korrekten buchhalterischen Ziel: Forderungen, Provisionserlöse, Verbindlichkeiten gegenüber Verkäufern, Zahlungsabwicklungsaufwand und Interimskonten (Suspense). Er nutzt die dokumentierten Import- und Settlement-Endpunkte von Nordlet als Buchungsmechanismus, enthält ein durchgerechnetes Settlement-Beispiel und endet mit einer Checkliste für die Abstimmung (Reconciliation), die Sie vor jedem Monatsabschluss durchgehen können.

Klären Sie das Connect-Zahlungsmodell, bevor Sie Prozesse entwerfen

Buchungsregeln können erst definiert werden, wenn Sie wissen, welches Zahlungsmodell (Charge Model) jeder Zahlungsfluss verwendet. Das Modell bestimmt, auf welchem Stripe-Guthaben die Zahlung (Charge) verbucht wird, wer die Gebühren trägt und wo Rückerstattungen (Refunds) und Dispute zuerst einschlagen.

Connect-Modell	Zahlung (Charge) erstellt auf	Trägt Stripe-Gebühren	Rückerstattungen/Dispute mindern	Buchhalterische Konsequenz
Direct Charges	Verknüpftem Konto (Connected Account)	Je nach Partei konfigurierbar	Guthaben des verknüpften Kontos	Die Plattform verbucht ihre Application Fee als Umsatz; die Zahlungsaktivitäten des Verkäufers finden hauptsächlich in dessen eigenem Hauptbuch statt
Destination Charges	Plattform, mit sofortigem Transfer an ein verknüpftes Konto	Plattform	Plattform	Die Plattform verbucht die Kundenforderung und die Stripe-Gebühr; der Anteil des Verkäufers ist eine Verbindlichkeit, kein Umsatz
Separate Charges and Transfers	Plattform-Zahlung, gefolgt von einem oder mehreren separaten Transfers	Plattform	Plattform	Zahlung und Verkäufer-Transfers sind separate Ereignisse; die Verbindlichkeit gegenüber dem Verkäufer wird unabhängig von der Kundenforderung erfasst

Der Stripe-eigene Leitfaden zu wie Charges in einer Connect-Integration funktionieren bestätigt, dass bei Destination Charges und Separate Charges and Transfers das Plattform-Guthaben die Zahlungsgebühren, Rückerstattungen und Chargebacks (Rückbuchungen) trägt. Bei Direct Charges erhält das verknüpfte Konto die Zahlung, und Gebühren können beiden Parteien belastet werden.

Die praktische Grundregel: Sagen Sie nicht „die Stripe-Auszahlung ist der Verkäuferumsatz“ oder „der Verkäufer zahlt die Gebühren“, solange Sie nicht das Charge-Modell für jeden Zahlungsfluss dokumentiert haben. Speichern Sie dieses Modell zu jeder Transaktion. Das Mischen von Direct und Destination Charges unter einer einzigen Buchungsregel ist der schnellste Weg, um sowohl Umsätze als auch Verbindlichkeiten falsch auszuweisen.

Dieser Leitfaden geht von Destination Charges oder Separate Charges and Transfers aus, da in diesen Fällen das Plattform-Guthaben die buchhalterische Hauptlast trägt und hier die meisten Marktplatz-Hauptbücher (Ledger) ansetzen.

Bilden Sie den Geldfluss ab, bevor Sie auch nur eine einzige Zeile importieren

Bevor Sie sich mit dem Import befassen, skizzieren Sie für jeden Zahlungsfluss den Ablauf auf einer Seite:

Customer payment
  -> Stripe charge / payment balance transaction
  -> Stripe fee
  -> platform application fee (commission)
  -> transfer to connected account
  -> refund or dispute (if applicable)
  -> Stripe payout
  -> bank receipt

Jeder Pfeil ist eine eigene Guthaben-Transaktion (Balance Transaction) mit eigener ID, Kategorie, Betrag und Datum. Behandeln Sie das Stripe-Guthaben wie ein bankähnliches Verrechnungskonto (Clearing Account): Zahlungen fließen ein, Gebühren und Transfers fließen ab, und die Auszahlung (Payout) überweist den Restbetrag auf das eigentliche Bankkonto. Die Nordlet Dokumentation zum Bank- und Zahlungsimport empfiehlt genau diese Vorgehensweise für reguläre Stripe-Aktivitäten.

Wählen Sie den richtigen Stripe-Quellbericht

Verwenden Sie für Settlement-Batches mit automatischen Auszahlungen den Bericht Payout reconciliation, itemized von Stripe. Er liefert eine Zeile pro Transaktion, gruppiert Zeilen nach reporting_category, verknüpft jede mit einer automatic_payout_id und liefert Brutto-, Gebühren- und Nettosummen. Der Stripe Leitfaden zur Berichtsauswahl dokumentiert diesen Bericht und bestätigt charge_id, connected_account_id und destination_payment_id als verfügbare Connect-Felder.

Falls automatische Auszahlungen nicht aktiviert sind (wie bei einigen manuellen Auszahlungsvereinbarungen), verwenden Sie stattdessen den Balance-Bericht. Betrachten Sie eine Auszahlungsübersicht im Dashboard niemals als ausreichenden Buchungsbeleg. Die Übersicht belegt nur die Gesamtsumme des Batches; erst der detaillierte Bericht schlüsselt die Bestandteile auf.

Stripe empfiehlt die Klassifizierung nach reporting_category statt nach dem älteren Feld type. Zudem enthält jede Zeile eine source-ID, die mit dem zugrunde liegenden Objekt verknüpft ist. Beachten Sie die zeitliche Einschränkung: Laut Stripe sind die täglichen Berichtsdaten in der Regel am folgenden Tag bis 12 Uhr mittags (Ortszeit) verfügbar. Sofortauszahlungen (Instant Payouts) lassen sich nicht sauber einzelnen Transaktionen zuordnen und erfordern daher eine separate Abstimmung anhand der Transaktionshistorie.

Klassifizieren Sie jede Balance-Transaktion nach Kategorie

Nutzen Sie reporting_category als primäres Klassifizierungsmerkmal und prüfen Sie dann source_id, charge_id sowie die Beschreibungen. Das entscheidende Mapping lautet:

Stripe-Aktivität	Reporting Category	Buchhalterische Auslegung
Kundenabbuchung, Kreditkarte oder lokale Zahlungsmethode	charge	Vom Kunden bezahlte Forderung oder Umsatzabrechnung
Rückerstattung (Refund)	refund	Stornierung der ursprünglichen Kundenzahlung
Von Stripe einbehaltene Bearbeitungsgebühr	fee	Aufwand für den Zahlungsverkehr (Nebenkosten des Geldverkehrs)
Application Fee der Plattform	platform_earning	Provisionserlöse
Rückerstattete Application Fee	platform_earning_refund	Minderung der Provisionserlöse
Transfer auf ein verknüpftes Konto	transfer	Minderung der Verbindlichkeit gegenüber dem Verkäufer
Stornierter Transfer	transfer_reversal	Rückforderung vom verknüpften Konto
Chargeback (Rücklastschrift/Disput)	dispute	Chargeback-Verlust; prüfen Sie das Quell-Disput-Objekt
Chargeback gewonnen oder storniert	dispute_reversal	Rückbuchung eines zuvor verbuchten Chargebacks
Auszahlung auf das Bankkonto	payout	Kontobewegung (Geldtransit), kein Umsatz
Stornierte Auszahlung	payout_reversal	Gelder fließen in das Stripe-Guthaben zurück
Einbehaltene Rücklage (Reserve)	connect_reserved_funds / risk_reserved_funds	Zweckgebundene Mittel, standardmäßig kein Aufwand
Einzug eines längerfristig negativen Saldos	connect_collection_transfer	Finanzierungs- oder Rückforderungsereignis, das eine Risikopolicy erfordert

Vorsicht bei der Terminologie: Das ältere Balance-Transaction-Feld type verwendet andere Bezeichnungen für dieselben Ereignisse, darunter payment, application_fee und adjustment. Die Stripe Dokumentation zu den Typen von Guthabentransaktionen listet beide Vokabulare auf. Mischen Sie niemals einen type-Wert in eine Regel für die reporting_category und erfinden Sie keine Kategorien wie dispute_loss, die Stripe gar nicht exportiert. Wenn ein Export eine Bezeichnung enthält, die Sie nicht erkennen, behalten Sie den exportierten Wert bei und überprüfen Sie ihn anhand des Quellobjekts.

Buchen Sie die normalen Marktplatz-Aktivitäten im Hauptbuch

Für eine Plattform, die Destination Charges oder Separate Charges and Transfers nutzt, sehen die konzeptionellen Buchungssätze wie folgt aus.

Kundenabbuchung (Kundengelder gehen auf dem Stripe-Verrechnungskonto ein):

Dr Stripe clearing        Gross customer charge
    Cr Trade receivables   Gross customer charge

Stripe-Bearbeitungsgebühr:

Dr Stripe fee expense      Stripe fee
    Cr Stripe clearing     Stripe fee

Saldieren (Netting) Sie die Stripe-Gebühr nicht mit dem Umsatz, es sei denn, Ihre Rechnungslegungsrichtlinie fordert und unterstützt die Nettoausweisung ausdrücklich.

Plattformprovision (Ihr Umsatz, herausgelöst aus dem Betrag, der ansonsten dem Verkäufer zustehen würde):

Dr Seller payable          Commission amount
    Cr Commission revenue   Commission amount

Verkäufer-Transfer (Begleichung einer Schuld, kein Aufwand):

Dr Seller payable          Transfer amount
    Cr Stripe clearing      Transfer amount

Ein Transfer ist niemals automatisch ein Aufwand. Der Anteil des Verkäufers wird zum Zeitpunkt der Abbuchung zu einer Verbindlichkeit, und der Transfer begleicht diese Verbindlichkeit. Die Settlement-Buchungsregeln von Nordlet folgen diesem Prinzip: platform_earning-Zeilen werden als Provisionserlöse gebucht, während transfer-Zeilen die Verbindlichkeiten gegenüber dem Verkäufer mindern. Die dokumentierten Standard-Buchungsschlüssel sind settlements.commissionRevenue (Standard 5001), settlements.sellerPayable (Standard 4499), settlements.fees (Standard 6800) und settlements.suspense (Standard 4440). Diese können pro Unternehmen über die Buchungsregeln in der Nordlet API überschrieben werden.

Behandeln Sie Rückerstattungen im Bezug zum ursprünglichen Verkauf, nicht als lose Bankposten

Eine Rückerstattung (Refund) ist mit der ursprünglichen Zahlung oder Rechnung verknüpft. Konzeptionell:

Dr Refunds / sales reversals    Refund amount
    Cr Trade receivables         Refund amount

Der tatsächliche Buchungssatz hängt davon ab, ob der Verkauf bereits erfasst wurde, ob Steuern storniert werden müssen und ob eine Application Fee der Plattform zurückerstattet wurde. Ein einziger Refund kann zu einer Stornierung der Forderung, einer Steuerkorrektur, einer Rückerstattung der Application Fee, einer Transferstornierung oder der Minderung einer Verbindlichkeit gegenüber dem Verkäufer führen. Auch die Auswirkungen auf die Stripe-Gebühren müssen geprüft und dürfen nicht einfach nur angenommen werden.

Die Zeitfalle: Eine Rückerstattung wird oft in einem späteren Payout abgerechnet als die ursprüngliche Zahlung. Ziehen Sie den detaillierten Auszahlungs-Abstimmungsbericht (itemized payout-reconciliation report) einem synthetischen Refund aus einem Zahlungs-Export (Charge-Level Export) vor. Die Dokumentation von Nordlet warnt ausdrücklich davor, dass ein aus einem Payments-Export generierter Refund nur eine Annäherung ist, wenn die Rückerstattung erst später abgerechnet wird. Der Settlement-Importer kann die Refund-Zeile einlesen, sie dem ursprünglichen Verkauf zuordnen und die Forderung bei der Verbuchung des Batches stornieren.

Behandeln Sie Dispute getrennt von Rückerstattungen

Ein Disput ist eine Reklamation des Karteninhabers oder der ausgebenden Bank, und Stripe kann sowohl den strittigen Betrag als auch eine Disputgebühr belasten, noch bevor eine Klärung erfolgt. Bei Destination Charges sowie Separate Charges and Transfers belastet Stripe gemäß den Richtlinien für Rückerstattungen und Dispute in beiden Fällen das Plattform-Guthaben. Die Plattform kann eine Rückforderung versuchen, indem sie den Transfer an den Verkäufer storniert.

Ein verlorener Disput aus Sicht der Plattform:

Dr Chargeback loss / receivable reopened   Disputed amount
Dr Dispute-fee expense                      Dispute fee
    Cr Stripe clearing                      Combined amount

Wenn der Verkäufer den Verlust trägt und die Rückforderung bestätigt ist:

Dr Seller payable / recovery account   Recoverable amount
    Cr Chargeback recovery              Recoverable amount

Buchen Sie die Rückforderung beim Verkäufer nicht allein deshalb, weil eine Transferstornierung angefordert wurde. Verifizieren Sie, dass die Stornierung erstellt wurde, erfolgreich war und im Stripe-Guthaben aufscheint. Wenn der Disput gewonnen wird, gibt Stripe den umstrittenen Betrag über eine dispute_reversal-Zeile zurück. Stornieren Sie den Chargeback-Verlust und behandeln Sie eventuelle von Stripe nicht zurückerstattete Disputgebühren separat. Nordlet ordnet Chargeback-Zeilen anhand der charge_id einer zuvor abgeglichenen Zahlung zu – entweder aus derselben Datei oder aus einem früheren Import.

Ein durchgerechnetes Settlement-Beispiel

Nehmen wir einen automatischen Payout-Batch. Der detaillierte Bericht enthält:

• Eine charge-Zeile: brutto 100.00, Stripe-Gebühr 3.20, netto 96.80
• Eine platform_earning-Zeile: 15.00, die Provision der Plattform
• Eine transfer-Zeile: 81.80 an den verknüpften Verkäufer
• Eine refund-Zeile aus einem früheren Verkauf: brutto 20.00, abgerechnet in diesem Batch
• Eine payout-Zeile: die Gesamtsumme des Batches, die auf das Bankkonto fließt

Die Zusammensetzung des Payouts, folgend der Settlement-Identität von Stripe:

Gross charges                100.00
- refunds                     20.00
- Stripe fees                  3.20
- transfers                   81.80
= net to platform balance     -5.00

Die platform_earning-Zeile bewegt das Geld nicht ein zweites Mal. Sie beziffert lediglich die 15.00, die nach Abzug der Gebühr und des Verkäufer-Transfers auf dem Plattform-Guthaben verbleiben. So kann die Plattform Provisionserlöse direkt verbuchen, statt sie nur abzuleiten.

In diesem Fall übersteigen der Verkäufer-Transfer zuzüglich des Refunds die Nettoeinnahmen aus Zahlungen. Der Batch schließt also leicht negativ ab und reduziert das nächste Payout oder zehrt das Guthaben auf. Der verbuchte Journalbeleg storniert die zurückerstattete Forderung, erfasst 15.00 an Provisionserlösen, verbucht 3.20 an Gebührenaufwand, mindert die Verbindlichkeit gegenüber dem Verkäufer um den Transfer und verbucht die Stornierung des Refunds. Die Bankzeile stimmt exakt mit dem Nettobetrag überein, der auf dem Konto eingeht. Keine einzelne Zahl entspricht hier dem „Umsatz“ – und genau das ist der Punkt.

Import und Verbuchung über den Nordlet Settlement-Endpunkt

Für die Abstimmung auf Payout-Ebene nutzen Sie:

POST /v1/bank/settlements/import

mit dem Provider Stripe und der detaillierten (itemized) CSV-Datei. Nordlet gruppiert die Zeilen nach automatic_payout_id, wandelt jedes Payout in einen Settlement-Batch mit Brutto-, Gebühren- und Nettosummen um, überspringt Neuimporte eines bereits verbuchten Payouts, schließt payout-Zeilen aus der Settlement-Zusammensetzung aus und ordnet Zahlungs-, Refund- und Disput-Zeilen mithilfe von Bestell-, Rechnungs-, PaymentIntent-, Charge-, Source- oder Metadaten-Referenzen automatisch zu. Da Stripe den detaillierten Bericht in eine Datei pro Abschnitt aufteilt, sollten Sie die Dateien für Charges, Refunds und Gebühren zusammen importieren: Zeilen, die zu einem bereits importierten, aber noch nicht verbuchten Payout gehören, fließen in den bestehenden Batch ein. Dies ist ein dokumenten- und API-gesteuerter Import-und-Buchungs-Workflow (Import-and-Post), kein Live-Konnektor zu Stripe. Die Features-Seite listet auf, was der Bank- und Settlement-Bereich alles abdeckt.

Führen Sie den Abgleich in dieser Reihenfolge durch: Zahlungen zu Rechnungen, Rückerstattungen zu den ursprünglichen Zahlungen, Dispute zu den ursprünglichen Zahlungen, Provisionszeilen zu Provisionsbuchungen. Halten Sie Stripe-Gebühren, Adjustments, Rücklagen und Payout-Zeilen aus dem Rechnungsabgleich heraus. Das Nordlet Glossar zur Zahlungsabstimmung hält fest, dass Gebühren- und Anpassungszeilen per Design nicht mit Rechnungen abgeglichen werden können; leiten Sie offene geldbewegende Posten stattdessen auf ein Interimskonto (Suspense) um. Manuelle Korrekturen erfolgen über bank/settlements/match { lineId, invoiceId }, wobei null als invoiceId die Zuordnung aufhebt.

Verbuchung eines ausgeglichenen Batches:

POST /v1/bank/settlements/post

Dies erzeugt einen ausgeglichenen Journalbeleg, gleicht die gematchten Rechnungen aus, belastet das Hauptbuchkonto der Bank mit dem Netto-Payout, bucht die Gebühren in den Aufwand, entlastet die Forderungen um die Zahlungen, storniert Forderungen bei Rückerstattungen und Chargebacks, teilt nicht zugeordnete Marktplatzzahlungen (Marketplace Charges) zwischen Provisionserlösen und Verbindlichkeiten gegenüber Verkäufern auf (sofern commissionPercent angegeben ist) und bucht ungeklärte Beträge auf ein Interimskonto (Suspense). Auch alle Kategorien, die das System nicht erkennt, landen auf dem Interimskonto; die API-Antwort listet diese Kategorien in einer Warnung explizit auf, anstatt sie unbemerkt zu schlucken.

Checkliste für die Abstimmung (Reconciliation)

Führen Sie vor jedem Monatsabschluss diese Prüfungen durch:

• Keine doppelte balance_transaction_id
• Kein doppelter (provider, payout_id) Settlement-Batch
• Die Summe der Zeilen-Nettobeträge (net) entspricht dem Batch-Netto
• Das Batch-Netto entspricht dem Bank-Payout (vorbehaltlich zeitlicher Verschiebungen und Währungsrichtlinien)
• Jeder Refund verweist auf eine ursprüngliche Zahlung oder eine protokollierte Ausnahme
• Jeder Disput verweist auf eine Disput- oder Zahlungsreferenz
• Jeder Transfer verfügt über eine ID für das verknüpfte Konto (Connected Account)
• Für jede platform_earning-Zeile ist die korrekte Verbuchung der Provision definiert
• Der Saldo des Interimskontos (Suspense) ist null oder wurde vollständig geprüft – einschließlich aller unerkannten Kategorien, die in der Buchungswarnung genannt werden
• Die Verbindlichkeiten gegenüber dem Verkäufer (Seller Payable) sind nicht negativ, es sei denn, es liegt eine genehmigte Vorschuss- oder Rückforderungsvereinbarung vor
• Bereits verbuchte Batches können nicht unbemerkt neu importiert oder erneut verbucht werden
• Ein Payout in einer anderen Währung als der Basiswährung des Unternehmens wird zum Kurs des Auszahlungstages umgerechnet; die Differenz zum ursprünglichen Rechnungskurs wird als realisierter Kursgewinn oder -verlust verbucht. Ein Payout mit gemischten Währungen wird beim Import abgewiesen

Nehmen Sie die Abstimmung auf drei Ebenen vor: auf Zeilenebene (jede Transaktion hat eine unveränderte ID, Kategorie, Betrag, Währung, Quelle), auf Payout-Ebene (die Netto-Einzelposten entsprechen dem Stripe-Payout sowie dem Bankeingang) und auf Hauptbuchebene (der verbuchte Journalbeleg geht auf und erzeugt die beabsichtigten Salden für Umsätze, Gebühren, Forderungen, Verkäufer-Verbindlichkeiten und Interimskonten). Verifizieren Sie insbesondere für die Verkäufersalden, dass der Anfangsbestand der Verbindlichkeiten plus der neuen Verkäuferanteile, abzüglich der Transfers und legitimen Stornierungen, exakt dem Endbestand der Verbindlichkeiten gegenüber den Verkäufern entspricht.

Das immer wiederkehrende Versäumnis bei allen Marktplatz-Hauptbüchern ist jenes, mit dem alles begann: Die Verdichtung eines strukturierten Payouts auf eine einzige Zahl. Halten Sie die Bestandteile strikt voneinander getrennt, binden Sie jeden Posten an eine eindeutige Stripe-Kennung und nutzen Sie das Interimskonto für alles, was Sie noch nicht zuordnen können. Einen sauberen Monatsabschluss wird auch jeder Wirtschaftsprüfer anstandslos akzeptieren.

FAQ

Ist das Stripe-Payout der Umsatz der Plattform?

Nein. Das Payout ist das Nettoergebnis aus Zahlungen, Rückerstattungen, Bearbeitungsgebühren, Verkäufer-Transfers, Disputen und Anpassungen (Adjustments), die zufällig im gleichen Batch abgerechnet wurden. Wenn Sie diese Summe als eine einzige Umsatzzeile verbuchen, unterschlagen Sie die darin enthaltenen Verbindlichkeiten gegenüber dem Verkäufer sowie den Zahlungsabwicklungsaufwand. Bei einem Vermittlungs-Marktplatz (Agent Marketplace) entspricht der Umsatz ausschließlich der Provision, die in den platform_earning-Zeilen ausgewiesen wird.

Gegen welchen Stripe-Bericht sollte ich die Abstimmung vornehmen?

Gegen den Bericht Payout reconciliation, itemized (detaillierte Auszahlungsabstimmung). Dieser Bericht liefert eine Zeile pro Balance-Transaktion, inklusive reporting_category, automatic_payout_id sowie Brutto-, Gebühren- und Nettobeträgen. Eine Auszahlungsübersicht im Dashboard belegt lediglich die Gesamtsumme des Batches. Wenn automatische Auszahlungen nicht aktiviert sind, sollten Sie stattdessen den Balance-Bericht nutzen.

Sollte ein Transfer an einen Verkäufer als Aufwand gebucht werden?

Nein. Der Anteil des Verkäufers wird in dem Moment zu einer Verbindlichkeit, in dem die Zahlung des Kunden eingeht, und der Transfer begleicht lediglich diese Verbindlichkeit. Wenn Sie Transfers als Aufwand verbuchen, rechnen Sie die Kosten doppelt und weisen die Verbindlichkeit gegenüber dem Verkäufer dauerhaft zu hoch aus.

Was passiert mit einer Stripe-Zeile, deren Kategorie der Importer nicht erkennt?

Diese wird auf dem Settlement-Interimskonto (Standardkonto 4440) gebucht, und die Antwort der API wirft eine Warnung mit den Kategorienamen aus, die dort gelandet sind. Rücklagen (Reserves) und ungewöhnliche Anpassungen landen typischerweise dort, was volle Absicht ist: Das Geld bleibt sichtbar und der Journalbeleg ist ausgeglichen, bis jemand entscheidet, wo der Betrag korrekt hingehört.

Wie werden Refunds behandelt, die erst in einem späteren Payout abgerechnet werden?

Sie tauchen als refund-Zeile im detaillierten Bericht des späteren Payouts auf und werden anhand der charge_id wieder der ursprünglich abgeglichenen Zahlung zugeordnet. Ein synthetischer Refund aus einem Zahlungs-Export (Charge-Level Payments Export) ist in diesem Fall nur eine Annäherung; der detaillierte Auszahlungsbericht ist daher die verlässlichere Datenquelle.

Weiterführende Links

• Bank- und Zahlungsimporte, einschließlich der Abstimmung von Stripe-Settlements
• Zahlungsabstimmung (Payment Reconciliation): PSP-Payouts mit dem Hauptbuch abgleichen
• Nebenbücher für Marktplatzverkäufer: Umsätze vs. Verbindlichkeiten
• Wie Charges in einer Connect-Integration funktionieren (Stripe)