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つのクリアリング口座になります。それらを混在させると、収入レベルで解決しようとしているのと同じ不一致の問題がクリアリングレベルで再発生します。

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

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

Shopifyの支払いには3つの異なる手数料タイプが表示されます。それらを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が処理する税金と販売者が処理する税金を区別できず、その区別は税務申告時に重要になります。

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

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

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

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

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

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

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