5つ以上のEコマース会計ベストプラクティス（詳細な内訳）

日曜日の夜11時。あなたは2時間かけて、Shopifyの入金レポートとQuickBooksの預金との間の1,600ドルの不一致を見つめています。CSVを2回再エクスポートしました。日付範囲を3回確認しました。銀行によると、今月口座には14,200ドルが入金されています。Shopifyによると、あなたは15,800ドルを売り上げました。QuickBooksはサードパーティの数字を持っています - 14,740ドル - そしてそれがどこから来たのか全く分かりません。

そこであなたは、まともな人間なら誰でもするように、「Eコマース会計のベストプラクティス」をGoogleで検索します。そして、多くの異なる企業が公開している同じ記事を見つけ、同じアドバイスを得ます。個人の財務と事業の財務を分離する。クラウド会計ソフトウェアを使用する。売上原価を追跡する。毎月照合する。

あなたはすでにこれらすべてを行っています。それでも帳簿は間違っています。そして、ある時点であなたは静かな嘘を信じ始めます：Eコマース会計は本質的に厄介なものであり、ほぼ完璧で十分なのです。

そうではありません。問題は、あなたがベストプラクティスを無視していることではありません。問題は、誰もが公開しているEコマース会計のベストプラクティスが間違っていること、あるいは、それらは従来の小規模ビジネスにとっては正しいものの、収益を徴収するプラットフォームとそれを記録するソフトウェアが根本的に異なる言語を話すビジネスには適していないことです。

誰も言及しないEコマース会計のベストプラクティスリストにおける構造的な問題

その1,600ドルのギャップで実際に起こっていることは次のとおりです。あなたのShopifyストアは先月、総売上15,800ドルを処理しました。しかし、Shopifyは15,800ドルを送金しませんでした。お金があなたの銀行口座に入る前に、Shopifyは決済手数料620ドル、7件の返品注文に対する返金480ドル、Shopifyのサブスクリプションとアプリの料金340ドル、チャージバック調整160ドルを差し引きました。あなたの銀行に届いたのは純額：14,200ドルでした。

あなたの会計ソフトウェアはこれらのことを何も知りません。QuickBooksは14,200ドルの入金を見て、それを記録しました。しかし、14,200ドルはあなたの収益ではありません。あなたの利益でもありません。それはあなたの収益から4つのカテゴリーの控除を差し引いたもので、それらすべてを不明瞭にする単一の数字にまとめられています。

これが構造的な問題です。Eコマースプラットフォームは純額の支払いを行います。会計ソフトウェアは総取引を期待します。両者の間にはネイティブな翻訳レイヤーがありません。そして、あなたがそれを作成するまで、「Eコマース会計のベストプラクティス」はひび割れた基盤の上に構築されています。

「毎月照合する」と言われた場合、会計ソフトにはすでに照合すべき正しいデータがあると想定されています。しかし、実際にはそうではありません。「売上原価を正確に追跡する」と言われた場合、利益率の計算が意味を持つには十分な売上高の数字があると想定されています。しかし、実際にはそうではありません。アドバイスが間違っているわけではありません。ただ不完全なのです。本当に重要な部分が抜け落ちています。

実際に重要な勘定科目表と手数料分離の決定

すべてを変える最初のプラクティスは、退屈に聞こえるかもしれませんが、会計勘定科目を正しく設定することです。デフォルトのQuickBooksの会計勘定科目ではなく、プラットフォームを経由してお金が銀行に届くビジネスのために設計されたものです。

最も重要な単一の決定は、Shopify Paymentsの残高をQuickBooksの銀行口座として扱うことです。なぜなら、それが銀行口座だからです。Shopifyはあなたの資金を保持し、バッチ処理し、スケジュールに従って払い出す — まさに銀行口座のように。QuickBooksで「Shopify Payout Funds」という名前の口座を、タイプを銀行、詳細タイプを当座預金に設定して作成すると、$14,200の入金が謎ではなくなります。それはある口座（Shopify）から別の口座（あなたの銀行）への振替になります。総売上高、手数料、返金 — これらすべてはShopify口座の中に存在し、そこに属します。

2番目の決定は、手数料の分離です。ほとんどの店舗オーナーは、Shopifyの決済手数料を、記録する場合でも、単一のまとめての費用として記録します。しかし、すべての支払いには少なくとも3つの異なる手数料カテゴリが隠されています：決済手数料（取引ごとのスワイプコスト）、プラットフォーム手数料（Shopifyのサブスクリプション、アプリの料金）、および返金関連の調整。それぞれが異なる費用口座に属するのは、それらが異なるように動作し、異なるようにスケールし、あなたのビジネスについて異なることを教えてくれるからです。

割引と返金のための控除対象収益勘定科目も必要です。返金は費用ではありません — それは収益の減少です。それを費用として記録すると、総収益と費用合計の両方が膨れ上がり、実際の利益率が見えなくなります。返金用の控除対象収益勘定科目と割引用の控除対象収益勘定科目があれば、総収益は真実になり、純収益は計算可能になります。

総勘定元帳の仕訳と月次締めの実態

ほとんどの店舗オーナーを驚かせるプラクティスがあります：おそらく、ShopifyからQuickBooksへすべての個々の取引を同期すべきではありません。

月500件の注文を行っている場合、各注文を同期すると、QuickBooksに500件の個別のエントリが作成されます。さらに、関連する手数料エントリ、税金エントリ、返金エントリも追加されます。QuickBooksは遅くなり、レポートの生成に時間がかかります。ファイルを確認するのに時間がかかるため、公認会計士の料金も高くなります。そして皮肉なことに、その詳細さが帳簿をより正確にするのではなく、使いにくくしているのです。

より良いアプローチは、集計された仕訳伝票です。これは、期間内のすべての取引を1つのエントリにまとめる、日次または週次の集計です。1つのエントリで、その日の総売上、手数料、返金、徴収した税金、および純支払い額が記録されます。帳簿はクリーンに保たれ、レポートは高速に実行され、数字は銀行の預金と一銭単位で一致します。

これは、経験豊富なeコマース会計士のほとんどが推奨する方法であり、LedgerPortのようなツールが自動的に生成するものです。ただし、取引量が十分に少ない場合は手動で行うこともできます。問題は、「十分に少ない」があなたのストアに当てはまるかどうかです。これは、月次締め処理につながります。

記事で「毎月照合する」ように指示されている場合、eコマースストアでは実際には次のようになります。

1. その月のShopifyの支払いレポートをプルします。これは、すべての支払いとその内容を示しています。
2. 各支払いを銀行口座の預金と照合します。各支払いには、1〜3営業日以内に対応する預金があるはずです。
3. 各支払いに対する総額（売上、手数料、返金）が、個別のエントリまたは集計された仕訳伝票としてQuickBooksに正しく記録されていることを確認します。
4. QuickBooksのShopify支払い資金勘定をゼロに照合します（または、Shopifyが輸送中の資金を保持している場合は、現在の保留残高に照合します）。
5. 損益計算書を実行し、総収益、純収益、および手数料の合計がShopify管理ダッシュボードと一致することを確認します。

月500件以上の注文を手動で行っている場合、ステップ1から3には4〜8時間かかります。2,000件以上の注文になると、計算が完全に成り立たなくなります。エントリを逃したり、数字を転記したりして、毎月「ほぼ完了」の照合で四半期ごとに現実からさらに乖離していきます。自動化ツールは、支払いから総額への変換を自動的に処理することで、これを1時間未満に短縮します。

手動での調整が必要な時を知り、適切なものを自動化する

すべてのeコマース会計ベストプラクティス記事は、会計を自動化するように指示しています。しかし、具体的に何を、いつ自動化するかを教えてくれるものはほとんどありません。

手動のeコマース簿記には限界があり、それはほとんどの人が考えるよりも低いです。月200〜300件の注文になると、トランザクションの手動分類、支払い照合、手数料照合にかかる時間的コストが、自動化ツールのコストを上回り始めます。月500件以上の注文になると、手動照合はほぼ確実に時間あたりの最も高価な項目になります。ただし、コストは請求書ではなく、あなたの時間の中に埋もれているため、目には見えません。

不適切な照合業務は、時間だけでなく、収益も失わせます。業界データによると、不十分な照合は、追跡されていない手数料、見逃されたチャージバック、誤分類された返金を通じて、売上の2〜3％を静かに漏洩させる可能性があります。年間収益100万ドルの店舗では、これは見えない損失で2万〜3万ドルに相当します。お金が盗まれたからではなく、帳簿が不一致を捉えられなかったからです。この数字は、Shopifyストアオーナーの大多数が犯している7,500ドルの間違いでカバーした内容を反映しています。この間違いを犯すことのコストは、ほとんどのオーナーが認識しているよりも速く複利で増加します。

しかし、「すべてを自動化する」というのは間違ったアドバイスです。重要なのは、入金から総売上への変換を自動化することです。つまり、14,200ドルの純入金を、総売上15,800ドル、処理手数料620ドル、返金480ドル、プラットフォーム料金340ドル、チャージバック調整160ドルといった構成要素に分解することです。この変換は、退屈で、エラーが発生しやすく、構造的に反復的です。実際に変化をもたらすのは、この自動化です。

メールマーケティングや在庫の再注文を自動化することは有用です。入金から総売上への変換を自動化することは、基盤となります。これがなければ、ビジネスの他のすべての財務プロセスは不完全なデータで機能することになります。その変換レイヤーが実際にどのように機能するかを、正確に確認できます。

「Eコマース会計のベストプラクティス」の皮肉

あなたは、やるべきことのリストを探してこの記事にたどり着きました。財務を分離する、QuickBooksを使用する、売上原価を追跡する、毎月照合する—あなたはそれらのリストを見たことがあるでしょう。ブックマークしたかもしれません。すべてチェックしたかもしれません。それでも、日曜日の夜に帳簿が1,600ドルもずれていたかもしれません。

皮肉なことに、Eコマースの照合の失敗を防ぐ実際の対策は、誰の標準的なリストにも載っていません。それらは構造的な決定です—勘定科目表をどのように設定するか、プラットフォームの入金をどのように扱うか、概要エントリを使用するか、トランザクションごとの同期を使用するか、そしていつ手作業での入金変換をやめるか。これらは華やかではありません。リスト記事の見出しにはなりません。しかし、それらは、他のすべてのEコマース会計のベストプラクティスを実際に機能させる基盤となります。

その1,600ドルのギャップは謎ではありませんでした。それは、処理手数料620ドル、返金480ドル、プラットフォーム料金340ドル、チャージバック調整160ドルでした—すべて、お金が銀行に届く前に差し引かれ、会計ソフトウェアのどこにも記録されていませんでした。それを理解すれば、修正は機械的です。変換レイヤーの設定—適切な勘定科目表を手動で行うか、LedgerPortのようなツールで自動化するか—は、合わない数字を眺めて過ごすもう一つの日曜日の夜よりも短い時間で済みます。

無料で始めましょう。最初の1ヶ月の照合が自動的に行われるのを確認してください。