銀行が宣伝する機能は、ストアにとって重要な機能ではほとんどありません。ここに、誰も公開していないチェックリストがあります—アーキテクチャ、フィードの品質、そして将来の貸し手が何を見るかです。
3月の第2週、あなたは単一の当座預金口座で14ヶ月分の取引をスクロールしています。Shopifyの支払い。サプライヤーへの支払い。その卸売サイドチャネルからのStripeの入金。あなた自身への3回の送金。収益と全く同じように見える梱包業者からの払い戻し。会計士は「これらの入金のうち、どれが売上か？」という簡単な質問をしました。そして、あなたはそれを答えるために2時間スプレッドシートを作成しています。
そのアカウントは選択されたものではありません。それは蓄積されました。おそらく、LLCを登録したときに地元の支店があなたにアップセルした中小企業当座預金口座かもしれません。おそらく、設定中に支払いプラットフォームがオンにした残高口座かもしれません。どちらにしても、誰も座って「これは実際の取引量があるストアのバンキング構造だ」と決めた人はいません—そして今、あなたのお金に関するすべての質問に答えるにはスプレッドシートが必要です。
この下に隠された嘘—銀行マーケティングが静かに奨励しているもの—は、ビジネス銀行口座はコモディティであるということです：すべてお金を保持するので、最も素敵なサインアップフローがあるものか、あなたの家の近くの支店があるものを選んでください。これはストアにとっては特に誤りです。あなたの銀行設定はお金が置かれる場所ではありません。それはあなたの会計システム全体が構築されている信頼のソースレイヤーであり、設定間の違いは、あなたの帳簿にかかる時間とそれらをどれだけ信頼できるかという点で、毎月現れます。
まず、開示を率直に述べます：私たちは銀行業務を販売しておらず、このガイドのどの企業も掲載料を支払ったり、紹介手数料を支払ったりしていません。私たちは会計ソフトウェアを製造しています—LedgerPortはShopifyとWooCommerceストアをQuickBooksと同期します—そのため、あなたの銀行選択における私たちの唯一の利害関係は下流にあります：あなたが最終的に選択するものはすべて、私たちがストアオーナーが照合する銀行フィードになります。このガイドが存在する理由もそれです。私たちはどの設定がクリーンな帳簿を生み出し、どの設定が上記の3月のような午後を生み出すかを見ています。そして、率直に言うと：これは、アカウントを選択および構造化するためのガイドであり、財務アドバイスではありません—預金保険、融資、または法的な重みを持つものに関する決定については、プロバイダーとCPAに詳細を確認してください。
あなたのストアのお金が存在する3つの場所
すべてのeコマースバンキング設定は3つの構成要素から構築されており、多くの悪い設定はそれらのうちの1つしか使用していない、またはプロファイルに合わないものを使用していることから生じます。
フィンテックビジネスアカウント（Mercury、Relay、Novoクラス）
新しい世代のビジネスバンキング商品はソフトウェアファーストで構築されており、オンラインビジネスではそれが顕著です。口座は支店訪問ではなく、数日でオンラインで開設できます。インターフェースは、他のツールを接続することを前提としています。そして、以下に説明するアーキテクチャで最も重要な機能（数回のクリックで開設できる複数のサブアカウント、低コストまたは無料の電信送金とACH、権限付きのチームログイン）は、プレミアムアドオンではなくコア製品です。
それぞれに中心的な強みがあります。Mercuryはスタートアップやオンライン企業で評判を築き、その製品にはそれが反映されています。クリーンなサブアカウント処理とAPIファーストの姿勢により、バンキングデータは他のスタックとうまく連携します。Relayは複数のアカウントワークフローに重点を置いています。Profit Firstのような封筒方式システムを運営しているオーナーの間で最もよく名前が挙がるのは、多くの当座預金口座を開設・管理することがその設計全体だからです。Novoは小規模な事業を対象とし、小規模店舗がすでに使用しているツールとのシンプルさと統合に重点を置いています。これら3つはいずれもクラスの例であり、網羅的なリストではありません。また、機能は変更されるため、コミットする前に必ず現在の条件を直接確認してください。
正直に申し上げます。ほとんどのフィンテックバンキング商品は銀行ではありません。それらは、舞台裏で1つ以上の提携銀行に預金を預けているテクノロジー企業です。その構造は一般的で実行可能ですが、特定のプロバイダーがどのように預金保険を構造化しているか、実際にお金を保有しているのはどの機関か、そしてそれらの間で補償がどのようになっているかを理解する必要があります。直接質問してください。優れたプロバイダーはそれを書面で回答します。それ以外にも、支店がないため、現金預金は不便から不可能まで様々であり、融資を希望する際にあなたの名前を知っている支店担当者はいません。あなたの店舗が市場、ポップアップストア、現金引き出しなど、実店舗での取引を伴う場合は、フィンテック口座だけではカバーできません。
従来型の銀行
従来のビジネスバンクの強みは、まさにフィンテックのギャップです。現金を入金できます。問題があれば支店に立ち入ることができます。そして、ほとんどのオーナーが早期に気づくよりも重要なことですが、融資関係を築くことができます。3年間あなたの預金を見てきた銀行担当者との会話は、特に融資枠やSBA保証ローンでは、冷たい申請とは異なります。そこでは関係と履歴が本当に重要になります。
考慮事項。 ソフトウェアは一般的に10年遅れており、月額料金と最低残高要件は依然として存在し、送金には通常実質的な費用がかかり、以下の複数のアカウントアーキテクチャは、多くの場合、「新しいサブアカウント」をクリックするのではなく、正式に複数のアカウントを開設することを意味します。これらはどれも失格となるものではありません。従来の銀行は、デフォルトではなく、特定の理由（現金、融資、支店の必要性）のために選択するものであることを意味します。
プロセッサ残高アカウント（Shopify Balanceクラス）
3番目の選択肢は、ほとんど決断ではありません。これはまさに問題です。決済プラットフォームは、組み込みの残高口座（Shopify Balanceがその明白な例です）を提供するようになっています。そこでは、あなたの入金はプラットフォーム内の口座に着金し、多くの場合、カードが付随しており、資金へのアクセスが速くなります。利便性は本物です。送金を待つ必要も、サードパーティの口座を設定する必要もなく、すぐに資金を利用できます。
考慮事項。 残高口座は、それをあなたの全額銀行として使用するように誘惑します。そして、あなたの運営費用、あなたの入金、そしてあなたのプラットフォーム活動はすべて1か所に集まり、あなたのストアを運営し、あなたの支払いを処理するのと同じ会社によって管理されます。それは、デフォルトではなく、意識的に行う価値のある集中決定です。特に簿記に関しては、収益が入金される口座から直接支出すると、この記事の冒頭の3月のシナリオが再現されます。入金と経費が1つのフィードで混在し、毎月仕分け作業が発生します。意図的に使用する場合 — プロセッサの残高は、実際の運営口座にスイープするための入金着金ゾーンとして — 便利なコンポーネントになります。すべてのアカウントとして使用すると、帳簿がずれます。
帳簿をクリーンに保つアーキテクチャ
銀行のマーケティングページには決して書かれていない部分がここにあります。それは特定の銀行に関するものではありません。口座の数と配置は、それらに表示されているロゴの会社よりも重要です。
ストアの規模で一貫してクリーンな帳簿を作成するセットアップは、次のようになります。
- 入金受取口座。 プロセッサの入金（Shopify、PayPal、Stripe、その他あなたが使用するもの）を受け取るだけの1つの口座。そこからは何も支出されません。お金が入金され、あなたは定期的にそれを転送します。この口座には入金のみが行われるため、この口座の履歴の各行は、「プラットフォームは実際にいくら入金したか？」という質問に、仕分けなしで答えます。
- 運営口座。 スイープされたお金が入金され、ビジネスが支出する場所 — サプライヤー、広告、給与、ソフトウェア。ここでのすべての取引は経費または振替であり、偽装された収益イベントではありません。
- 税金準備金口座。 すべてのスイープの固定割合がここに移動され、支出として扱われます。信託で保持している売上税と所得税引当金はあなたの所有物ではありません。口座の境界線は、それを覚えておくための最も安価な規律です。（どのくらいの割合か、特に売上税をどのように処理するかは、あなたのCPAとの相談事項です — ここでのポイントはアーキテクチャです。）
リレーまたはマーキュリークラスの製品では、この構造全体の設定に数分しかかからず、費用もかからないため、フィンテックのサブアカウント機能は「あれば便利」というレベルを超えています。まさに、これが私たちがそれをクラスの強みとして挙げた理由です。
QuickBooksで全体が機能するための1つのルールは、実際の口座ごとに1つの銀行フィードを設定し、構造内のすべての口座を接続することです。上記の各口座は独自のフィードとなり、それらの間の送金は二重に収入と支出としてカウントされるのではなく、送金として照合され、Shopifyが送信した金額と銀行が受け取った金額を照合する入金照合は、入金のみを含むフィードに対して行われます。現在、この照合ステップが毎月の苦痛な部分である場合は、完全な方法はQuickBooksでShopifyの入金を照合する方法ガイドに記載されています。入金を受け取る口座が、そのプロセスを考古学からチェックリストに変えます。
[画像：シンプルなフロー図 — プロセッサの入金 → 入金受取口座 → 運用口座と税金準備金に分割される定期的なスイープ。各口座にはQuickBooksの銀行フィードアイコンが付いています]
誰も宣伝しない基準：銀行フィードの品質
2番目の簿記基準があり、それは悪いバージョンを経験するまで見えません。それはQuickBooksにトランザクションがどのように表示されるかということです。
各銀行は、フィードを通じてトランザクションの説明を異なる方法で表示します。良いバージョンは、プロセッサの名前、日付、入金レポートに追跡できる識別子など、認識可能なものを示す入金行です。悪いバージョンは、何にでもなりうる参照コードの切り詰められた文字列で、奇妙にバッチ処理されるか、数日遅れて実行されるフィードに表示されます。同じ金額、同じ銀行残高でも、一方は数秒で照合され、もう一方は毎月、永遠に簿記担当者から「これは何ですか？」というメールを生成します。
これは機能ページでは見つけられませんが、コミットする前にテストできます。トライアル期間中に候補となる口座をQuickBooksに接続し、いくつかの実際の入金を処理して、フィードに何が表示されるかを確認してください。同じボリュームの他のストアオーナーに、フィードがどのように見えるか尋ねてください。これは、サインアップボーナスよりも多くの時間を節約できる、地味な評価ステップです。なぜなら、フィードの品質は、口座の存続期間中、毎月、すべてのトランザクションに対して支払う（または支払わない）税金だからです。
貸し手がこれらの同じアカウントに求めるもの
銀行設定が静かに行っている最後のことは、将来貸し手に提出するファイルを作成すること（または作成しないこと）です。
最終的に運転資金が必要になった場合 — 在庫の与信枠、証書貸付、収益連動型融資 — 審査は銀行取引明細書と帳簿が一致しているかにかかってきます。クリーンな構造にすればそれが自動化されます。入金口座は収益の証明となり、営業口座は支出の物語となり、QuickBooksは両方に接続されます。なぜなら、各フィードが照合されるからです。混在した単一口座は逆の効果を生みます。貸付元には振込と区別できない入金があり、申請は「確認できませんでした」で停滞します。各資金調達元が確認する内容の詳細 — そして、まだ記録が整っていない場合の是正期間 — は、eコマース向けの資金調達準備の整った帳簿ガイドに記載されています。要するに、貸付元は、あなたがそれを選択してから数ヶ月または数年後に、あなたの銀行システムの残骸を読むのです。
これは、フィンテックが日常業務を管理している場合でも、従来の銀行を関係者に含めておくことの正直な理由でもあります。成長計画にSBA融資や地元の銀行との関係が含まれる場合、その機関での預金履歴の一部は、ゆっくりと構築され、すぐに購入できない資産となります。
ランキングではなく、プロファイルで選択する
eコマースに最適な銀行はありませんが、形状に応じた合理的なデフォルトはあります。
- オンラインのみ、現金なし、ソフトウェアに慣れている方: フィンテック口座をコアとし、そのサブ口座を使用して3口座アーキテクチャを構築します。預金保険の構造を書面で確認し、現在の条件を確認してください。
- 現金要素がある場合、または融資が視野に入っている場合: 従来の銀行が関係と現金の取り扱いを保持します。アーキテクチャのために、その上にフィンテックレイヤーをオプションで追加します。
- プロセッサ残高: 定期的なスイープで入金着陸地点として使用するのは問題ありません。すべてのアカウントにしないようにしてください。
どれを選んでも、セットアップは同じ午後の作業です。3つの口座を開設し、スイープをスケジュールし、口座ごとに1つのフィードを接続し、まだ気が変わる可能性がある間にフィード記述子を確認します。銀行の仕事は、あなたのお金を読みやすくすることです。その後のすべて — 月次締め、税務シーズン、ローン申請 — は、ここで設定した読みやすさの度合いを引き継ぎます。
銀行業務はそのシステムの1つのレイヤーです。残りの部分がどのように連携するか — 入金、手数料、売上原価、売上税、そして締め自体 — については、eコマース会計の完全ガイドから始めてください。
