Amazonセラーの平均損失は、未請求の払い戻しや照合エラーにより、毎年1,500ドルから3,000ドルに達します。Amazon、Shopify、Walmart、eBayを同時に運営するマルチチャネルセラーの場合、決済レポートを誰も監視していなければ、未照合の未達入金（deposits-in-transit）が50万ドルを超えることもあります。それにもかかわらず、多くのEコマース創業者は在庫会計を二の次として扱っています。しかし、年度末の監査において、貸借対照表が物理的な実態から数万ドルも乖離していることが判明するのです。
問題は洗練されていないことではありません。現代のEコマース運営者は、複数の倉庫、サードパーティ・ロジスティクス（3PL）プロバイダー、フルフィルメント by Amazon（FBA）フルフィルメントセンター、輸送中の在庫、そして売上金が営業口座に入金される前に差し引かれるマーケットプレイス手数料を巧みに操っています。これらすべての接点は、会計記録が真実から逸脱する機会となります。このガイドでは、それらを一致させる方法を解説します。真のランデッドコスト（揚地原価）の算出方法、分散した拠点間での在庫追跡方法、マーケットプレイスの決済を一行ずつ照合する方法、そして会計士が毎年1月の決算処理で見つける「ゴースト売上原価」の調整を防ぐ方法について説明します。
なぜEコマースの在庫会計は根本的に異なるのか
従来の小売業の在庫会計は、シンプルなモデルを想定しています。商品を仕入れ、一つの倉庫に保管し、一つのチャネルで販売し、顧客が支払った時に売上原価を認識するというモデルです。しかし、現代のD2C（Direct-to-Consumer）ブランドにおいては、このモデルのほぼすべての要素が通用しません。
典型的な中規模Eコマース企業は、メイン倉庫に2,000ユニット、複数のFBA地域フルフィルメントセンターに1,500ユニット、Shopifyの注文を処理する3PLに1,000ユニット、そしてベトナムのサプライヤーから海上輸送中の在庫がさらに500ユニットあるかもしれません。これらすべてのユニットは物理的な場所が異なり、（どの出荷便で届いたかによって）原価基準が異なり、販売前に損傷、紛失、または古くなる確率も異なります。
物理的な複雑さに加えて、財務的な複雑さも重なります。Amazonは、セラーに入金する前の総売上高から、販売手数料、FBA配送代行手数料、在庫保管手数料、長期保管余剰金、廃棄手数料を差し引きます。MCF（マルチチャネルフルフィルメント）を利用するShopifyの注文には、全く異なる手数料体系が適用されます。各マーケットプレイスの決済サイクルも異なります。Amazonは通常14日ごと、Shopifyは毎日、Walmartは月2回であり、各決済レポートには、営業用銀行口座と照合し、正しい勘定科目に振り分けるべき数百から数千のラインアイテムが含まれています。
その結果、小規模な小売業者には有効な単純な記帳のショートカット（純入金額を収益として記録する、送料を費用として処理する、FBA手数料を「支払手数料」として一括りにするなど）が、財務諸表の正確性を静かに損なうことになります。創業者が「なぜ売上総利益率が下がり続けているのか？」と疑問を持つ頃には、その答えは1年間にわたる誤分類の積み重ねの下に埋もれてしまっています。
ランデッドコスト（揚地原価）：何よりも先に原価側を正しく把握する
Eコマース運営者が在庫会計に関して行う最初で最も影響の大きい決定は、商品の「原価」に何を含めるかです。一般に公正妥当と認められる会計原則（GAAP）では、在庫は販売地点に到達するまでにかかった全費用を含んだ価格で計上することが求められます。これには以下が含まれます：
- 仕入先請求価格（最も明白な構成要素）
- 国際運賃（起点からの海上、航空、またはトラック輸送）
- 関税およびタリフ（国や統計品目番号によって、多くの場合5〜25%）
- 輸入通関手数料
- 輸送保険
- 港から倉庫までの国内運賃
- 荷役、パレタイズ、準備費用
- 3PLへの入庫手数料
これらをまとめたものが**ランデッドコスト（揚地原価）**と呼ばれ、多くの輸入品において、仕入先請求価格のみよりも15〜30%高くなります。仕入価格のみを売上原価（COGS）として扱う創業者は、体系的に売上総利益を過大評価し、補充の意思決定において原価を低く見積もり、最終的には監査人が運賃費用を再分類する年度末に、手痛い在庫の評価替えに直面することになります。
SKU間での共通費用の配賦
難しいのは、運賃が重要であることを認識することではなく、1回の出荷に含まれる複数のSKUに対して、1枚の運賃請求書をどのように分割するかを決定することです。一般的な配賦方法には次の4つがあります：
- ユニット数による配賦： 運賃総額をユニット数で均等に割ります。単純ですが、ユニットのサイズや価値が大きく異なる場合は不適切です。
- 重量による配賦： 各SKUの物理的な重量に基づいて配賦します。料金が重量や容積に相関する海上運賃に最適です。
- 容積（立方メートル）による配賦： コンテナのスペースを不当に占有する、かさばる軽量商品に重量よりも適しています。
- 価格による配賦： 総額に対する各SKUの請求金額の割合に基づいて配賦します。概念的に明快であり、関税が通常どのように計算されるかと一致します。
ほとんどの輸入業者にとって実用的で有効な妥協案は、関税には価格ベースの配賦（関税自体が価格に対するパーセンテージであるため）を用い、運賃には容積ベースの配賦（配送業者がスペースに対して課金するため）を用いることです。コストカテゴリごとに1つの方法を選択して文書化し、一貫して適用してください。監査人は、どの方法を選んだかよりも、一貫性があるかどうかを重視します。
帳簿への陸揚原価の記録
陸揚原価（Landed Cost）の仕訳パターンは単純ですが、間違いやすいものです。たとえば、サプライヤーからの請求額が50,000ドル、運賃が8,000ドル、関税が3,500ドル、通関業者の手数料が1,000ドルの出荷を受け取ったとします。正しい仕訳は以下の通りです。
借：在庫（Inventory） $62,500
貸：買掛金（Accounts Payable） $50,000 （サプライヤー）
貸：未払運賃（Accrued Freight） $8,000 （運送業者）
貸：未払関税（Accrued Duties） $3,500 （税関）
貸：未払手数料（Accrued Brokerage） $1,000 （通関業者）よくある間違いは、8,000ドルの運賃を「在庫」ではなく「運賃費用」として借方に計上してしまうことです。これは、本来在庫として資産化され、商品が売れた際に売上原価（COGS）として計上されるべきコストを、即座に費用として認識してしまうことを意味します。四半期を通じると、このミスによって在庫が6桁（数十万ドル単位）で過小評価される可能性があります。
拠点別の在庫追跡：マルチ倉庫の現実
1ユニットあたりの陸揚原価が確定したら、次の課題はそれらのユニットが物理的にどこにあるかを追跡することです。マルチチャネル販売者の場合、1つのSKUが以下の場所に同時に存在する可能性があります。
- 自社の倉庫またはオフィス
- ShopifyのD2Cチャネルを担当する国内の3PL（サードパーティ・ロジスティクス）
- 複数のAmazon FBAフルフィルメントセンター（時には30拠点以上）
- Walmart Fulfillment Services (WFS) の倉庫
- サプライヤーからの輸送中の商品
- 「予約済み（Reserved）」在庫：注文に割り当てられているが、まだ出荷されていないユニット
各拠点には独自の勘定科目（補助科目）が必要であり、それによって貸借対照表の残高を実地棚卸数と照合できるようになります。「在庫」を一つの大きなバケツとして扱うことは、監査上の乖離を招く最も一般的な原因です。ある場所でのエラーが別の場所でのエラーを相殺してしまい、事後調査が不可能になるからです。
FBA予約在庫の罠
Amazonの在庫ダッシュボードでは、「販売可能（Fulfillable）」ユニット（倉庫にあり出荷可能な状態）、「予約済み（Reserved）」ユニット（顧客の注文に割り当てられた、フルフィルメントセンター間を移動中、または一時的な処理状態）、「納品中（Inbound）」ユニット（販売者からFBAへ輸送中）、「調査中（Researching）」ユニット（Amazonが不一致を調査中）、「販売不可（Unfulfillable）」ユニット（破損、欠陥、または滞留）を区別しています。
会計上、これらはすべて依然としてあなたの在庫であり、陸揚原価で貸借対照表に計上されますが、それぞれリスクプロファイルが異なります。「調査中」のユニットは、しばしば在庫の減損や補填の対象となり、「販売不可」のユニットはほぼ確実にそうなります。すべてを一つの「FBA在庫」勘定にまとめてしまう販売者は、数千ドルの在庫が60日間も静かに滞留し、補填請求の期限が迫っているというシグナルを見逃してしまいます。
よりクリーンな勘定科目体系では、FBA在庫を少なくとも3つの補助科目に分割します。
- 在庫 — FBA 販売可能
- 在庫 — FBA 輸送中/予約済み
- 在庫 — FBA 販売不可/調査中
これにより滞留分析が容易になり、補填請求はパニック状態の年度末の作業ではなく、日常的な月次のプロセスへと変わります。
納品中および輸送中の在庫
支払いは済んでいるが、まだ受け取っていない在庫も貸借対照表のどこかに存在する必要があります。最もクリーンな処理は、専用の 「輸送中在庫（Inventory in Transit）」 勘定を使用することです。サプライヤーが出荷したときに借方に記入し、商品が到着したときに貸方に記入（同時に「在庫 — 倉庫」を借方に記入）します。輸送中の商品を分けて管理することで、「まだ所有していない商品を販売可能な在庫として認識してしまう」ことと、「太平洋を渡るのに8週間かかる商品の存在を忘れてしまう」という2つのミスを防ぐことができます。
マーケットプレイスの精算：現金が隠れている場所
創業者が陥りがちな勘違いに、「売上はAmazonからの銀行入金額の合計に等しい」というものがあります。実際はそうではありません。Amazonの入金額は、総売上から紹介料、FBA配送代行手数料、FBA保管手数料、FBA納品輸送費用、返品、返金、チャージバック、広告費（Amazonの保留システムに登録している場合）、プロモーション割引、その他多くのカテゴリーを差し引いた 純額 です。入金純額のみを売上として記録すると、損益計算書は役に立たなくなります。
精算照合の実際のプロセス
適切なマーケットプレイスの精算照合には3つのステップがあります。
- 精算レポートの分解。 Amazonの精算レポートは、セラーセントラルからCSVまたはXML形式でダウンロードできます。これには、精算期間内のすべてのトランザクションが含まれており、それぞれにタイプ（注文、返金、FBA在庫手数料、サービス手数料、調整など）がタグ付けされています。
- 各トランザクションタイプを勘定科目にマッピング。 注文は「総売上」へ、紹介料は「マーケットプレイス販売手数料」へ、FBA配送代行手数料は「配送代行費」へ、保管手数料は「保管料」へ、返品は「売上控除」として、返金された手数料は「費用のマイナス」として流れます。
- 純合計額を銀行入金額と照合。 精算レポート内のすべての構成要素の合計は、営業口座に記帳された現金の入金額と一致する必要があります（数セントの端数調整の範囲内）。一致しない場合は、トランザクションタイプの欠落や手数料の分類ミスが存在します。
これを機能させるための規律は、手数料を売上総利益（グロスマージン）の中に圧縮（相殺）させないことです。紹介料、配送代行手数料、保管手数料は、貢献利益のウォーターフォールにおいて売上総利益の後にくる変動費です。これらを売上総利益より上に置いてしまうと、ユニットエコノミクスが同一であっても、Amazonの粗利益がShopifyよりも悪く見えてしまい、創業者がチャネル構成の判断を下すために必要な比較可能性が損なわれてしまいます。
「差額の切り捨て」アンチパターン
記帳担当者が決済の照合を円単位（あるいはセント単位）で正確に一致させられないとき、その差額を汎用的な「マーケットプレイス調整」勘定に放り込んでしまうという、誘惑に満ちた近道が存在します。4つの販売チャネルを12ヶ月運用すれば、こうした小さな切り捨ては、通常、年間で数百万円規模の不足額に膨れ上がります。これを防ぐための規律は、「すべての決済は入金額との差額を5ドル（あるいは相当額）以内に収めて照合しなければならず、それを超える不一致は、月次決算を締める前に調査し、記録を残さなければならない」という厳格なルールです。紛失または破損したFBA在庫の補填請求には通常60日の期限があるため、原因不明の不一致は、本来得られたはずの補填の機会を見逃していることを意味します。
年末の「幽霊売上原価」：マイナス在庫問題
最も厄介な年末の在庫問題は、NetSuiteユーザーが「ファントム（幽霊）COGS（売上原価）」と呼ぶものから生じます。これは、システム上の手元在庫がゼロまたはマイナスの状態で、会計システムが売上（および対応する売上原価の仕訳）を記録したときに発生します。システムは実際の売上原価を計上できないため、プレースホルダー（ゼロ、あるいは過去の古い原価）を計上します。数週間、あるいは数ヶ月後、在庫調整によってようやく在庫数がプラスに戻ると、システムは本来の売上とは無関係な原価を用いて、帳尻を合わせるための「追及売上原価」を計上します。
こうした「幽霊調整」は、一年を通じて静かに蓄積されます。12月になる頃には、損益計算書の年初来の売上原価が数万ドル単位で乖離し、売上総利益の傾向は不安定になり、貸借対照表上の在庫残高は実際の棚卸数からいつの間にか大きく離れてしまいます。
そもそもマイナス在庫を防ぐには
構造的な対策は、システム内で在庫がマイナスにならないようにすることです。具体的には以下の通りです。
- 入庫出荷の迅速な照合。 FBAが荷物を受け取ると、セラーダッシュボードには受領済みのユニット数が表示されますが、担当者が会計システムに受領を記録しない限り、システム上はそのユニットはまだ輸送中とみなされます。
- マーケットプレイスのフルフィルメントをリアルタイムで計上。 A2X、Webgility、Link My Books、Entriwiseなどのツールを使用して、Amazonと会計システムを毎日同期させることで、売上が在庫数を上回ってしまう数週間のラグを防ぐことができます。
- 混合在庫（Commingled Inventory）の慎重な扱い。 Amazonの混合在庫プログラム（自社のSKUが他社の同一SKUとプールされる仕組み）は、物理的な実態に問題がなくても、システム上でマイナス在庫のように見えるタイミングの問題を引き起こします。最も明快な解決策は、品質管理が重要なSKUについては混合在庫をオプトアウトすることです。
期末棚卸と帳尻合わせ
日々の管理が完璧であっても、帳簿と物理的な実態が一致しているかを確認する唯一の方法は、年末の棚卸です。棚卸はすべての保管場所で行う必要があります。
- 自社倉庫での実地棚卸
- Amazonセラーセントラルからの在庫レポートのダウンロード（在庫元帳レポート）
- 3PL（サードパーティ・ロジスティクス）ポータルからの在庫レポートのダウンロード
- 仕入先およびフォワーダーからの輸送中在庫の確認
合計額は貸借対照表の在庫勘定と一致する必要があります。一致しない場合、その差額を調査し、説明がつかないものは「棚卸減耗損」として振替伝票で落とします。在庫価値の2%を超える減耗は、単なる不一致ではなく、プロセス上の問題（盗難、3PLでのカウントミス、あるいは継続的なFBA補填漏れ）を示唆しています。
原価計算手法：先入先出法（FIFO）、総平均法、そしてなぜ多くのECセラーが総平均法を選ぶべきなのか
GAAP（一般に認められた会計原則）では、主に3つの在庫原価計算手法が認められています：先入先出法（FIFO）、後入先出法（LIFO）、および総平均法です。LIFOは米国以外ではほとんど使用されず、国際財務報告基準（IFRS）とも互換性がないため、現実的な選択肢はFIFOか総平均法になります。
**FIFO（先入先出法）**は、最も古い在庫原価を次に販売されるユニットに関連付けます。コストが安定している時期に最も正確な売上総利益を算出できますが、システムが各バッチのコストを個別に追跡し、最も古いバッチから順に売上を割り当てる必要があります。
総平均法は、新しい荷物を受領するたびに、ユニットあたりの平均単価を再計算します。数学的に単純で、（物理的なバッチの区別がつかない）FBAの混合在庫とも相性が良く、ほとんどの現代的なEC会計ツールのデフォルト設定となっています。
中規模の販売量で消費財を販売するほとんどのD2Cブランドにとって、総平均法が正解です。正確な財務諸表を作成するのに十分な精度があり、自動化が容易で、マルチチャネル運用に特有の入出庫のタイミングのズレ（ノイズ）にも強いからです。FIFOによる複雑さを導入する価値があるのは、製品原価の変動が非常に激しい場合（リチウム、半導体、特定の農産物など）や、コンプライアンス上の理由でロットや消費期限を追跡する必要がある場合に限られます。
チャネル別収益性：正確な管理がもたらす最終的な成果
これらすべての規律が重要である理由は、正確なチャネル別損益計算書（P&L）なしには、ECビジネスにおいて適切な成長判断を下せないからです。在庫をFBAにより多く投入すべきか、それとも3PLか？ Shopifyチャネルは本当にAmazonより利益率が高いのか、それとも帳簿上でFBA手数料が誤った勘定科目に隠れているためにShopifyが良く見えているだけなのか？ 卸売がD2Cの赤字を補填しているのか、あるいはその逆か？
これらの問いに答えるには、売上、返品、売上原価、フルフィルメント費用、マーケットプレイス手数料、および広告費をチャネルごとに分離した勘定科目表が必要です。現代のほとんどの会計プラットフォームは、クラス、場所、部門、またはタグを組み合わせることでこれをサポートしています。具体的な仕組みはツールによって異なりますが、原則は同じです。すなわち、すべての取引に発生元のチャネルをタグ付けし、損益計算書をチャネル別にフィルタリングできるようにすることです。
その成果は多大です。クリーンなチャネル別P&Lを維持している経営者は、自身の「最高の」チャネルが実は貢献利益ベースでは最悪であったり、見過ごされていた小さなチャネルが運転資本1ドルあたりで莫大なキャッシュフローを生み出していたりすることに日常的に気づかされます。こうした洞察は、基礎となるデータがクリーンであるとき、つまり揚地原価が正しく割り当てられ、決済が正確に照合され、幽霊売上原価が数値を汚染していないときにのみ得られるのです。
初日から在庫帳簿を完璧に管理する
正確な在庫会計を行えるかどうかは、ビジネスの実態を把握できているか、あるいは単なる推測に留まっているかの分かれ目となります。倉庫、フルフィルメントセンター、マーケットプレイスへと事業が拡大する中で、帳簿と物理的な実態を一致させ続ける唯一の持続可能な方法は、透明性が高く、監査可能で、バージョン管理されたシステムを導入することです。Beancount.io は、まさにそのために設計されたプレーンテキスト会計を提供します。すべての取引は人間が判読可能で、差分（diff）を比較できる記録として保存されます。勘定科目の階層構造は複数拠点の在庫管理にスムーズにマッピングされ、履歴データはベンダーロックインなしに永久にユーザーの資産となります。無料で始める 複雑なマルチチャネル・オペレーションを運営する財務チームが、なぜプレーンテキスト会計に移行しているのか、その理由をぜひ体験してください。