そのファイルのメスはユニークではありません。それは次のファイルに見られるのと同じ5つの欠陥であり、それはあなたがクリーンアップをフォレンジックプロジェクトとして扱うのをやめ、標準的なエンゲージメントとして扱うことができることを意味します。
あなたは10時間で見積もりました。3週目です。
そのファイルは、最後の簿記係が「銀行フィードを追跡していた」Shopifyクライアントから、年の中盤にあなたのもとに来ました。彼らはそれをしました—すべての預金が直接収益に分類されました。問題は、誰かがいつか同期ツールを接続したため、預金の上に売上レシートが収益を計上していることです。収益は数ヶ月間二重に計上されています。処理手数料はどこにも表示されません。売上税は収益口座にあります。そして、一度もゼロになったことのない5桁の残高を持つ決済口座があります。
ShopifyクライアントのQuickBooksファイルをクリーンアップすることに同意したすべてのCPAは、このバージョンのいずれかを経験しています。そしてほとんどの人は、*すべてのeコマースクリーンアップはカスタムフォレンジックプロジェクトであり、それをやり遂げるしかない*と信じて立ち去ります。
それは嘘であり、高価な嘘です。10時間の見積もりが30時間になった理由であり、多くの企業がその後eコマースの紹介を静かにやめる理由です。
このグラインドが隠しているのは次のとおりです。Shopifyクライアントのメスは非常に一貫しています。同じ5つの欠陥がほぼすべてのファイルに、ほぼ同じ重症度の順序で、同じようなセットアップミスによって引き起こされます。それらを名前を付け、数分で検出し、正しい順序で修正できるようになると、フォレンジックプロジェクトは標準的なエンゲージメントになります。スコープ設定、価格設定、そして最終的には委任できるエンゲージメントです。
ほぼすべてのShopifyクライアントファイルに見られる5つの欠陥
1つのトランザクションに触れる前に、診断してください。これらのそれぞれは、確認するのに数分かかり、それらを組み合わせることで、実際に何に対処しているかがわかります。
| 欠陥 | 5分間の検出 | 破損するもの |
|---|---|---|
| 二重計上された収益 | P&L収益 vs. Shopify総売上—約2倍の差 | 収益、税金負債 |
| 純預金収益 | 収益は銀行預金と正確に一致します。手数料口座は空です。 | 総収益、利益率、手数料費用 |
| 収益としての売上税 | どの売上税負債勘定にも活動がない | 収益、負債、申告サポート |
| 返金が削除または相殺された | Shopifyの返金にもかかわらず、収益控除勘定が空である | 総収益、返品率 |
| クリアリングがゼロにならない | 大きくて古いクリアリング勘定残高 | すべてが下流へ - 何も照合できない |
1. 二重計上された収益（銀行フィード＋同期された売上）
検出方法: P&Lをプルし、総収入を同じ期間のクライアントのShopify売上レポートと比較します。帳簿上の金額がプラットフォームの総売上の約2倍になっている場合、それが見つかったということです。収入勘定を開いて確認します。同期ツールからの銀行フィード入金と売上レシート（または請求書）が並んで表示されます。
破損するもの: 収益、およびそれから計算されるすべて（推定税金、利益率、クライアントがこれらの数値で提出したローン申請など）。
修正方法: 売上レシートは通常、より良い記録です。総売上の詳細が含まれています。それらを保持し、銀行フィード入金を収益から除外し、レシートが決済されるべきクリアリング勘定に対して再分類します。すでに申告済みの期間については、明細ごとに修正せず、期間ごとに1つの修正仕訳（借方収益、貸方クリアリング）を投稿し、文書化してください。
2. 純預金収益（手数料が見えない）
検出方法: 収益が2倍になっていない場合、代わりに過小評価されていないか確認します。収益が銀行入金と完全に一致する場合、クライアントはShopifyの純受取額を売上として計上しています。手数料または処理手数料の費用勘定を探して確認します。それは空であるか、完全に欠落しています。
破損するもの: 総収益が過小評価され、手数料費用が存在せず、利益率分析は架空のものです。注文ごとに2.9% + 30¢を支払うストアには、P&Lに表示されたことのない実際の費用項目があります。
修正方法: 総額を計上します。各期間について、手数料の金額に対して手数料を借方計上し、売上収益を貸方計上する仕訳により、両方の項目が復元されます。Shopifyの受取レポートには、受取ごとの手数料合計が記載されています。推定値ではなく、それらから作業してください。
3. 売上税が収益として計上されている
検出方法: 売上税負債勘定を開きます。活動がほとんどまたは全くない場合（ただし、クライアントが申告および納付を行っている場合）、徴収された税金が収益内にあります。多くの場合、その鏡像も見つかります。州への納付が「売上税費用」として計上されています。両者はP&Lでほぼ相殺され、まさに誰も気づかなかった理由です。両方の項目は間違っています。
破損するもの: 徴収された税金により収益が過大計上され、負債勘定は申告されたものを裏付けることができず、クライアントが監査された場合、帳簿と申告書が一致しなくなります。
修正方法: 徴収された税金を収益から負債勘定に再分類し、次に費用ではなくその負債に対して納付を計上します。結果の残高をクライアントの実際の申告に対して照合します。これは、QuickBooks以外のソースに対して検証する必要がある唯一の欠陥です。
4. 払い戻しが削除または相殺収益ではなく相殺されている
検出方法: Shopifyの返金レポートを指定期間で抽出します。次に、「返金および値引（控除収益）」勘定を探します。Shopifyでは返金が表示されているのに帳簿に何も記載がない場合、返金は入金に静かに相殺されたか、または監査ログを確認してください、何も一致しないため」として削除されたかのどちらかです。
破損するもの: 総収益と返品率。売上の2%を返金していると思っている顧客が、実際には6%を返金している場合、誤ったデータに基づいて価格設定や在庫の決定を行っています。
修正方法: 返金を控除収益勘定に再計上し、総売上、返金、純売上をそれぞれ表示される項目として残します。収益に相殺しないでください。そこで失われた情報は戻ってきません。
5. ゼロになったことのない決済口座
検出方法: 残高を確認します。Shopifyのクリアリング（または未預金資金）勘定は、支払い間の残高がゼロに近い状態であるべきです。もしそれが数ヶ月前の5桁の残高を抱えている場合、入金されたものと支払い済みのものの照合が一度も行われていないことになります。
破損するもの: これは他の問題を不可視にする欠陥です。クリアリングがゼロにならない場合、二重計上や不足している手数料を捕捉したはずのチェックポイントがありません。下流の何も照合されず、最後にファイルが確実に正しかったのがいつなのか誰も言えません。
修正方法: これは意図的に最後に実行します。欠陥1から4が修正されたら、クリアリング残高の経過を調べ、支払いと入金を照合し、パートナーが承認した仕訳で文書化された残額を償却します。クリアリングを最初にゼロにしようとすると、まだ間違っている数値に対して照合することになります。
クリーンアップシーケンス：Shopify QuickBooksファイルをこの順序でクリーンアップする
順序は努力よりも重要です。手順と、その理由を説明します。
1. 流入を停止する。 何かを修正する前に、まだ重複して投稿されているものを一時停止してください。冗長な銀行フィードの分類ルールや誤設定された同期を切断します。欠陥が蓄積しているファイルをクリーンアップすることは、蛇口を開けたままモップをかけるようなものです。
クライアントの同期ツールがLedgerPortの場合、蛇口には文字通りのハンドルがあります。「接続」ページにある「同期を一時停止」です。これにより、設定を切断したり構成を失ったりすることなく、クリーンアップ中にQuickBooksに新しいエントリが着地するのを停止します。ドキュメントでは、まさにこの種のメンテナンスウィンドウに推奨されています。ファイルがクリーンになったら、同じ場所から「同期を再開」をクリックすると、接続は中断したところから再開されます。再承認不要、設定の再構築不要、孤立したマッピング不要。
2. 履歴の前に構造を修正します。 ファイルが持つべきだった勘定科目表を設定します — 収益、返金控除、手数料、売上税負債、1つの決済口座。壊れた勘定科目表に投稿された修正は、第二世代の混乱を生むだけです。eコマース勘定科目表テンプレートは標準のマッピングです。クライアントごとに調整しますが、標準から始めてください。
3. 再計算ラインを描画します。 詳細に再計算する範囲と概要で調整する範囲を決定します。作業上のデフォルト：現在の会計年度は、トランザクションまたは月次仕訳レベルで修正されます。以前に提出された年度は、それぞれ1つの調整エントリで、申告書を作成した担当者と連携して行われます。重要性と税務担当者がこれを決定します — あなたの考古学への意欲ではありません。
4. 月ごとではなく、欠陥ごとに作業します。 これは、エンゲージメント全体の効率を最も向上させる点です。「1月をクリーンアップしてから2月をクリーンアップする」のではなく、全体的な期間の二重計上された入金をすべて修正し、次にすべての手数料の総計、次に税金の再分類、次に返金を修正します。各欠陥には1つの診断と1つの修正パターンがあります — それらをバッチ処理することで、30回の判断が30回適用される1回の判断に変わります。
このパスのどこかで、まったく投稿されなかった注文も見つかるでしょう — それらはマッピングされていない製品または請求フィールドの欠落により同期からエラーになり、以来エラー状態のまま残り、収益に穴を残しています。それらを同じバッチ処理の精神で回復します：ステータスで注文リストをフィルタリングし、原因を修正し、次に手動同期ページで失敗したレコードを選択して「選択したものを同期」をクリックします。何かを再プッシュする前に1つのルールがあります：すでに同期された注文を再同期すると、更新ではなく新しい QuickBooksトランザクションが作成されます。悪い元のトランザクションがファイルに残っている場合は、まずQuickBooksで削除してください — さもないと、再インポートはあなた自身のクリーンアップの途中で、欠陥#1、二重計上された収益を再作成します。一時停止し、構造をクリーンアップし、マッピングを修正し、悪い元のトランザクションを削除し、再同期し、再開します。このシーケンスがエンゲージメントです。
5. 最後に決済口座をゼロにします。 それが完了の証明です。決済が各支払い日にゼロに照合されると、ファイルは検証可能にクリーンになります — そしてクライアントに示す証拠があります。
再構築：メスが二度と再蓄積しないようにする
「そして今、これを手動でやり続けてください」で終わるクリーンアップは完了していません。同じ5つの欠陥が再発します。なぜなら、それらは不注意によって引き起こされたのではなく、Shopifyの支払い計算をQuickBooksに正しく変換する構造が欠けていたために引き起こされたからです。（その変換に関わるものの完全な解剖を知りたい場合は、Shopifyの売上をQuickBooksに記録する方法で順を追って説明しています。）
再構築には3つの部分があります。
同期はデフォルトではなく、クライアントごとに設定します。 再構築の最初の設定は同期方法です。これは、Sync Config » Orders でクライアントごとに選択します。デイリーサマリーは、その日のすべての注文を集計したジャーナルエントリを1日1件投稿します。これは、大量の注文があるクライアントに適した形式であり、いずれにしても合計値から作業する方法と一致するファイルです。請求書モードは、未収金が必要なB2Bクライアントに適しています。注文時に請求書を作成し、注文が支払われたときに支払い記録を作成します。タグベースルーティングは、混合帳簿に対応します。wholesale → Invoice、retail → Sales Receipt、do-not-syncタグは、テスト注文や内部注文をQuickBooksにまったく同期させません。
トリガーの衛生状態と方法をペアにします。支払いトリガーをPaidのみに設定し、無効化された注文は除外したままにします（デフォルト）。保留中、承認済みだがキャプチャされていない、キャンセルされた注文は、ファイルを汚染することは二度とありません。これは、ステップ4で削除したファントム収益の構造的な修正です。次に、クリーンアップされた期間を保護する2つのガードレールを設定します。「同期しない」日付と注文IDのカットオフは、同期が修正した履歴を再インポートするのを防ぎ、すべての設定変更は将来の同期にのみ適用されます。投稿されたトランザクションは、遡って書き直されることはありません。（カットオフはWooCommerceプラグインの同期設定にあり、Shopifyアプリは同じ前方のみの同期コンセプトを公開しています。）設定としての欠陥防止、クライアントごとに1つの画面。
標準的なチャートマッピング。ステップ2で作成したものは、このクライアント専用ではありません。テンプレート化してください。Shopifyクライアント間の違いは、ほぼ完全にマッピングの詳細と履歴ウィンドウにあります。構造はファイルごとに同じです。
自動化された入金ジャーナル。永続的な修正は、各入金をジャーナルエントリとして投稿する同期レイヤーです。総売上、返金、手数料、売上税はそれぞれマッピングされたアカウントに投稿され、銀行預金に対してクリアされます。この単一のメカニズムは、5つの欠陥すべてを構造的に防止します。収入の二重計上ができなくなり、手数料が消えなくなり、税金が収益に残らなくなり、返金が収益 contra として投稿され、入金ごとにクリアリングがゼロになります。
これは、LedgerPortのようなツールが配置されるレイヤーです。クライアントのShopifyストアをQuickBooks Onlineに接続し、アカウントマッピングを適用して、支払いジャーナルを自動的に投稿します。会計士アクセスにより、貴社が各クライアントファイルのセットアップが標準に一致することを期待するのではなく、すべてのクライアントファイル全体のマッピングを制御できます。正直な注意点として、同期ツールは履歴を自動的に修復しません。しかし、ステップ3で定義したリストアウィンドウについては、正しく構造化されたエントリをバックフィルし、不正なエントリを削除することは、月ごとに修正ジャーナルを作成するよりも速いことがよくあります。
[画像：ダイアグラム — 1つのShopifyの支払いが、総売上、返金、手数料、および売上税負債の行に分割され、仕訳帳に記録され、銀行預金にクリアされる]
エンゲージメントのスコープ設定と価格設定
プロセスが発掘ではなくシーケンスになったら、そのように価格設定できます。5つの欠陥チェックリストで診断してから見積もりを行ってください。1時間未満で完了し、リストアウィンドウと関与するボリュームがわかります。次に、フラットレートで見積もりを行います。クリーンアップは固定プロジェクトとして、再構築された同期は月次エンゲージメントの開始として。これを標準化する企業は、オーバーランを食べるのをやめ、時間ではなく専門知識に対して請求を開始します。これは、次の見積もりを行う前に確認する価値のあるLedgerPort for CPAsページでカバーされているのと同じマージンロジックです。
このエンゲージメントモデルに正確に合わせたプログラムが用意されています。LedgerPort CPA Partner Programは、企業に階層的なクライアント管理を提供します。すべてのクライアントファイルは1つのダッシュボードから監視および構成され、個別の口座へのログインとログアウトは不要です。さらに、ボリュームに応じてスケーリングされる卸売りのクライアントごとの請求、および20％の収益分配とクライアントへの20％の割引のいずれかを選択できます。平易な言葉で言うと、1回のログインで、管理するクライアントビジネスの数だけ、ShopifyとWooCommerceストアの両方で、それぞれが独自のQuickBooksファイルに同期されます。
しかし、実際にデリバリーの経済性を変えるのは、再構築自体の周辺ツールです。ステップ2で作成した標準的なチャートマッピングは、マスターテンプレートになります。これは、すべてのクライアントに適用される標準化された勘定科目表の設定であり、エンゲージメントごとにゼロからマッピングを再構築するのではなく、一度テンプレートを作成してクライアントごとにスタンプを押すことができます。それが、クリーンアップを定額で、堂々と見積もれるメカニズムです。ホワイトグローブのオンボーディングは、セットアップを完全にあなたの負担からなくします。LedgerPortのチームが、各クライアントのストアとQuickBooksアカウントを接続し、マッピングを設定し、最初の同期が完全に照合されたことを確認してからエンゲージメントを返却します。これにより、クライアント7のセットアップが、あなたの請求されない時間になることはありません。そして、エンゲージメントにブックの再構築が含まれる場合、タイムマシンは最大24ヶ月の過去のShopify注文データをインポートします。リテイナーの価格設定となる統計：パートナーファームは、クライアントあたり月あたり平均12時間以上の照合時間を節約しています。これは、クリーンアッププロジェクトに加えて、月額料金の背後にある数字です。
5回目のクリーンアップはチェックリストです
これが実際にどのように機能するかを説明します。このプロセスでの最初のクリーンアップは、テンプレートをその場で作成しているため、まだ苦痛です。2回目は半分の時間がかかります。同じ5つの欠陥があり、今回は試算表だけでそれらを認識します。5回目までには、ジュニアスタッフが実行するチェックリストになります。診断し、欠陥ごとに修正をバッチ処理し、クリアリングアカウントをゼロにし、パートナーにレビュー用の書き込みエントリを1つ渡します。
3週目の後悔として到着したクライアントは、あなたのファームが最も自信を持って見積もるエンゲージメントタイプになります。ファイルがよりクリーンになったからではありません。それぞれがユニークであると信じることをやめたからです。
収入が二重計上され、クリアリングアカウントがゼロになったことがないファイルを見ている場合は、今週5つの欠陥診断を実行してください。その後、ファームが再構築レイヤーをどのように設定するかを見て、そのクライアントにとって最後のクリーンアップになるようにしてください。そして、eコマースクライアント全体でオンボーディングを標準化する準備ができたら、CPAオンボーディングウォークスルーから始めましょう。最初のマッピングを一緒に確認します。
