先月、マーケットプレイスはあなたの銀行口座に$35,300を入金しました。そこへフォーム1099-Kが届き、$58,400と記載されています。どちらの数字も間違いではありません — しかし、あなたの帳簿が売上として$35,300を示しているなら、その帳簿は間違っており、この差額は確定申告から価格設定の意思決定に至るまで、あらゆるものを静かに歪めています。入金額はマーケットプレイスが取り分を差し引いた後に残ったものであり、あなたの売上は顧客が実際に支払った金額です。このガイドでは、決済レポートに溺れることなく、毎月この二つを照合する方法を紹介します。
ペイアウトが売上と決して一致しない理由、1099-Kとの整合性を保つ総額記録のルール、各ペイアウトをゼロに照合させる仮勘定方式、Amazon型マーケットプレイスとShopifyの決済明細行の読み方、そして税金の問題になる前に不足金を発見する毎月のルーティンを学びます。
ペイアウトが売上と決して一致しない理由
マーケットプレイスのペイアウトは売上高ではなく純残額です。マーケットプレイスは顧客から全額を回収し、自分に支払われるべきものや源泉徴収が義務付けられているものをすべて差し引き、残りをあなたに送金します。典型的なペイアウトはこれらすべてを一つの銀行入金にまとめます：
- 各注文の紹介料または手数料
- フルフィルメント、配送、保管の各手数料
- 決済処理手数料
- 期間中に発行された顧客への返金
- 販売者アカウントに請求された広告費
- リザーブの留保（将来の返品やチャージバックに備えて保留された資金）
- 紛失または破損した在庫に対してあなたに返還される弁済金
- 前期の調整および修正
つまり、$35,300の入金は、$58,400の顧客支払から、紹介料$8,760、フルフィルメント手数料$6,140、保管料$890、返金$2,310、広告費$3,420を差し引き、弁済金$310を加え、リザーブの増加額$1,890を差し引いたものを表しているかもしれません。三つの異なる書類がその物語の三つの部分を語ります：注文レポートは顧客が総額で何を買ったかを示し、決済またはペイアウトレポートはプラットフォームが支払可能として項目ごとに計算したものを示し、銀行明細は実際に到着したものを示します。照合とは、この三つを結びつけ、総売上のすべてのドルが、検証可能な手数料、あなたが承認した返金、追跡可能なリザーブ、または銀行の現金のいずれかに辿れるようにする規律です。
これは整った帳簿以上の意味を持ちます。入金額だけを記録する事業は、売上を過少報告し、真の手数料負担を隠し、最も有用なチャネルに関する問いに答える能力を失います：このマーケットプレイスは実際に売上の何パーセントをあなたに負担させているのか？
総額記録のルール：売上と手数料を別々に記帳する
マーケットプレイス記帳の基本ルールは単純です：総売上を収益として記録し、すべての手数料を独自の費用として記録する。純入金を収益として記録してはいけません。
これが譲れない理由は三つあります。第一に、税務書類は総額で語ります。IRSは第三者決済機関に対し、フォーム1099-KのBox 1aに総支払額を、手数料、クレジット、返金、配送料、割引の調整なしで報告することを義務付けています — これらの項目は所得ではなく、確定申告時に総額から差し引くものです。帳簿が純入金を収益として示していると、収益は1099-Kと決して一致せず、IRSからの通知への対応は一年分の決済レポートを掘り起こす考古学的発掘作業になります。
第二に、純額記録は管理すべきコストを隠します。月間売上$58,400で合計手数料$19,210を支払う販売者は、売上1件ごとの約33パーセントをチャネルに支払っています。この手数料負担こそ、値上げすべきか、再交渉すべきか、より安価なチャネルへ数量を移すべきかを教えてくれる数字です — そして手数料が費用として帳簿に決して現れなければ、それは見えません。
第三に、総額記録こそが返金、リザーブ、弁済金を追跡可能にします。返金は収益の減少（または収益の控除項目）、リザーブの変動はプラットフォームからの売掛金、弁済金は収入または回収であり、それぞれが独自の行を必要とします。そうすれば月をまたぐタイミングの違いが利益率を損なうことはありません。
関連する落とし穴が一つ：買い手から徴収した売上税またはマーケットプレイスが代行徴収した税も、あなたの収益ではありません。それはあなたを通じて課税当局へ渡るものであり、納付するまで貸借対照表の負債として計上されるべきです。総額決済明細に現れるかどうかに関わらず。
ペイアウトをゼロに照合させる仮勘定方式
総額記録を実装する最もクリーンな方法は仮勘定です — 販売チャネルごとに一つ — ペイアウトが決済されるまで各プラットフォームの活動を保持します。マーケットプレイスと銀行の間の中間ステージングエリアと考えてください。単一のペイアウト期間の完全なサイクルは次のとおりです：
- 総売上を記録する。 チャネル仮勘定（資産、本質的にはプラットフォームからの売掛金）を借方に記入し、顧客支払全額について売上収益を貸方に記入します。
- 手数料を費用として記録する。 該当する費用勘定 — マーケットプレイス紹介料、フルフィルメント手数料、決済処理手数料、広告費 — を借方に記入し、仮勘定を貸方に記入します。
- 返金を記録する。 期間中に発行された返金について、返金または売上戻り（収益の控除項目）を借方に記入し、仮勘定を貸方に記入します。
- リザーブの変動を記録する。 プラットフォームがリザーブを増加させた場合、マーケットプレイスリザーブ売掛金を借方に記入し、仮勘定を貸方に記入します。リザーブが解放されたときに逆仕訳します。
- ペイアウトを振り替える。 入金が到着したら、銀行口座を借方に記入し、純額について仮勘定を貸方に記入します。
すべての行が捕捉されると、仮勘定は（未清算のリザーブのようなタイミング項目を除いて）ゼロに戻ります。ゼロでない残高は早期警告システムです：手数料が見落とされた、返金が誤った期間に転記された、またはペイアウトがまだ到着していないことを意味します。調整仕訳でゼロに強制するのではなく、残差を調査してください — 残差は照合が機能している証拠です。
チャネルは分けて保ちます。Amazon、Shopify、Etsy、eBay、Stripeはそれぞれ独自の仮勘定を持つべきです。各プラットフォームには独自の手数料体系、ペイアウトサイクル、レポート形式があるからです。それらを一つの勘定に統合すると、すべての調査がマルチプラットフォームのパズルになります。ほとんどの小規模販売者にはペイアウト期間ごとの要約仕訳で十分です。大量販売者は日次で要約を転記するかもしれませんが、どちらでも構造は同じです。
決済レポートを一行ずつ読む
各プラットフォームのレポートは見た目が異なりますが、解剖学的構造は同じです。明細行の種類を一度学べば、どれでも読めるようになります。
Amazon型マーケットプレイスの決済
Seller Central（支払レポート）から決済レポートをダウンロードし、この順序で読みます：
- 注文明細行 — 商品代金、顧客から徴収した配送料、ギフト包装。これが期間の総額です。
- 返金明細行 — 返品とキャンセルに対して借方に記入された金額で、それぞれ元の注文IDを参照しています。すべての返金が実際に承認した返品と一致することを確認します。
- 手数料明細行 — 紹介料、成約手数料、フルフィルメント（FBA）手数料、月次保管料。紹介料のパーセンテージをカテゴリの公表料率と抜き取り確認します。誤分類された商品は日常的に過剰請求されます。
- その他の請求 — 販売者アカウントを通じて請求された広告費とサブスクリプション料。広告プラットフォームの請求書も帳簿に流れ込む場合、二重計上しやすいです — 一つのソースを選んでください。
- 弁済明細行 — 紛失または破損したFBA在庫に対するクレジット。これらは収入（または在庫損失に対する回収）であり、手数料の減少ではありません。販売者は日常的にこれらを未請求のままにしています。
- リザーブと残高の明細行 — 期首残高、期末リザーブ、結果としての振替額。リザーブは依然としてあなたのお金です。売掛金として追跡し、増加するリザーブが利益の縮小として読まれないようにします。
Shopifyペイアウト
Shopifyの財務サマリーとペイアウトレポートは、各ペイアウトを請求（徴収した配送料と税金を含む総顧客支払）、返金、調整、取引手数料、結果としての純ペイアウトに分解します。照合の式は：請求 − 返金 ± 調整 − 手数料 = 銀行入金。Shopifyは返金を処理された期間のペイアウトの減少として報告する点に注意してください。これは元の売上の期間と異なる場合があります — 返金をカレンダーの直感ではなくペイアウトIDでペイアウトに照合し、タイミングのギャップを仮勘定に吸収させてください。
どのプラットフォームでも、検証の習慣は同じです：期間の明細行タイプごとに合計し、総額から純額への計算がペイアウトを1セントまで再現することを確認し、入金日と金額が銀行フィードと一致することを確認します。明細行が入金に合計しないペイアウトは、明細行が欠けている（画面表示ではなく完全な日付範囲をエクスポートしてください）か、まだ分類していない調整が含まれています。
実例：売上$58,400から入金$35,300へ
現実的な数字で一つの決済期間を歩いてみましょう：
| 明細 | 金額 |
|---|---|
| 商品売上（総額） | $58,400 |
| 発行済み返金 | −$2,310 |
| 紹介料 | −$8,760 |
| フルフィルメント手数料 | −$6,140 |
| 保管料 | −$890 |
| アカウントに請求された広告費 | −$3,420 |
| 在庫弁済金 | +$310 |
| リザーブ増加 | −$1,890 |
| 銀行への純ペイアウト | $35,300 |
その背後の仕訳：Amazon仮勘定を借方に記入し$58,400について収益を貸方に記入；返金（収益の控除項目）を$2,310借方に記入；手数料と広告費の合計$19,210を借方に記入；リザーブ売掛金を$1,890借方に記入；それぞれについて仮勘定を貸方に記入；次に銀行を借方に記入し$35,300について仮勘定を貸方に記入。仮勘定はゼロに純額化し、収益は注文レポートと一致し、総チャネルコスト — 売上$58,400に対する手数料$19,210と返金$2,310 — は36.8パーセントの総合チャネルコストとして可視化されます。このパーセンテージこそ月ごとに注視すべき数字です。急な上昇は通常、手数料の値上げ、商品の誤分類、または制御不能な広告費を意味します。
年末に1099-Kと照合する
フォーム1099-KのBox 1aは調整なしで総支払額を報告するため、年末のタスクは、帳簿のマーケットプレイス総売上がフォームの総額と等しいことを証明し、次に手数料、返金、調整を、総額から課税所得へ橋渡しする控除として示すことです。その橋を意図的に構築します：
- 年間の帳簿に基づき、各チャネルの総収益を合計します。
- 各合計を対応する1099-KのBox 1aと比較します。申告前に重大な差異を調査します：一般的な原因は、12月の売上に対して1月に処理された返品、大晦日をまたぐペイアウト、一方の数字には含まれるが他方には含まれない売上税です。
- 手数料と返金が、報告された総所得の減少ではなく、申告書（スケジュールCまたは事業体の申告書）の控除として現れることを確認します。IRSのガイダンスは、これらの項目が総額から差し引かれることを明確に述べています。
- 決済レポートを保管します。IRSが不一致を問題視した場合、決済ファイルと仮勘定履歴が、長い往復調査ではなく一通の手紙で解決する監査証跡です。
連邦の1099-K報告の閾値は近年何度か変更されており、いくつかの州は独自のより低い閾値を課している点に注意してください — 昨年のルールが今も有効と仮定するのではなく、IRSの1099-Kガイダンスで現在の数字を確認してください。フォームを受け取るかどうかに関わらず、すべての所得は依然として報告対象です。フォームは書類仕事を変えるのであって、課税対象を変えるのではありません。
マーケットプレイスの帳簿を壊す7つの過ち
- 入金を収益として記録する。 原罪です。所得を過少報告し、手数料費用を消し去り、帳簿が1099-Kと一致しないことを保証します。
- 返金を誤った期間に転記する。 12月の売上が1月に返金された場合、1月のペイアウトに対して処理します。返金は売上日ではなく決済期間に従います。
- リザーブを無視する。 売掛金を決して計上しなければ、増加するリザーブは利益の縮小に見えます。毎月追跡してください。
- すべての手数料を一つの行にまとめる。 「Amazon手数料」を単一の費用とすると、紹介料、フルフィルメント、保管料、広告費のどれがコスト急増を引き起こしたかが見えなくなります。分解してください。
- チャネルを一つの勘定で混ぜる。 プラットフォームごとに一つの仮勘定、常に。共有勘定はすべての不一致をクロスプラットフォームの調査にします。
- 広告費の二重計上。 販売者アカウントを通じて請求された広告費と別途請求された広告費は同じドルです — 一つのソースから一度だけ記帳してください。
- 徴収した売上税を収益として計上する。 州に代わって徴収する税金は負債であり、収入ではありません。収益として記録すると売上が過大報告され、負うべき額が過少報告されます。
毎月のマーケットプレイス締めチェックリスト
上記の方法を30分の毎月のルーティンに変えましょう：
- 締め期間について各チャネルの注文、決済、ペイアウトレポートをエクスポートする
- 各チャネルの仮勘定に総売上、手数料、返金、調整を転記する
- 各ペイアウトの計算を検証する：総額 − 手数料 − 返金 ± 調整 = 入金
- すべての入金を金額と日付で銀行フィードに照合する
- 仮勘定をゼロに清算する（追跡されたリザーブと輸送中のペイアウトを除く）
- 総合チャネルコストのパーセンテージを前月と比較検討し、急増を調査する
- 1月に税務担当者が見つけられる場所にレポートをファイルする
構造が整えば、マーケットプレイスの照合は恐ろしいものではなくなります。決済レポートが難しい算術を代わりに行ってくれます。あなたの仕事は、純入金に収益のふりをさせるのではなく、すべての行に帳簿上の適切な居場所を与えることだけです。
初日からすべてのチャネルの帳簿をクリーンに保つ
Amazon、Shopify、その先へとマーケットプレイスの売上が成長するにつれ、総売上と銀行入金の差は手作業で追跡するのがますます難しくなります — そして決済レポートのスプレッドシート要約こそ、手数料のじわじわした増加が隠れる場所です。チャネルごとに別々の仮勘定を維持し、すべての手数料と返金を独自の行として記録することが、混乱したペイアウトの山を確定申告時に信頼できる帳簿に変えます。Beancount.ioは、あなたの財務データに対する完全な透明性とコントロールを与えるプレーンテキスト会計を提供します — ブラックボックスも、ベンダーロックインもありません。無料で始めるそして、開発者や財務専門家がなぜプレーンテキスト会計に切り替えているかをご覧ください。
