eコマースクライアントの帳簿の月末締めチェックリスト

一般的なチェックリストは人間が作成した作業を検証します。Eコマースクライアントのブックはソフトウェアによって作成されるため、決算は自動化された出力の5つの検証であり、特定の順序で約30分かかります。

---

決算は8日に完了とマークされました。あなたのスタッフブックキーパーは、会社の標準チェックリスト（トランザクションの分類、銀行口座の照合、すべてのボックスにチェック済み）を処理しました。その後、パートナーレビューのためにファイルを開いたところ、3日付のShopifyの支払いが入金フィードに一致しないまま残っており、誰にも説明できない残高を持つクリアリング口座があることがわかりました。

決算は穴が開いたまま完了しました。そして最悪なのは、チェックリストが失敗したのではなく、合格したことです。それは単に間違っているものをチェックしていなかっただけです。

もしあなたの会社が、Eコマースクライアントが抜け落ちてしまう月次決算チェックリストを実行しているなら、理由はこれです。チェックリストは、これらのブックがどのように作成されるかには対応していませんでした。この記事は、その代替案です。スタッフブックキーパーが約30分で実行できる、各クライアントごとの実行シートで、すべてのステップに時間と合格条件が記載されています。

「ブックはブックである」がパートナーレビューで失敗する理由

不完全な決算の根底にある嘘は、もっともらしく聞こえるものです。「決算チェックリストは一般的であり、ブックはブックである」ということです。分類、照合、レビュー、ロック。Shopifyクライアントの決算が法律事務所の決算とどう違うというのでしょうか？

なぜなら、ブックの作成方法が異なっていたからです。法律事務所の元帳は人間によって作成されるため、決算は人間の作業を検証します。すべて入力され、コード化され、照合されているか？同期ツールを使用しているEコマースクライアントのブックは、機械によって作成されます。ソフトウェアが売上エントリを投稿し、手数料を分離し、返金を記録します。構築はすでに完了しています。決算が検証する必要があるのは、一般的なチェックリストでは決して調査されない方法で失敗する、**自動化された出力**です。

14日に誰も気づかなかった同期エラーにより、11件の注文がQuickBooksに到達しませんでした。「銀行口座を照合する」では、銀行フィードはその注文の存在を知らないため、それを検出できません。Shopifyの収入の塊に一致した入金は、収益を二重にカウントしながら銀行照合を通過します。収入勘定に計上された売上税は、税務申告まで、書かれているすべての一般的なチェックリストでは問題なく見えますよね？

したがって、Eコマースの締め処理では、クライアント固有の検証が5つ、意図された順序で追加されます。それぞれが次のステップを許可します。それらのどれも建設作業ではありません。それらはすべて、自動化が生成したものに対するチェックです。（クライアントが毎月これらのうちいくつかを失敗した場合、問題は締め処理の上流にあります。15分間のファイル診断を実行し、年間12回壊れたファイルを閉じるのではなく、クリーンアップを範囲指定してください。）

Eコマースクライアント向け月次決算チェックリスト

合計時間：クライアントあたり約30分。クライアントが標準テンプレートでオンボーディングされており、すべてのファイルが同じチャートとマッピングを使用していると仮定します。以下はすべてLedgerPort向けに記述されていますが、ロジックはレコードごとのログを公開するあらゆる同期ツールに移植可能です。

決算前：エラーログのトリアージ — 5分

締め処理の前日、クライアントの監査ログを開き、ステータスを「エラー」にフィルターします。各行は、QuickBooksに到達しなかったレコードで、理由が添付されています。「製品がマッピングされていません」、「顧客が見つかりません」。修正可能なものを修正し（マッピングを追加する、顧客を作成する）、今日解決できないものについては、理由を付けて保留として記録してください。

修正ごとに、影響を受けたレコードのみを再プッシュします。行をチェックし、「選択したものを同期」をクリックします。完全な再同期や、次のスケジュールされた実行を待つ必要はありません。

クリーンな状態とは：エラーフィルターに、既に文書化された保留中の行のみが表示される状態です。リストに驚くべきものはありません。

検証1：エラーログのスウィープ — 3分

締め処理日には、その月のすべてをスキャンします。監査ログを期間にフィルターし、各ステータスを確認します。エラーは空であるべきです（または文書化された保留中のもののみ）、保留中は空であるべきです。締め処理日にキューに残っているレコードは、何かがスタックしていることを意味します。保留中の各行には、注文が支払いを待っているなど、既知のトリガー理由があるはずです。

このステップは最初に行われます。同期されていない注文が1つでもあると、下流のすべての数値が無効になるためです。穴のある帳簿の支払い追跡に意味はありません。

クリーンな状態とは：その月の未解決のエラー行ゼロ、保留中ゼロ、保留中のすべてが説明されている状態です。

検証2：支払いから入金までのトレース — 6分

その月の支払いから1つを選択します。最大額のものが最良のストレステストになります。それを最初から最後まで追跡します。総売上高は収益に、手数料は費用勘定に、払い戻しは控除対象収益に、純額は銀行預金と一銭単位で一致します。完全に一致する1つの支払いは、マッピング、手数料の分離、および入金の一致を単一のトレースで証明します。

これはサンプルであり、国勢調査ではありません。自動化はすべての支払いを同じ方法で投稿したため、1回の完全なトレースとステップ3で残りをカバーできます。支払いと預金が乖離する理由と、支払いジャーナルがそれらをどのように結びつけているかのメカニズムは、支払い照合ガイドに記載されています。

クリーンな状態とは：トレースされた支払い額の純額が、各項目が個別の口座にある状態で、銀行への入金額と正確に一致すること。1セントでもずれていれば、手数料または調整がどこかで間違って計上されていることを意味します。続行する前に見つけてください。

検証3：クリアリングゼロチェック — 3分

月末時点のクリアリング口座の元帳を開きます。残高はゼロであるか、または未払い金の合計額と正確に一致している必要があります。これは、月末の最終日に支払われた注文のうち、Shopifyがまだ払い戻していないものです。

重要なのは「正確に」という言葉です。残高を構成する特定の保留中の支払い額を特定できるはずです。特定できない残額は、未払い金の問題の早期警告です。これは、先月締め処理で問題を起こした3日のものです。

クリーンな状態とは：クリアリングがゼロであるか、または名前の付いた保留中の支払い額のリストと一致し、それ以外は何もない状態です。

検証4：売上税の照合 — 4分

Shopifyの税金レポートからその月の徴収税額を抽出し、QuickBooksの売上税負債勘定の動きと比較します。両方の数値は一致するはずです。返金税額も、収入ではなく負債勘定に対して取り消されていることを確認してください。

このステップは、Eコマースの帳簿で最も見過ごされがちな失敗を検出します。それは、徴収された税金が収益として計上されることです。これにより、収入が膨張し、負債が過小評価され、銀行の照合では決して検出されません。

クリーンな状態とは：Shopifyで徴収された税額が、期間の負債勘定の動きと一致し、返金取り消し分を差し引いた額です。

検証5：返金期間のレビュー — 4分

その月の返金を実行し、3つの点を確認します。各返金が、収入の削除ではなく、収益の反対勘定として計上されていること。元の処理手数料が費用として計上されたままになっていること（処理業者が保持します）。そして、期間をまたぐ返金（今月の返金が先月の売上に対するもの）が、締められた期間に戻って編集されるのではなく、今月に計上されていること。総額を、その期間のShopifyの返品額と比較します。

返金は期間の境界ステップであるため、最後に処理します。ここで、前の期間に何も遡って到達していないことを確認します。完全な処理（収益の反対勘定、手数料、税金の取り消し、在庫補充）は、返金と返品ガイドに記載されています。

クリーンな状態とは：返金総額がShopifyと一致し、すべての返金が期間内であり、前の期間のエントリが変更されていない状態です。

決算後：ロックとレポート — 5分

QuickBooksで期間をロックします。設定 → 詳細設定 → 帳簿を閉じる、締め日を設定し、パスワードを追加します。ロックされていない締めは、締めではありません。それは提案にすぎません。

次に、クライアントに1つの段落を送ります。スタッフが3分で記入できるテンプレートです。

[ストア名]の6月の締め処理が完了しました。1,214件の注文すべてがQuickBooksに同期され、未解決のエラーはゼロです。すべての支払い額が銀行への入金額まで追跡され、クリアリング口座は月末にゼロに戻りました。売上税の徴収額は負債勘定で4,860ドルと一致しています。期間中の返金額は2,310ドルで、返品として記録されました。1点注意が必要なのは[項目]です。帳簿は7月3日をもってロックされました。

15クライアントでの実行

1つのランシートは30分かかります。クライアントが15人いる場合、スタッフ時間は7.5時間です。問題は、どのようにスケジュールを組み、監督するかということです。

日次バッチ処理、クライアントの気まぐれではない。 月末の入金処理が完了するまでクロージングは開始できず、通常は2日か3日を意味します。3〜5日目に1日あたり5人のクライアントをスケジュールします。1日あたり2.5人のスタッフ時間で、5日目までに完了するすべてのクロージングを行います。

役割分担。 スタッフはすべてのクライアントで完全なランシートを実行します。パートナーは何も再実行せず、クライアントごとに1つの検証をローテーションでチェックします。最大のファイルに対する入金トレース、またはその他のファイルに対する税金照合またはクリアチェックを行います。すべてのステップに書き込まれた合格条件があるため、「レビュー済み」とは、再導出ではなく、指定された結果を確認することを意味します。

クライアントを分離する。 ランシートは、あるクライアントでの修正が別のクライアントに漏洩しない場合にのみ、大量で機能します。LedgerPortでは、各クライアントは独自のビジネス — 1つの店舗と1つのQuickBooks会社がペアになっています。完全に分離されており、単一のファームログインの下で独自の監査ログ、マッピング、および同期設定を備えています。スタッフはビジネスピッカーからクライアントを切り替え、ランシートはすべてのクライアントで同じように読み取られます。

チェックリストをクライアントに送信する

ほとんどのファームが見落としている手順です。完了したランシートを月次サマリーに添付します。

クライアントにとって、「月次簿記」は、内部を見ることができない請求書項目です。結果を伴う5つの名前付き検証 — エラーが修正され、入金がペニー単位で追跡され、ゼロでクリアされ、税金が照合され、返金がレビューされた — は、目に見えるデューデリジェンスです。これにより、リテイナーは容認できる手数料から、欠かせないレポートに変わり、時間ではなく価値に基づいた価格設定をサポートする、まさにそのような読みやすく体系化された作業です。

自己中心的なメリットもあります。毎月その段落を読むクライアントは、あなたに何のために支払っているのか尋ねることはありません。そして、他の店舗オーナーにそれについて話します。

3日目の入金は、より一生懸命働くことでキャッチされるわけではありません。それは、機械的に作成された帳簿が異なる方法で失敗することを知っているチェックリストによってキャッチされます — そして、まさにそれを、順番に、30分でチェックします。

CPAオンボーディングコールを予約する→と、接続、マッピング、およびこの正確なランシートに対する最初のクロージング実行を設定します。これにより、次のパートナーレビューでは何も見つからなくなります。