売上エクスポートには10,000ドルと表示されている。銀行口座には9,000ドルしかない。数式を確認し、数値を別のシートにコピーしても、それでも上司に資金が不足しているのかどうかを説明できない。
小規模なEC事業やサービス業にとって、有用な答えとは、各調整の根拠となる記録を伴う短い説明である。500ドルの返金、300ドルの手数料、そして200ドルはまだ決済待ち。 これで、何が入金済みで、何が未入金で、何を調査すべきかがわかる。
以下の4ファイルの練習用パックに取り組んで、その説明を組み立てよう。Excelで追いながら、同じルールを使ってRowSpeakでレビュー可能な分析を依頼できる。
主なポイント:
- 支払済売上、プラットフォーム上のアクティビティ、ペイアウト、実際の銀行入金を分けて扱う。これらは異なる事象を記録している。
- 完全な10,000ドル → 9,000ドルの例を追い、各ペイアウトをその取引と銀行受領証の両方と照合する。
- 保留資金を可視化しておく。入金不足は自動的に手数料や損失になるわけではない。
- ダウンロード、プロンプト、10ドル失敗テストを使って、業務レポートを信頼する前にツールの出力を確認する。
- RowSpeakはファイルの分析と結果の説明を支援できるが、照合ルールと未解決の差異を承認するのはあなたである。
売上と入金が通常一致しない理由
支払済注文は顧客が支払った内容を記録する。ペイアウトは決済プラットフォームからの送金である。銀行入金は口座に記帳された資金を記録する。返金、決済手数料、送金タイミングによって、これら金額はエラーを示さずに異なることがある。
売上照合とは、差異に説明がつくまでこれらの記録を追跡することである。売上から銀行へのチェックでは、期間の開始時と終了時の残高も必要である。一部の現金は前月の売上に属し、今月の現金の一部は後で入金される場合がある。
Stripeのペイアウト照合ドキュメントでは、ペイアウトを、支払い・返金・手数料を含む取引バッチと照合する方法が説明されている。また、同レポートはペイアウトを推定到着日でグループ化しており、これは銀行の記帳日と異なる場合があると注記している。他のプラットフォームには異なるエクスポートとルールがある。テンプレートをコピーする前に自分の環境を確認すること。
このガイドでは、支払済売上を現金の動きと照合する。 認識される会計収益、税務処理、または財務諸表が正しいかどうかを判断するものではない。
ステップ1:4つのファイルを集め、各行の意味を定義する
ダウンロードにはDemoStore向けの2026年9月の合成例が含まれている。すべての金額はUSD、日付はUTC、開始時のプラットフォーム残高はゼロである。これらは独立して計算された回答を伴う架空の練習用レコードであり、顧客の結果や記録されたRowSpeakの実行ではない。
| ファイル | 1行の意味 | 確認するフィールド |
|---|---|---|
| orders.csv | 1件の支払済注文 | order_id, order_date, paid_sales, currency |
| processor-activity.csv | 1件の課金、返金、または手数料イベント | event_id, order_id, payout_id, signed_amount |
| payouts.csv | プラットフォームから送金された1件の送金 | payout_id, payout_amount, bank_reference |
| bank.csv | 記帳された1件の銀行入金 | bank_row_id, posted_date, reference, credit |
原本は変更しない。コピーで作業し、各ファイルがどのエクスポートとどのアカウントから来たかを記録する。実際の注文明細エクスポートでは、複数行が1件の注文に属することがある。注文を数えたり支払いを照合したりする前に、その扱いを決めること。
この演習では、9月は完了しているものと規定されている。サンプルには税金、送料、通貨換算、異議申し立て、保留金、未払い注文、前期調整はない。実際のファイルでは、それぞれに別行が必要になる場合がある。
ステップ2:金額を照合する前に期間を合意する
報告ルールを1文で書く:
DemoStoreの9月1日〜30日の支払済売上と9月の銀行入金をUSDで説明し、開始時と終了時のプラットフォーム残高を別々に示す。
すべてのファイルをorder_dateでフィルタしないこと。注文、その返金、プラットフォームのペイアウト、銀行記帳は4つの異なる日に発生しうる。
実際の月末チェックでは、開始時プラットフォーム残高、終了時残高、両方の境界時点で送金済みだがまだ記帳されていない送金を入手する。また、8月注文に対する9月の返金も確認する。これらの記録がなければ、当月の注文エクスポートではすべての現金の動きを説明できない。
このフィクスチャでは、開始時残高と未達の送金はゼロである。唯一の期末残高は注文O105である:9月30日に課金された200ドルで、まだペイアウトが割り当てられていない。 その金額を保留資金テーブルに保持し、後日のペイアウトと照合する。行方不明のお金と呼んではならない。
ステップ3:ソース記録で1,000ドルの差異を説明する
まず5件の支払済注文から始める:
| 注文 | 支払金額 | 調整または次のステップ |
|---|---|---|
| O101 | $3,000 | ペイアウトP01に含まれる |
| O102 | $2,500 | 300ドル返金、残りのアクティビティはP01 |
| O103 | $2,000 | ペイアウトP02に含まれる |
| O104 | $2,300 | 200ドル返金、残りのアクティビティはP02 |
| O105 | $200 | 9月30日時点でまだプラットフォーム上にある |
| 合計 | $10,000 | 返金とプラットフォーム手数料前 |
返金イベントE03とE07は合計500ドル。手数料イベントE04とE08は合計300ドル。プラットフォームの期末未決済残高はE09の200ドルである。
図:ダウンロード可能な合成レコードから独立して計算。これは説明用のチャートであり、製品のスクリーンショットではない。
結果は次のとおりである:
支払済売上 $10,000
返金を差し引く $500
プラットフォーム手数料を差し引く $300
期末未決済資金を差し引く $200
予想銀行入金 $9,000
実際の銀行入金 $9,000
未説明差異 $0
この単純なブリッジが機能するのは、サンプルの他のフローと開始時残高がゼロだからである。実際のデータでは、開始時資金を加算、期末資金を減算として示し、他のプラットフォーム調整と未達の送金を別途記録する。ゼロに合わせるためだけに「タイミング調整」をでっち上げてはならない。
ステップ4:各ペイアウトを確認し、次に銀行を確認する
合計が一致していても、相殺し合う誤りが隠れている可能性がある。個々のバッチも確認すること。
| ペイアウト | ソースアクティビティ | 純支払額 | 銀行証跡 | 差異 |
|---|---|---|---|---|
| P01 | 3,000ドル + 2,500ドル − 300ドル返金 − 120ドル手数料 | $5,080 | B01:5,080ドル、9月10日記帳 | $0 |
| P02 | 2,000ドル + 2,300ドル − 200ドル返金 − 180ドル手数料 | $3,920 | B02:3,920ドル、9月25日記帳 | $0 |
信頼できるペイアウト参照を使用して、送金を銀行に紐付ける。参照がない場合は、金額、口座、通貨、記録された日付範囲を使って可能性のある一致を特定する。同額の2件の入金は、誰かが確認するまで曖昧なままである。
スプレッドシートの罠もある。1件の注文に課金と返金の両方が存在することがある。注文テーブルをすべてのイベントに結合してからpaid_salesを合計すると、注文金額が2回現れる。売上は元の注文テーブルから合計し、現金アクティビティはイベントテーブルから合計する。結果は正しいレベルで比較する。
アクティビティファイルでは、返金と手数料はすでに負の値である。各ペイアウトについてsigned_amountを合計する。それらの負の値を再度差し引くと結果が膨らむ。ZIPには解答キーとしてexpected-payout-matches.csvとexpected-bridge.csvが含まれている。
ステップ5:レビュー可能な説明をRowSpeakに依頼する
ルールが明確になったら、RowSpeakのデータ分析ワークフローを使って、エクスポートの確認、集計の計算、結果の読みやすいレポート化を支援できる。業務ファイルをアップロードする前に、まず合成入力から始める。
4つの入力CSVのみをアップロードし、このリクエストを使用する。後で比較できるよう、解答キーファイルは実行に含めないこと。
DemoStoreの2026年9月1日〜30日の支払済売上と銀行入金の照合を支援してください。添付された4つのCSVを使用します。すべての金額はUSD、日付はUTCです。ソースデータは変更しないでください。ordersの各行は1件の支払済注文、processorの各行は1件のイベントです。返金と手数料はすでに負の値です。
まず一意のID、欠落キー、通貨、ソースカバレッジを確認してください。各注文金額をその課金イベントと比較し、不一致をフラグしてください。売上は、返金イベントと結合したテーブルではなく、ordersから計算してください。processorのsigned_amountをpayout_idでグループ化してください。payout_idが空のイベントは未決済アクティビティとして保持してください。各バッチをpayouts.payout_amountと比較し、そのbank_referenceをbank.referenceとbank.creditに照合してください。曖昧な一致を推測したり、送金済みペイアウトを銀行受領として扱ったりしないでください。
売上、返金、手数料、未決済資金、ペイアウト一致、未一致項目についてソースIDを示してください。この演習では開始時プラットフォーム残高と未達の送金はゼロです。他の調整タイプはありません。売上から銀行へのブリッジ、ペイアウト一致テーブル、例外テーブルを返してください。不明な原因は未解決としてラベル付けし、帳尻合わせの手数料を決して追加しないでください。最後に短いマネージャー向け要約と、まだ承認が必要なチェックを付けてください。
期待値: 支払済売上10,000ドル、返金500ドル、手数料300ドル、未決済200ドル、銀行受領9,000ドル。両方のペイアウトが一致する。O105は説明済みの保留項目で、未説明差異はゼロである。これらは計算された期待値であり、いかなるAIツールの出力を保証するものではない。
機密の財務記録については、アップロード前に匿名化ファイルを使用するか、プライベートデプロイについて相談する。このガイドはエクスポート済みファイルを使用しており、ライブの銀行接続、自動決済監視、RowSpeak内の独立した検証エージェントを前提としていない。
ステップ6:月次結果を使用する前に失敗をテストする
bank.csvのコピーを作成する。B02の入金額を3,920から3,910に変更し、そのコピーと他の3つの元入力を使ってリクエストを繰り返す。
銀行合計は8,990ドルになり、P02には10ドルの不足が表示されるはずである。返金、手数料、保留資金は変更されないままでなければならない。ツールが黙って10ドルの手数料を追加したり、O105を変更したり、すべて一致したと宣言したりした場合は、ソース行を求め、レポートは下書きのままにする。
共有する前に確認する:
- 各注文の課金がソース金額と一致し、各銀行入金に承認済みの一致が1つある。
- 返金と手数料が正しい符号で1回だけ現れる。
- 保留資金にソースIDとフォローアップ日がある。
- 欠落ID、重複イベント、曖昧な一致が見える状態で残っている。
- 開始時・終了時残高、通貨、日付ルール、完全性について、確認できる担当者がいる。
より広範なAI生成レポートのレビューチェックリストでは、根拠のない説明や重複行など、他のチェックを扱っている。
上司に送る内容
変更していないサンプルについて、有用なメモは次のとおりである:
9月の支払済売上は10,000ドルでした。返金500ドル、プラットフォーム手数料300ドル、月末時点で未決済の200ドルを差し引くと、銀行受領は9,000ドルでした。両方のペイアウトバッチは銀行入金と一致しています。保留残高200ドルはO105に関連し、後日のペイアウト確認が必要です。記載されたサンプル範囲内では、未説明差異は残っていません。
そのメモを、入力バージョン、照合ルール、例外判断、レビュー承認と一緒に保存する。来月については、定期的なCSVレポートワークフローで、ファイルを更新しながらそれらのルールを維持する方法を説明している。
次の月次締めを説明しやすくする
未説明の差異をレビューリストに変える。
次の月末レビューの前に、RowSpeakで4ファイルの例を試す。9,000ドルの結果を確認し、例外を調査する時間があるうちに10ドルの失敗テストを実行する。
まず合成ファイルから始める。実際の月次締めに適用する前に出力をレビューする。






