ある販売者がShopifyのダッシュボードをスクロールし、主力商品の売上総利益率が60%であるのを見て満足しています。しかし、会計士が年度末の数字をまとめると、実際の利益率は38%に近いことが判明します。残りの22ポイントは、入庫運賃、関税、3PLのピッキング手数料、繁忙期の追加料金、そして誰も記録していなかったAmazon倉庫での紛失ユニットによって、静かに食いつぶされていました。Eコマースにおいて最も高くつく会計上の盲点へようこそ。それが「幽霊売上原価（Phantom COGS）」です。
マルチチャネルの販売者は、シングルチャネルの小売業者よりも約190%多い収益を上げていますが、同時に190%複雑な記帳作業も引き継いでいます。在庫は同時に5つの場所に存在し、決済レポートは3つの異なる形式で届き、手数料には14もの種類があり、ユニットは毎日マーケットプレイス間で紛失、返品、または再分類されます。揚地原価、留保在庫、決済照合、および年度末の修正（トゥルーアップ）に関する意図的なシステムがなければ、あなたの損益計算書（P&L）は作り話に過ぎません。
このガイドでは、作り話をクリーンな総勘定元帳に変えるための4つのステップを説明します。
オンライン販売者にとっての売上原価（COGS）とは何か
売上原価（COGS）とは、該当期間中に実際に販売された商品を製造または取得するためにかかった直接的な費用のことです。実物商品を扱う販売者の場合、その計算式は非常にシンプルです。
売上原価 = 期首棚卸高 + 純仕入高 + 入庫運賃 + 関税 + 直接労務費 − 期末棚卸高
このシンプルさが罠です。ほとんどの販売者は「純仕入高」に仕入先からの請求額を入力して、そこで止まってしまいます。それ以外のすべて、つまり商品をフルフィルメント拠点に販売可能な状態で届けるために実際に支払ったコストは、雑費のバケツに放り込まれ、ユニットコストに反映されることはありません。これが、誰にも気づかれずに利益率が60%から38%に低下する理由です。
IRS（米内国歳入庁）は、在庫に完全な揚地原価（Landed Cost）が含まれることを期待しています。投資家や貸し手、そして将来新しいマーケットプレイスで価格設定を行おうとするあなた自身も同様です。
ステップ1：SKUごとの真の揚地原価を構築する
揚地原価（Landed Cost）とは、1つのユニットを配送拠点の販売準備が整った状態にするまでにかかる実際のコストのことです。ほとんどのEコマース運営において、その構成要素は以下の通りです。
- ベンダーコスト: ボリュームディスカウントやリベート適用後の請求価格。
- 入庫運賃: 工場から港、そして倉庫や3PLの受け取りドックまでの海上、航空、鉄道、またはトラック輸送費。
- 関税およびタリフ: HTS分類に基づく関税率、適用される場合はセクション301関税、および通関手数料。
- 通関仲介および保険: 通関件数ごとの固定手数料と貨物保険料。
- 入庫受取手数料: 3PLは通常、在庫の受け取りと保管に対して、パレットごと、カートンごと、または労働時間ごとに請求します。
- 準備とラベル貼り: ポリ袋詰め、セット組み、FNSKUラベル、有効期限ステッカーなど、仕向地のマーケットプレイスで要求されるすべての作業。
- 梱包材: ブランドロゴ入りメーラー、緩衝材、同梱物、ギフトカードなど、各ユニットと共に出荷されるもの。
これらのコストを、コストドライバーに適した方法でユニットに割り当てます。ベンダーコストと準備費用はユニットごとです。入庫運賃と関税は通常、重量、体積、または請求額に基づいて出荷内のユニット全体に割り当てられます。受取手数料は、パレットごとにそのパレット上のユニットに割り当てられる場合があります。
計算自体は単純ですが、それを継続するのは容易ではありません。売上高が100万ドルを超えるほぼすべての販売者に有効な解決策は、単一の「コストカタログ」を所有することです。新しい発注（PO）が発生するたびに、関連するすべてのSKUの揚地原価を再計算し、新しいユニットコストが受領したユニットの在庫レイヤーとなります。スプレッドシートが機能するのはある程度の規模までです。複数のフルフィルメントチャネルにわたって200以上のSKUを扱うようになれば、ソフトウェアが必要になります。
ステップ2：在庫が「今夜どこで眠っているか」を追跡する
マルチチャネル運営では、同じ物理的なSKUが同時に5つの異なる在庫状態で存在する可能性があります。
- 仕入先からの輸送中: 港で所有権が移転している可能性があるため、あなたの在庫ですが、まだ入庫はできません。
- 3PL在庫、販売可能: DTC、eBay、Walmart、Shopifyなどの注文をピックアップするための稼働在庫。
- Amazon在庫、販売可能（FBA）: Prime注文に利用可能で、補充制限にカウントされる在庫。
- Amazon在庫、留保（Reserved）: フルフィルメントセンター間の移動中、顧客の注文処理中、または在庫調整としてフラグが立てられたユニット。このバケツは補充システムからは見えませんが、間違いなくあなたの資産です。
- Amazon在庫、販売不可: 返品、破損、または期限切れで処分を待っているユニット。
これらの各状態は、貸借対照表上の補助科目、あるいは最低でも在庫台帳上のディメンション（属性）としてマッピングされるべきです。販売者がすべてを「在庫」という1行にまとめてしまうと、Amazonが21日間も動いていない80,000ドル分の留保在庫を抱え込んでいることに気づけなくなります。これは、会計上の盲点に隠された、現実のキャッシュフローの問題です。
特にFBA留保在庫については、少なくとも月に一度はAmazonの「在庫元帳レポート」および「FBA在庫管理」レポートと照合してください。数週間を過ぎても留保されたままのユニットは、通常、解決可能な配送ルートの問題を示しています。二度と現れない留保ユニットは、補填請求の対象となります。
ステップ 3：銀行の入金額ではなく、マーケットプレイスの決済報告書を照合する
eコマースの記帳を始めたばかりの人が犯す最大の過ちは、AmazonやShopifyペイメントからのまとまった入金額をそのまま「売上」として扱うことです。これは売上ではありません。マーケットプレイスが数十種類もの活動を相殺した後に残った「残金」に過ぎません。
典型的なAmazonの隔週の決済入金は、以下のような項目の代数和である可能性があります。
- 商品売上総額
- 購入者から回収した配送料収入
- ギフト包装料収入
- 購入者へのプロモーション割引（マイナス）
- 返金（マイナス）
- 販売手数料（マイナス）
- FBA配送代行手数料（マイナス）
- 月額保管手数料（マイナス）
- 長期保管手数料（マイナス）
- 納品代行サービス手数料（マイナス）
- 返送・所有権の放棄手数料（マイナス）
- 広告サービス料金（マイナス）
- 徴収および納付された売上税（パススルー）
- 留保金（当期はマイナス、解除時にプラス）
- 紛失または破損した商品の補填金（プラス）
ネットの入金額を「Amazon売上」として記帳してしまうと、これらの項目はすべて帳簿から消えてしまいます。売上は過小評価され、手数料はカテゴリー分けされず、売上原価（COGS）も適切なチャネルに紐付けられません。
正しいパターンは、決済報告書をインポートし、各手数料カテゴリーをそれぞれの費用勘定に記帳し、総売上高と返金を個別に記帳することです。eコマースに特化した記帳ツールの多くは、各決済を10〜30行の仕訳項目にまとめ、記帳時に入金額と正確に一致させることでこれを行います。これにより、入金はワンクリックで銀行口座と照合され、初めて真の総売上高、真の手数料負担、そしてチャネル別の収益性を把握できるようになります。
「Amazon留保金」という別の流動資産勘定を使用して、留保された資金を管理します。Amazonが後の決済で留保金を解除した際に、資金を「留保金」から「現預金」へと移動させます。これが、まだ自由にできないお金がすでに銀行にあるかのように装うのではなく、誠実な貸借対照表を維持する方法です。
初日から正確なマーケットプレイスの記帳を行っているかどうかが、自信を持って価格を引き上げ、ベンチャーデットの条件合意書を受け入れ、あるいは店舗を売却できるセラーと、納税期限の1週間前にパニックになりながら1年分の手数料を再構築するセラーを分ける境界線となります。
ステップ 4：年末に「幽霊売上原価（Phantom COGS）」を突き止める
幽霊売上原価とは、帳簿上の販売数と、物理的な在庫に基づく販売数との間のギャップのことです。これは主に以下の3つの要因から発生します。
3PL（外部倉庫）やFBAでの未記録の在庫減耗。 商品のカウントミス、ピッキング作業中の破損、またはフルフィルメントセンター間での移動中の紛失などが原因です。在庫管理システムでは1,000個あるはずなのに、倉庫の循環棚卸で940個しか見つからなかった場合、60個分の「幽霊在庫」が貸借対照表を膨らませ、売上原価を押し下げていることになります。この評価下げを記録するまで、作成されるすべてのレポートは誤ったものになります。
未処理の返品。 購入者が商品を返品し、マーケットプレイスが顧客に返金したものの、商品が倉庫に戻ってこなかったり、再販不能な状態で届いたりする場合です。在庫の増加や廃棄を記帳せずに売上の取り消しだけを記帳すると、その商品の原価レイヤーは永遠に失われたままになります。
原価レイヤーの乖離。 サプライヤーの変更、配送モードの切り替え、あるいは関税率の変更があった場合、実際の揚地原価（Landed cost）は発注書（PO）ごとに大きく変動する可能性があります。今年の価格で販売しているにもかかわらず、会計上で既存の在庫を昨年の原価で評価し続けていると、2四半期ほどは利益率が非常に良く見えますが、現実が追いついたときには利益が崩壊します。
解決策は、年末に実地棚卸を行い、帳簿上の在庫と比較して、その差異を修正する単一の仕訳を行うことです。もし調整額が在庫価値の10%を超えるようであれば、その原因は一時的なものではなくシステム的なものです。翌年により大きな調整を行うのではなく、コストカタログや3PLのワークフローといったプロセス面での改善が必要になります。
これを誤った場合の税務上の影響は小さくありません。期末在庫が過大評価されると売上原価が過小評価され、その結果、課税所得が膨らみます。50,000ドルの過小評価がある場合、22%の税率区分にいる利益の出ているセラーであれば、自営業税と合わせて連邦税の過払いは10,000ドルから18,000ドルに達することもあります。これは、倉庫が循環棚卸の結果を報告しなかったために、IRS（内国歳入庁）の懐に入ってしまった実質的な現金なのです。
月次決算ルーチンのサンプル
年間売上高50万ドルから500万ドルのセラーが行うべき、クリーンなマルチチャネル決算は1ページに収まります。
- 各マーケットプレイスの決済報告をインポートし、複数行の仕訳を記帳する。各総入金額を銀行口座と照合する。
- 3PLの請求書をインポートし、チャネルごとのフルフィルメント手数料を記帳する。
- FBA在庫元帳レポートを取得し、「留保中」「販売可能」「販売不可」の残高を帳簿と照合する。解消されない不足分については返金リクエストを行う。
- 3PLの循環棚卸または月末の在庫レポートを取得し、在庫システムと照合する。
- 加重平均法または先入先出法（FIFO）レイヤーを使用して、その期間の売上原価（COGS）を算出する。チャネル別の売上総利益率が想定範囲内であることを確認し、範囲外のチャネルがあれば調査する。
- その期間に受領した発注書（PO）について、揚地原価（Landed cost）の更新を反映させる。
- 解除されたAmazon留保金を「留保金」勘定から「現預金」へ移動させる。
システムが連携されていれば、このルーチンは半日の集中作業で済みますが、連携されていなければ数日間の苦痛を伴う作業になります。その見返りは、「Walmart、Amazon、Shopifyのそれぞれにおける、このSKUの本当の利益率はいくらか？」という問いに、途方に暮れることなく即座に答えられるようになったときに現れます。
プレーンテキストによる帳簿管理がマルチチャネルの混乱を解消する
マルチチャネルEコマースに深く関わるほど、コードと同じようにクエリやスクリプト実行、監査、バージョン管理が可能な会計システムが必要になります。販売手数料、マーケットプレイスのマッピング、着地原価（ランデッドコスト）の算出方法、評価減のポリシーなどは、毎年見直しが必要となる重要な判断事項です。これらは、クローズドソースの元帳に含まれる脆弱な勘定科目表ではなく、より堅牢なシステムで管理されるべきです。
最初の1商品から正確な在庫帳簿を維持する
マルチチャネルの規模拡大を乗り越えるセラーは、銀行の入金記録だけでなく、ビジネスの物理的、財務的、運用的な現実を帳簿に反映させている人々です。Beancount.ioは、プレーンテキストによるバージョン管理可能な会計を提供し、チャネル別の損益（P&L）、着地原価、在庫状況を透明化し、検査可能にします。ブラックボックス化したレポート、ベンダーロックイン、年末の予期せぬ照合作業などはもう不要です。無料で始める をクリックして、開発者や財務に精通した実務担当者が、なぜ自身のコマーススタックにプレーンテキスト会計を採用しているのか、その理由を確かめてください。