Ihr Verkaufsexport sagt 10.000 $. Ihre Bank zeigt 9.000 $. Sie prüfen die Formel, kopieren die Zahlen in ein anderes Tabellenblatt und können Ihrem Vorgesetzten immer noch nicht sagen, ob Geld fehlt.
Für ein kleines E-Commerce- oder Dienstleistungsunternehmen ist eine nützliche Antwort eine kurze Erklärung mit Belegen hinter jeder Anpassung: 500 $ erstattet, 300 $ Gebühren und 200 $, die noch auf Verrechnung warten. Jetzt wissen Sie, was angekommen ist, was nicht angekommen ist und was untersucht werden muss.
Arbeiten Sie das unten stehende Vier-Dateien-Übungspaket durch, um diese Erklärung aufzubauen. Sie können es in Excel nachvollziehen und dann dieselben Regeln verwenden, um in RowSpeak eine prüfbare Analyse anzufordern.
Wichtigste Erkenntnisse:
- Trennen Sie bezahlte Verkäufe, Plattformaktivität, Auszahlungen und tatsächliche Bankgutschriften. Sie erfassen unterschiedliche Ereignisse.
- Folgen Sie einem vollständigen Beispiel von 10.000 $ → 9.000 $ und prüfen Sie jede Auszahlung sowohl gegen ihre Transaktionen als auch gegen ihren Bankbeleg.
- Halten Sie ausstehende Gelder sichtbar. Eine fehlende Einzahlung ist nicht automatisch eine Gebühr oder ein Verlust.
- Nutzen Sie den Download, den Prompt und den 10-$-Fehlerfalltest, um die Ausgabe eines Tools zu prüfen, bevor Sie Ihrem Geschäftsbericht vertrauen.
- RowSpeak kann helfen, die Dateien zu analysieren und das Ergebnis zu erklären; Sie genehmigen weiterhin die Abgleichsregeln und ungeklärten Differenzen.
Warum Verkäufe und Einzahlungen üblicherweise abweichen
Eine bezahlte Bestellung erfasst, was der Kunde bezahlt hat. Eine Auszahlung ist eine Überweisung von Ihrer Zahlungsplattform. Eine Bankgutschrift erfasst Geld, das auf Ihrem Konto gebucht wurde. Erstattungen, Verarbeitungsgebühren und Überweisungszeitpunkte können diese Beträge unterschiedlich machen, ohne auf einen Fehler hinzuweisen.
Verkaufsabstimmung bedeutet, diese Belege nachzuverfolgen, bis die Differenz eine Erklärung hat. Ein Verkauf-zu-Bank-Abgleich benötigt außerdem Bestände zu Beginn und Ende des Zeitraums: Ein Teil des Geldes kann zu Verkäufen eines früheren Monats gehören, und ein Teil des Geldes dieses Monats kann später eintreffen.
Stripe-Dokumentation zur Auszahlungsabstimmung beschreibt, wie eine Auszahlung mit ihrem Transaktionsbatch abgeglichen wird, einschließlich Zahlungen, Erstattungen und Gebühren. Sie weist außerdem darauf hin, dass ihr Bericht Auszahlungen nach geschätztem Ankunftsdatum gruppiert, das vom Buchungsdatum der Bank abweichen kann. Andere Plattformen haben andere Exporte und Regeln; bestätigen Sie Ihre, bevor Sie eine Vorlage übernehmen.
Dieser Leitfaden prüft bezahlte Verkäufe gegen Cash-Bewegungen. Er bestimmt nicht den anerkannten Buchhaltungsumsatz, die steuerliche Behandlung oder ob ein Finanzabschluss korrekt ist.
Schritt 1: Vier Dateien sammeln und jede Zeile definieren
Der Download enthält ein synthetisches Beispiel für September 2026 für DemoStore. Alle Beträge sind in USD, Datumsangaben verwenden UTC und der Anfangsbestand der Plattform ist null. Dies sind erfundene Übungsdatensätze mit unabhängig berechneten Antworten, keine Kundenergebnisse oder ein aufgezeichneter RowSpeak-Lauf.
| Datei | Eine Zeile bedeutet | Zu prüfende Felder |
|---|---|---|
| orders.csv | Eine bezahlte Bestellung | order_id, order_date, paid_sales, currency |
| processor-activity.csv | Ein Belastungs-, Erstattungs- oder Gebührenereignis | event_id, order_id, payout_id, signed_amount |
| payouts.csv | Eine von der Plattform gesendete Überweisung | payout_id, payout_amount, bank_reference |
| bank.csv | Eine gebuchte Bankgutschrift | bank_row_id, posted_date, reference, credit |
Lassen Sie Originale unverändert. Arbeiten Sie mit Kopien und halten Sie fest, aus welchem Export und Konto jede stammt. In einem echten Bestellpositions-Export können mehrere Zeilen zu einer Bestellung gehören; entscheiden Sie das, bevor Sie Bestellungen zählen oder Zahlungen zuordnen.
Für diese Übung wird angenommen, dass September vollständig ist. Das Beispiel enthält keine Steuern, Versandkosten, Währungsumrechnung, Streitfälle, Rücklagen, unbezahlte Bestellungen oder Anpassungen aus Vorperioden. Reale Dateien benötigen möglicherweise für jedes eine separate Zeile.
Schritt 2: Einigen Sie sich auf den Zeitraum, bevor Sie Beträge abgleichen
Schreiben Sie Ihre Reporting-Regel in einem Satz:
Erklären Sie die bezahlten Verkäufe von DemoStore vom 1.–30. September und die Bankeinzahlungen im September in USD, mit separat ausgewiesenen Anfangs- und Endbeständen der Plattform.
Filtern Sie nicht jede Datei nach order_date. Eine Bestellung, ihre Erstattung, die Plattformauszahlung und die Bankbuchung können an vier verschiedenen Tagen stattfinden.
Für eine echte Monatsabschlussprüfung ermitteln Sie den Anfangsbestand der Plattform, den Endbestand und Überweisungen, die gesendet, aber an beiden Grenzen noch nicht gebucht wurden. Prüfen Sie außerdem auf September-Erstattungen für August-Bestellungen. Ohne diese Datensätze kann ein Bestellexport des aktuellen Monats nicht jede Cash-Bewegung erklären.
In diesem Testdatensatz sind Anfangsbestände und Überweisungen im Transit null. Der einzige Endbestand ist Bestellung O105: 200 $ am 30. September belastet, noch keiner Auszahlung zugeordnet. Führen Sie diesen Betrag in einer Tabelle für ausstehende Gelder und prüfen Sie ihn gegen eine spätere Auszahlung; bezeichnen Sie ihn nicht als fehlendes Geld.
Schritt 3: Die 1.000-$-Lücke mit Quellbelegen erklären
Beginnen Sie mit fünf bezahlten Bestellungen:
| Bestellung | Bezahlter Betrag | Anpassung oder nächster Schritt |
|---|---|---|
| O101 | 3.000 $ | In Auszahlung P01 enthalten |
| O102 | 2.500 $ | 300 $ Erstattung; übrige Aktivität in P01 |
| O103 | 2.000 $ | In Auszahlung P02 enthalten |
| O104 | 2.300 $ | 200 $ Erstattung; übrige Aktivität in P02 |
| O105 | 200 $ | Am 30. September noch auf der Plattform |
| Summe | 10.000 $ | Vor Erstattungen und Plattformgebühren |
Erstattungsereignisse E03 und E07 summieren sich auf 500 $. Gebührenereignisse E04 und E08 summieren sich auf 300 $. Der nicht abgerechnete Endbestand der Plattform ist E09, 200 $.
Abbildung: unabhängig berechnet aus den herunterladbaren synthetischen Datensätzen. Dies ist ein erklärendes Diagramm, kein Produktscreenshot.
Das Ergebnis ist:
Bezahlte Verkäufe 10.000 $
Abzüglich Erstattungen 500 $
Abzüglich Plattformgebühren 300 $
Abzüglich nicht abgerechneter Endgelder 200 $
Erwartete Bankeinzahlungen 9.000 $
Tatsächliche Bankeinzahlungen 9.000 $
Ungeklärte Differenz 0 $
Diese einfache Überleitung funktioniert, weil die übrigen Ströme und Anfangsbestände des Beispiels null sind. Zeigen Sie bei realen Daten Anfangsgelder als Addition, Endgelder als Abzug und dokumentieren Sie andere Plattformanpassungen und Überweisungen im Transit separat. Erfinden Sie niemals eine „Timing-Anpassung“, nur um auf null zu kommen.
Schritt 4: Jede Auszahlung prüfen, dann die Bank prüfen
Eine übereinstimmende Gesamtsumme kann Fehler verbergen, die sich gegenseitig aufheben. Prüfen Sie auch die einzelnen Batches.
| Auszahlung | Quellaktivität | Nettoauszahlung | Banknachweis | Differenz |
|---|---|---|---|---|
| P01 | 3.000 $ + 2.500 $ − 300 $ Erstattung − 120 $ Gebühr | 5.080 $ | B01: 5.080 $ gebucht am 10. September | 0 $ |
| P02 | 2.000 $ + 2.300 $ − 200 $ Erstattung − 180 $ Gebühr | 3.920 $ | B02: 3.920 $ gebucht am 25. September | 0 $ |
Verwenden Sie eine verlässliche Auszahlungsreferenz, um die Überweisung mit der Bank zu verknüpfen. Wenn eine Referenz fehlt, nutzen Sie Betrag, Konto, Währung und ein dokumentiertes Datumsfenster, um mögliche Übereinstimmungen zu identifizieren. Zwei Einzahlungen in gleicher Höhe bleiben mehrdeutig, bis sie jemand bestätigt.
Es gibt außerdem eine Tabellenkalkulationsfalle: Eine Bestellung kann sowohl eine Belastung als auch eine Erstattung haben. Wenn Sie die Bestelltabelle mit jedem Ereignis verknüpfen und dann paid_sales summieren, erscheint der Bestellbetrag zweimal. Summieren Sie Verkäufe aus der ursprünglichen Bestelltabelle; summieren Sie Cash-Aktivität aus der Ereignistabelle. Vergleichen Sie die Ergebnisse auf der richtigen Ebene.
In der Aktivitätsdatei sind Erstattungen und Gebühren bereits negativ. Summieren Sie signed_amount je Auszahlung; diese negativen Werte erneut abzuziehen würde das Ergebnis aufblähen. Die ZIP-Datei enthält expected-payout-matches.csv und expected-bridge.csv als Lösungsschlüssel.
Schritt 5: RowSpeak um eine prüfbare Erklärung bitten
Sobald die Regeln klar sind, kann RowSpeaks Workflow für Datenanalyse Ihnen helfen, Exporte zu prüfen, Zusammenfassungen zu berechnen und die Ergebnisse in einen lesbaren Bericht zu verwandeln. Beginnen Sie mit den synthetischen Eingaben, bevor Sie Geschäftsdateien hochladen.
Laden Sie nur die vier Eingabe-CSV-Dateien hoch und verwenden Sie diese Anweisung. Halten Sie die Lösungsschlüsseldateien aus dem Lauf heraus, damit Sie danach vergleichen können.
Hilf dabei, die bezahlten Verkäufe von DemoStore vom 1.–30. September 2026 und die Bankeinzahlungen abzustimmen. Verwende die vier angehängten CSVs. Alle Beträge sind USD; Datumsangaben sind UTC. Lass die Quelldaten unverändert. Jede orders-Zeile ist eine bezahlte Bestellung; jede processor-Zeile ist ein Ereignis. Erstattungen und Gebühren sind bereits negativ.
Prüfe zuerst eindeutige IDs, fehlende Schlüssel, Währungen und Quellenabdeckung. Vergleiche jeden Bestellbetrag mit seinem Belastungsereignis; markiere Abweichungen. Berechne Verkäufe aus orders, nicht aus einer mit Erstattungsereignissen verknüpften Tabelle. Gruppiere processor signed_amount nach payout_id. Behalte Ereignisse mit leerer payout_id als nicht abgerechnete Aktivität. Vergleiche jeden Batch mit payouts.payout_amount und gleiche dann seine bank_reference mit bank.reference und bank.credit ab. Nimm bei mehrdeutigen Übereinstimmungen keine Vermutungen vor und behandle eine gesendete Auszahlung nicht als Bankeingang.
Zeige Quell-IDs für Verkäufe, Erstattungen, Gebühren, nicht abgerechnete Gelder, Auszahlungsübereinstimmungen und nicht zugeordnete Posten. Anfangsbestand der Plattform und Überweisungen im Transit sind in dieser Übung null. Andere Anpassungsarten fehlen. Gib eine Überleitung von Verkäufen zu Bank, eine Tabelle mit Auszahlungsübereinstimmungen und eine Ausnahmentabelle zurück. Kennzeichne unbekannte Ursachen als ungeklärt; füge niemals eine ausgleichende Gebühr hinzu. Schließe mit einer kurzen Zusammenfassung für den Vorgesetzten und den Prüfungen ab, die noch genehmigt werden müssen.
Erwartet: 10.000 $ bezahlte Verkäufe, 500 $ Erstattungen, 300 $ Gebühren, 200 $ nicht abgerechnet und 9.000 $ Bankeingänge. Beide Auszahlungen stimmen überein. O105 ist ein erklärter ausstehender Posten; die ungeklärte Differenz ist null. Dies sind berechnete Erwartungen, keine Garantie für die Ausgabe eines KI-Tools.
Bei vertraulichen Finanzunterlagen verwenden Sie anonymisierte Dateien oder besprechen Sie eine private Bereitstellung, bevor Sie sie hochladen. Dieser Leitfaden verwendet exportierte Dateien; er setzt keine Live-Bankverbindung, automatische Abrechnungsüberwachung oder einen unabhängigen Verifizierungsagenten in RowSpeak voraus.
Schritt 6: Testen Sie einen Fehlerfall, bevor Sie das Monatsergebnis verwenden
Erstellen Sie eine Kopie von bank.csv. Ändern Sie die Gutschrift von B02 von 3.920 auf 3.910 und wiederholen Sie dann die Anweisung mit dieser Kopie und den anderen drei Originaleingaben.
Die Banksumme sollte 8.990 $ werden, und P02 sollte eine Unterdeckung von 10 $ zeigen. Erstattungen, Gebühren und ausstehende Gelder müssen unverändert bleiben. Wenn das Tool stillschweigend eine Gebühr von 10 $ hinzufügt, O105 ändert oder alles als übereinstimmend erklärt, fragen Sie nach den Quellzeilen und behalten Sie den Bericht im Entwurf.
Prüfen Sie vor dem Teilen:
- Jede Bestellbelastung stimmt mit ihrem Quellbetrag überein, und jede Bankgutschrift hat genau eine genehmigte Übereinstimmung.
- Erstattungen und Gebühren erscheinen einmal, mit den richtigen Vorzeichen.
- Ausstehende Gelder haben Quell-IDs und ein Nachverfolgungsdatum.
- Fehlende IDs, doppelte Ereignisse und mehrdeutige Übereinstimmungen bleiben sichtbar.
- Anfangs- und Endbestände, Währungen, Datumsregeln und Vollständigkeit haben einen Verantwortlichen, der sie bestätigen kann.
Die umfassendere Checkliste zur Prüfung KI-generierter Berichte behandelt weitere Prüfungen, einschließlich nicht belegter Erklärungen und doppelter Zeilen.
Was Sie Ihrem Vorgesetzten senden sollten
Für das unveränderte Beispiel ist eine nützliche Notiz:
Die bezahlten Verkäufe im September betrugen 10.000 $. Die Bankeingänge betrugen 9.000 $ nach 500 $ Erstattungen, 300 $ Plattformgebühren und 200 $, die am Monatsende noch nicht abgerechnet waren. Beide Auszahlungs-Batches stimmen mit Bankgutschriften überein. Der ausstehende Saldo von 200 $ betrifft O105 und erfordert eine spätere Auszahlungsprüfung. Im angegebenen Beispielumfang bleibt keine ungeklärte Differenz.
Speichern Sie diese Notiz zusammen mit den Eingabeversionen, Abgleichsregeln, Ausnahmeentscheidungen und der Freigabe durch die prüfende Person. Für den nächsten Monat erklärt der wiederkehrende CSV-Reporting-Workflow, wie Sie diese Regeln beibehalten, während Sie die Dateien aktualisieren.
Machen Sie Ihren nächsten Abschluss leichter erklärbar
Verwandeln Sie die ungeklärte Differenz in eine Prüfliste.
Testen Sie das Vier-Dateien-Beispiel in RowSpeak vor Ihrer nächsten Monatsabschlussprüfung. Prüfen Sie das Ergebnis von 9.000 $ und führen Sie dann den 10-$-Fehlerfalltest durch, solange Sie noch Zeit haben, die Ausnahmen zu untersuchen.
Beginnen Sie mit den synthetischen Dateien. Prüfen Sie die Ausgabe, bevor Sie sie auf einen echten Abschluss anwenden.
