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コマース会計のベストプラクティス」はひび割れた基盤の上に成り立っています。WooCommerceストアも同じ壁にぶつかります。私たちのWooCommerce簿記ガイドは、そのプラットフォーム版について説明しています。

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

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

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

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

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

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

これらの決定が抽象的に聞こえる場合、実際の同期ツールでは次のようになります。タブのページです。LedgerPortの同期設定画面には7つのタブがあります。一般、注文、商品、顧客、支払い、税金、その他。そして、それぞれにこのセクションからの決定が含まれています。支払いゲートウェイは支払いタブにあり、ストアで検出された各ゲートウェイには独自の決済口座があり、設定していないすべてのもののフォールバックとしてデフォルトの決済口座があります。売上税は税金タブにあり、選択したQuickBooksの負債口座に投稿されます。各注文の形式（売上伝票または請求書）は、注文タブのドロップダウンです。

そのページの2つのプロパティがベストプラクティス記事にとって重要です。第一に、ドキュメント自体のFAQによると、ほとんどのストアは同期設定を一切変更せずに同期を開始できるとのことです。デフォルトは合理的であるため、構造は前提条件のプロジェクトではありません。第二に、設定の変更は将来の同期にのみ適用されます。すでに投稿したものは遡って書き直されることはないため、後で決定を調整しても、クローズされた期間を破損することはありません。つまり、この記事のプラクティスは野心的ではありません。それらはタブです。

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

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

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

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

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

知っておくと良いこと：最新の同期ツールでは、サマリーエントリは手動で構築するものではなく、名前付きの選択可能なモードです。LedgerPortはそれをデイリーサマリーと呼んでいます。1日あたり1つの仕訳伝票で、その日のすべての注文を集計します。これは、同期設定 » 注文の注文ごとのオプション（売上伝票、請求書）と同じドロップダウンから選択されます。ベンダー自身のガイダンスによると、転換点は1日あたり約100件以上の注文です。それ以下の場合、注文ごとのレコードは完全に管理可能であり、QuickBooksで注文レベルの詳細が得られます。注文ごと対要約は、ツールから継承する哲学ではなく、選択する設定です。

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

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

ツールと同期している場合は、その前にゼロステップを追加します。同期ログをエラーでフィルタリングします。LedgerPort のすべての同期試行には、同期済み、エラー、保留中、または一時停止中のいずれかのログステータスがあり、監査ログをステータス = エラーでフィルタリングすることは、存在する最速の事前照合チェックです。2週目に同期に失敗した注文は、総収益の穴であり、ステップ3では決して検証できません。今検出されれば、それは修正と再同期です。照合中に検出されれば、それは存在しなかった数値を探す1時間の作業です。締め処理前に検出されたエラーは、締め処理中に回避される仕訳のギャップです。

月に500件以上の注文を手動で行っている場合、ステップ1から3には4時間から8時間かかります。月に2,000件以上の注文の場合、計算が完全に成り立たなくなります。エントリを見逃したり、数値を転置したり、月末には現実からますます乖離していく「ほぼ正確」な照合で終わることになります。自動化ツールは、支払いから総収益への変換を自動的に処理することで、これを1時間未満に短縮します。個々の支払い、手数料、返金を預金に照合する完全な手動ウォークスルーは、QuickBooks で Shopify の支払い明細を照合する方法のガイドに記載されています。

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

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

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

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

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

「正しいこと」のための2番目のテストがあり、それは評価するあらゆるツールに適用する価値があります。自動化はあなたの会計方針を採用しますか、それとも独自のものを課しますか？LedgerPort では、ほとんどのツールがハードコードしている2つのポリシーが1つの画面の設定になっています。最初のものは同期方法です。注文が個別の売上伝票として投稿されるか、未払いの売掛金を持つ請求書として投稿されるか、または日次要約仕訳エントリとして投稿されるかは、[同期設定] » [注文] で選択できるため、注文ごとまたは要約された元帳は、自動化されるだけで、あなたのアーキテクチャのままです。2番目は収益認識の時点です。同期トリガーは、支払いステータスと履行ステータスのマトリックスであり、両方の条件が満たされた場合にのみ注文が投稿されます。したがって、履行時に収益を認識するB2Bストアと、支払い時に収益を認識するDTCストアは、同じ画面で異なるチェックボックスを設定し、それぞれがポリシーに一致する元帳を取得します。

そして、前のセクションとの正直なつながり：構造なしでは、これのどれも機能しません。ゲートウェイからクリアリング口座へのマッピングは、[同期設定] » [支払い] にあり、自動化が、総勘定元帳セクションで構築した手数料分離アーキテクチャに投稿されることを意味します。それはその作業を置き換えるのではなく、それを運用可能にします。ツール設定として表現された会計方針：それが、あらゆる自動化に課すべき基準です。

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

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

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

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

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

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