Eコマースの勘定科目表：悪いマッピング決定をしない方法

新しいShopifyクライアントを担当します。QuickBooks Onlineで勘定科目表を作成します。5つのカテゴリ、適切な補助勘定、標準的な規則に従った勘定科目番号付けを行います。Shopify連携を接続します。すべてが書類上は正しく見えます。

そして最初のShopifyの受取金が届きます。

Shopifyは銀行に14,200ドルを入金しましたが、QuickBooksにはShopifyの収益が15,800ドルと表示されています。Shopifyダッシュボードは総売上が16,100ドルと報告しています。同じ月の活動なのに、3つの異なる数字が表示され、どれも一致しません。あなたは4時間をかけてその差額を追跡します。最終的に、手数料が銀行振込として記録されていること、返金が正しい勘定科目に計上されていないこと、税金徴収額が収益ではなく収益勘定に入っていることなどを発見します。勘定科目表に不足があったわけではありません。ただ、Shopifyがお金を実際に動かす方法に合わせて作られていなかっただけなのです。

ほとんどの勘定科目表ガイドが基づいている誤った仮定は、「適切なカテゴリに適切な勘定科目があれば、照合はうまくいく。毎月作業するだけだ」というものです。Shopifyの場合はそうではありません。勘定科目名と番号付けは基本的な要件です。Shopifyの帳簿が照合できるかどうかは、勘定科目表がShopifyの資金の支払い方法、つまり総収入ではなく純受取金として、アーキテクチャ的に互換性があるかどうかにかかっています。5つの特定のマッピング決定により、月末締めにかかる時間が30分で済むか、午後のほとんどを費やすかが決まります。

月末締めまで正しく見える勘定科目表

ほとんどの標準的な勘定科目表テンプレート — Eコマース専用のものさえも — 収入が総収入として計上されるという仮定に基づいて作られています。100ドルの売上は100ドルの収入として計上されます。手数料は支払われたときに記録されます。ほとんどのビジネスはそうやって機能します。

Shopifyはそのようには機能しません。

Shopifyは、顧客が100ドルを支払ったときに100ドルを送金しません。それは純受取金 — 総売上から、決済手数料、返金、Shopifyの取引手数料、場合によっては代わりに徴収した売上税を差し引いた金額を、1日から14日間の注文をまとめて1回の銀行振込で送金します。その受取金がクライアントの銀行口座に振り込まれる頃には、少なくとも5つの異なる財務イベントを表しています。あなたの勘定科目表は、そのすべてを受け取り、分解できるようにする必要があります。そうでなければ、毎月照合に失敗します。

勘定科目が間違っているのではありません。アーキテクチャが間違っているのです。

Shopifyの純受取金構造がアーキテクチャ上の問題である理由

典型的なShopifyの受取金には、実際には次のような項目が含まれています。項目別に分解したものです。

• 総売上高 — 支払い期間中の全注文からのトップライン収益
• 支払い手数料 — Shopify Payments（ベーシックプラン）の場合、オンライン取引あたり通常2.9% + $0.30。払い出し前に差し引かれます。
• Shopify取引手数料 — ストアがShopify Paymentsを使用していない場合、取引ごとにさらに2%。古いプランで一般的です。
• 返金処理額 — 支払い期間中の返品された注文に対する総返金額
• マーケットプレイスが処理した売上税 — Shopifyが集計し、マーチャントに代わって直接州当局に remitt する金額（ほとんどの米国州では、Shopifyがマーケットプレイスファシリテーターです）

統合で入金が直接「Shopify売上」の収益勘定にマッピングされると、5つのイベントすべてが1つの数値に集約されます。手数料はすでに差し引かれているため、収益は過小評価されます。手数料費用は目に見えません。税金の徴収を収益として記録したため、貸借対照表には見かけ上の税金負債が計上されます。

解決策は、毎月後から片付けることではありません。各コンポーネントが自動的に正しい勘定にルーティングされるように勘定科目を構築し、クリアリング勘定がそれらを銀行入金に結び付けることです。これには5つの具体的な決定が必要です。それらを誤る下流コストは、貴社がeコマースの契約で無駄にする時間です。

決定事項1と2：総収入勘定とクリアリング勘定

決定1：入金額ではなく、総売上高を収益として記録する。

収入アカウントには、Shopifyが控除する前の、顧客が実際に支払った金額を反映させる必要があります。「eコマース売上」という単一のバケットではなく、販売チャネルごとに個別の収入アカウントを作成してください（Shopify売上、WooCommerce売上、卸売収入）。ShopifyとAmazonの収益を1つのアカウントにまとめると、チャネルごとの利益率の可視性が失われ、帳簿を再構築しない限り、それを回復する実用的な方法はありません。

Shopifyのみのクライアントの場合、きれいな収益セクションは次のようになります。

• 4100 — Shopify売上（控除前総額）
• 4110 — Shopify配送料収益（顧客に配送料が請求される場合）
• 4200 — 返品および値引（収益控除）

収益勘定は販売されたものを記録します。銀行入金は、控除後の払い出し額を反映します。これら2つの数値は構造的に異なり、勘定科目はそれらを橋渡しする勘定を必要とします。

決定2：クリアリング勘定をブリッジとして使用する。

売上が記録されると、総額はShopify売上収益勘定に、資産としてクリアリング勘定に計上されます。Shopifyが純払い出しを払い出すと、クリアリング勘定は控除（手数料、返金、税金）を受け取り、ゼロにドレインします。銀行入金は純払い出しと正確に一致します。各コンポーネントは正しい勘定に着地します。

クリアリング口座がない場合、単一のQBO口座に一致しない銀行預金の照合を試みることになります。なぜなら、それは単一の口座に一致するものではないからです。5つの財務イベントの合計です。クリアリング口座なしでShopifyの照合に一晩費やしたことのあるすべてのCPAは、それがどのような感じかを正確に理解しています。

支払い処理業者ごとに1つのクリアリング口座を作成します。クライアントがShopify PaymentsとPayPalを使用している場合、それは2つのクリアリング口座になります。それらを混在させると、収入レベルで解決しようとしているのと同じ不一致の問題がクリアリングレベルで再発生します。

これら2つの決定事項がどのように実施されるか：製品マッピング。

決定事項1と2は、QBOに投稿するソフトウェアがそれらを尊重する場合にのみ有効であり、マッピングはそれが起こる場所です。シーケンスルールは、LedgerPort独自のセットアップドキュメントから直接来ています：まず勘定科目表を作成し、次にマッピングします。LedgerPortは、あなたの既存のQuickBooksアカウントにマッピングします。勝手にアカウントを作成するわけではないので、この記事で設計した構造が、同期が尊重する構造になります。

マッピング画面は、収益の粒度を設定する場所でもあります。すべての製品はQBOアイテムにマッピングされ、すべてのアイテムは収入アカウントを持ちます。多くの製品を1つのアイテムに向けると、このテンプレートの単純なバリアント（単一のShopify売上アカウント）が得られます。製品を個別にマッピングすると、SKUごとの収益と、在庫タイプのアイテムに対するCOGS投稿が得られます。これは、「1つの売上アカウント対ラインごとの収益アカウント」と同じ決定事項であり、ドロップダウンとして表示されます。

実際には、この2つの詳細がこれを実行可能にします。第一に、失敗モードは安全です。マッピングされていない製品を含む注文は、「製品がマッピングされていません」という名前のステータスでエラーになり、間違ったアカウントに投稿される代わりに保持されるため、テンプレートが静かに違反されることはありません。第二に、セットアップは数週間のドロップダウンクリックではありません。Auto-Mapは、SKUまたは名前でShopify製品をQBOアイテムに1クリックで一致させ、結果をレビューのためにフラグ付けし、手動マッピングのために見つからなかったものだけを残します。

決定事項3と4：手数料の分離と返金処理

決定3：Shopifyの手数料は単一の明細項目ではありません。

3つの異なる手数料タイプがShopifyの支払いに出現します。これらを1つの「Shopify手数料」アカウントにまとめることは、利益がどこに行っているのかについての意味のある可視性を失わせます。

QBOでの明確な料金体系：

• 6100 — Shopifyサブスクリプション
• 6110 — Shopify取引手数料
• 6120 — 支払い処理手数料

これら3つをすべて1つの口座にまとめることは、CPAが、支払い処理による3%の利益率の低下が、粗利益が価格設定モデルの予測よりも低い理由が問われるまで見えない帳簿を引き継ぐ方法です。それらを分離することは、セットアップ時に何もコストがかからず、その後のすべてのレビューで時間を節約できます。

決定4：返金は元の注文ではなく、支払いに対して処理されます。

顧客が注文を返品すると、Shopifyは次の利用可能な支払いから返金を差し引きます。個別の銀行取引を作成するのではなく、払い戻しの正味額を減らします。返品および控除の反対収益勘定は、返品が処理された時点ではなく、それを含む支払い時に返金エントリを受け取る必要があります。

3月に返品が処理され、返金が4月の支払いに出金された場合、反対収益エントリは4月に属します。3月に投稿すると期間の不一致が発生します。3月の収益は減少しますが、現金の効果が3月に発生しなかったため、3月の銀行照合は依然としてバランスが取れません。期間の不一致は、帳簿を完全にクリーンアップして解きほぐす必要が生じるまで、月をまたいで累積します。

決定事項5：初日から負債としての売上税

米国のほとんどの州では、Shopifyはマーケットプレイスのファシリテーターです。つまり、Shopifyは顧客から売上税を徴収し、州税当局に直接送金します。マーチャントはそのお金に触れることはありません。マーチャントはその税金を支払う義務はありません。Shopifyはすでに支払っています。

Shopifyが徴収する売上税は、Shopifyダッシュボードの注文総額に表示されますが、マーチャントの銀行口座に流れ込むことはなく、マーチャントの収益ではありません。収入勘定が税金を含む注文総額を記録している場合、収益を過大計上しており、貸借対照表に架空の負債を構築しています。

正しい設定には2つの負債勘定が必要です：

• 売上税支払額 — 販売者が直接徴収・納付する税金（卸売などのマーケットプレイス以外、またはマーケットプレイスファシリテーターのルールが適用されない州）
• マーケットプレイス税源泉徴収額（または「Shopify税徴収額」） — Shopifyが販売者に代わって徴収・納付する税金。Shopifyによる納付によって債務が消滅するため、精算サイクル後にゼロになります。

クライアントが複数のチャネル（Shopify、直販サイト、卸売など）で販売している場合、チャネルごとに税務処理が異なります。「売上税支払額」という単一の勘定科目では、Shopifyが処理する税金と販売者が処理する税金を区別できず、その区別は税務申告時に重要になります。

LedgerPortでは、決定事項5は月次の規律ではなく設定として出荷されます。同期構成の「税金」タブには、「品目税」オプションがあります。プラットフォームによって収集された税金は、ドロップダウンから選択した負債アカウントにルーティングされ、QuickBooksトランザクションの独自の品目として投稿されます。「税金は収入ではなく負債である」というルールは、誰かが覚えておくべきものではなくなり、同期が投稿できる唯一の方法になります。

ほとんど説明されない詳細、つまり税金の丸め処理が同じタブにあります。プラットフォームの税金計算とQuickBooksの税金計算では、一部の注文で1〜2セントの誤差が生じますが、そのセントを吸収する場所がないと、帳簿は注文ごとに数セントずつ、照合不能な状態にずれていきます。税金丸め設定は、その差を吸収する丸め調整の品目行を追加します。そのため、帳簿は「ほぼ正確」ではなく、セント単位で一致します。「ほぼ正確」では完了しません。

1日で締められる勘定科目表

5つの決定事項がすべて整ったら、月末処理は以下のようになります。各Shopifyの入金は、クリアリング口座を経由します。総売上高がクレジットとして計上されます。決済手数料、返金、マーケットプレイス税がデビットとして差し引かれます。純粋な銀行預金が記帳されます。クリアリング口座はゼロで閉じられます。銀行勘定照合は、調査ではなく、構築によって一致します。

これは20分で完了するプロセスです。違いは作業量ではなく、勘定科目表がデータを正しく受け取るように設計されているかどうかです。

初期投資は現実的です。このアーキテクチャを新しいクライアントのために正しく構築するには、初回は2〜3時間かかります。これは汎用テンプレートをコピーするよりも時間がかかります。しかし、代替案は、毎月、無期限に、それ以上の時間を費やすことです。

5〜10社のShopifyクライアントを管理するCPAにとって、このアーキテクチャは再現可能なテンプレートの基盤となります。QBOのすべてのShopifyストアに同じ5つの決定事項が適用されます。一度正しく構築すれば、新しいエンゲージメントごとに問題を再学習するのではなく、実務全体に適用できます。

もう1つの決定事項：これらのアカウントに投稿される同期方法

勘定科目表は、勘定科目が存在するだけでは完成しません。どのような種類の取引がそれらに転記されるかを決定したときに完成します。同期ツールでは、その決定には同期方法という名前が付けられます。LedgerPortでは、それは1つのドロップダウン（アプリの左サイドバーからアクセスできるSync Config » Orders » Sync Method）に5つのオプションがあり、各オプションは作成したばかりの勘定科目表に異なることを要求します。

• 売上レシート — 注文ごとに1つのレシート。品目、税金、配送料、割引が含まれ、収益勘定と決済勘定に転記されます。売掛金は不要です。
• 請求書 — 注文ごとに2つのレコード：注文時の請求書、Shopifyが支払い済みとマークしたときの支払い。これを選択すると、勘定科目表に未収金が必要になります。
• 見積書 — 未転記のレコード。変換されるまで何も触れません。ドキュメントには、これがどれほどまれであるかについて率直に書かれています。「必要なのかどうか不明な場合は、おそらく必要ありません。」
• 日次サマリー — その日のすべての注文を集計した、1日あたりのジャーナルエントリが1つ。これを選択すると、ドロップダウンのすぐ下に勘定科目マッピングフィールドが表示されます。
• タグベース — Shopifyの注文タグが注文を異なる取引タイプにルーティングします（卸売 → 請求書、小売 → 売上レシート、同期しない → スキップ）。そのため、小売と卸売が混在する店舗では、未収金勘定とレシート側勘定の両方が必要になる場合があります。

日次サマリーが何をするかをよく見てください。選択した瞬間に、ソフトウェアは日次ジャーナルエントリが転記される勘定科目の名前を尋ねます。これらのマッピングフィールドは、この記事の5つの決定事項であり、フォームフィールドとして表示されます—総収益、決済、手数料、返金、税金。上記の勘定科目表を作成した場合、1回の操作で入力できます。作成しなかった場合、ここでそれが明らかになります。

決定ロジックは短いです。標準的なDTCストアで、チェックアウト時に支払い済み：売上レシート — ドキュメント自体のデフォルト、「ほとんどのストアにとって適切な出発点」です。B2Bまたは支払い条件：請求書。高ボリューム（1日あたり約100件以上の注文）で、合計金額から作業する会計士がいる場合：日次サマリー。これは、3,000件の注文月が3,000件のレコードではなく約30件のジャーナルエントリになる方法です。

そして、この決定を安全にするルール：同期方法を変更しても、既に同期された注文が書き直されることはありません。今後のみ適用されます。方法を選択し、支払いサイクルがクリアリング口座に反映されるのを確認し、形状が間違っている場合は再検討してください — 既に締められた帳簿は閉じたままです。

LedgerPortはマッピングを自動的に処理します — 各入金サイクルで、同期により総売上高、手数料項目、返金、マーケットプレイスで徴収された税金が正しい勘定科目に投稿されるため、クリアリング口座は手動介入なしで閉じられます。そのデータを受け取るためには、勘定科目表を正しく構造化する必要がありますが、上記の5つの決定事項がまさにその構造を提供します。

QBOで新しいShopifyクライアントを設定する場合、または照合されていない帳簿を引き継ぐ場合は、まずこの5つの箇所を確認してください。上記のいずれかの決定がなされていない場合、それが4時間の照合が発生する原因です。勘定科目表を正しく設定することは、CPAに求められたときに税務準備ができた帳簿を持つための基盤でもあります。月末処理をクリーンにするのと同じ5つの決定事項が、年末処理を単純化します。マルチクライアントの実務全体でLedgerPortがどのようにマッピングを処理するかは、ledgerport.com/cpasで確認するか、無料で開始してください。