QuickBooksにおける掛売買掛金会計は、1つの置き換え — 売上伝票を請求書に置き換える — と、毎週確認する1つのレポートに集約されます。
注文書は火曜日に届き、それはあなたがこれまでに受け取った中で最高の注文でした：4店舗展開のジムチェーン、卸売価格で300ユニット、掛売30日払い条件で9,600ドル。木曜日に出荷しました。QuickBooksは、あなたの店で他のすべてを記録するのと同じ方法で9,600ドルの売上を記録し、3月の損益計算書は素晴らしいものに見えました。
そして4月が来ました。家賃、在庫の再注文、広告費 — すべて現実的で、すべて今日が支払い期日です。9,600ドルはまだレポート上の数字でした。あなたの帳簿では3月が過去最高の月でしたが、あなたの銀行口座は今年一番現金が逼迫していることを示していました — そしてQuickBooksが示したものからは、誰があなたにいくら支払うべきか、またはいつ支払われるべきかを知ることはできませんでした。
小売店に卸売を追加した場合 — ShopifyのB2Bカタログ、WooCommerceの卸売プラグイン — 「売上」と「現金」の間のこのギャップは、最初に遭遇する会計上の問題です。これは計算ミスではなく、構造的な問題です。掛売注文は小売注文とは異なる種類の取引であり、帳簿上で異なる形状を必要とします。この記事では、その形状について説明します：QuickBooksでの適切な掛売買掛金会計、真のキャッシュフローダッシュボードとなる売掛金年齢表、入金、そして約束を現金に変える回収習慣について説明します。
卸売注文が小売簿記を破綻させる理由
小売注文は、顧客が購入し、顧客が支払うという2つのイベントが同時に発生するものです。会計用語では、売上と支払いは1つの瞬間です — だからこそ、小売注文の自然なQuickBooksの形状は、売上伝票（またはそれらの日次サマリー）であり、収益が記録され、現金が受け取られます。
掛売15日払い、30日払い、または60日払いの卸売注文は、これらの2つのイベントを分離します — 場合によっては2ヶ月も。出荷時に収益が発生し、バイヤーの買掛金処理が追いついたときに現金を受け取ります。その間の瞬間には、小売簿記が決して必要としなかったものがあります：売掛金、つまり、稼いだがまだ手元にないお金の継続的な元帳です。
その取引のQuickBooksでの形状は請求書です。注文を請求すると、QuickBooksは売掛金を借方計上し、収益（および売上税の負債）を貸方計上します。売上は損益計算書に、負債額は貸借対照表に計上されます。購入者が支払うと、その請求書に対する支払いを記録します。現金が増加し、売掛金が減少します。2つのエントリ、2つの日付、そしてその間のギャップが見えます。その可視性がすべてです。
ジムチェーンの注文を考えてみましょう。3月14日に30日払い（net-30）で請求され、4月13日の期日とともに売掛金に残ります。3月の収益には正直に9,600ドルが含まれています。しかし、3月の現金には含まれていません。4月になっても驚きはありません。なぜなら、帳簿はまだお金が届いたと主張していなかったからです。
店舗オーナーは、次の3つのいずれかの姿勢でこの問題に直面します。卸売注文を小売注文とまったく同じように記録して、数か月後に歪みに気づく。または、「誰が私にいくら払うべきか」というサイドのスプレッドシートを維持し、それがQuickBooksから逸脱していく。または、請求書ベースの売掛金を適切に設定し、週に1回レポートを確認する。この記事の残りは、第3のグループへの道です。
嘘：「売上は売上である」
最初にほとんどの人が犯す間違いは、もっともらしく聞こえるものです。「売上は売上だ。注文が入ったら記録すれば、お金は自然に解決するだろう。」したがって、30日払いの注文は、すべての小売注文と同じようにQuickBooksに入力されます。販売レシート、売上、支払いが1つの時点で記録されます。
それが実際にあなたの帳簿に何をするかというと、次のようになります。
それはあなたが持っていない現金をでっち上げます。販売レシートは、QuickBooksにお金が届いたことを伝えます。銀行フィードは、届いていないため、それに同意しません。今、あなたの帳簿は架空の預金を抱え、小切手が実際にクリアされるまで銀行照合が機能しなくなります。小売側でこの戦いを繰り広げたことがあるなら、Shopifyの支払い額がその日のレシート額と一致しない場合、卸売バージョンは同じ病気ですが、潜伏期間が長くなります。
それは借金を消去します。販売レシートが投稿された瞬間、QuickBooksの観点からは誰もあなたに何も負っていません。売掛金なし、期日なし、延滞なし。ジムチェーンがあなたに9,600ドルを負っているという唯一の記録は、あなたの記憶とメールのスレッドです。これを15の卸売アカウントに掛け合わせると、帳簿なしで融資業務（それが30日払い条件の意味するところです）を運営していることになります。
現金主義で申告する場合、収入を誤って記載します。現金主義の報告では、請求書の収益は支払いがあったときに計上され、販売レシートの収益はすぐに計上されます。30日払い条件の注文をレシートとして記録すると、現金主義の収入は間違った期間に計上されます。今期は過大計上され、現金が届く前に税金の結果が到着します。
これらはすべて、あなたが不注意だから起こるのではありません。あなたの簿記は小売用に構築されており、「売上=支払い」という仮定が成り立っていましたが、卸売はその仮定を通知なしに壊しました。修正は、小売構造の中でより一生懸命働くことではありません。それは、卸売注文に独自の構造を与えることです。
QuickBooksにおける掛売買掛金会計：請求書、未払売掛金、入金
QuickBooks Onlineでの30日払い条件の注文の完全なライフサイクルを、正しく行った場合、次のようになります。
- 請求書を作成するタイミング（出荷時、または合意したトリガーが作動したとき）。請求書自体に支払い条件を設定します。「受領時に支払う」ではなく「30日後払い」とすることで、QuickBooksが期日を計算し、売掛金を正しく経過日数で表示します。
- AR（売掛金）で、見えるように置いておく。未払いの請求書は隠すべき問題ではなく、システムが機能している証拠です。貸借対照表には、売掛金が資産として表示されます。つまり、稼いだお金で、回収待ちの状態です。
- 支払いを受け取ったら、請求書に記録する。「入金を受け取る」→特定の請求書に適用→預金。卸売りのチェックを単独の預金として記録しないでください。未適用入金は請求書を未解決のままにし、収益を二重に計上します。
- 銀行の明細で預金を照合する。支払いが請求書に適用されているため、照合は簡単です。1つの預金、1つの支払い記録、完了です。
簡単な並列比較です。対比が教訓となります。
| 小売注文 | 卸売りネットターム注文 | |
|---|---|---|
| QuickBooksの取引 | 売上伝票 / 日次サマリー | 請求書 |
| 認識された収益 | 購入時 | 請求時（発生主義） |
| 記録された現金 | 同じ瞬間 | 支払い受領時 |
| AR（売掛金）に残る？ | いいえ | 請求日から支払いまで |
| 何が起こりうるか | 手数料/支払い不一致 | 経過日数、支払い遅延 |
これが、より広範な設定（勘定科目表、収益勘定、売上税）のどこに位置するかは、eコマース会計ガイドで説明しています。WooCommerceストアの場合は、WooCommerce簿記ガイドで勘定科目構造の詳細を確認できます。卸売りレイヤーは、その基盤の上に構築されるものであり、置き換えるものではありません。
売掛金年齢表はあなたの真のキャッシュフローダッシュボード
卸売り注文がAR（売掛金）に反映されると、QuickBooksは卸売り事業者が実際にビジネスを運営するために使用するレポートを提供します：A/Rエイジングサマリー。これは、未払いの残高があるすべての顧客を、支払いの遅延日数（当月、1～30日遅延、31～60日遅延、61～90日遅延、90日超）で分類したものです。
会計上の形式ではなく、キャッシュフローの手段として読み取ってください。
- 「当月」の列は、今後のキャッシュフロー予測です。期日内の請求書は、バイヤーが期日通りに支払えば、今後数週間で到着するはずのお金です。
- 1～30日遅延の列は、ToDoリストです。新たに遅延した請求書は、通常、危機ではありません。それは、ちょっとした促しが必要な購買部門の問題です。しかし、その促しは今行う必要があります。回収の可能性は、時間が経つにつれて低下します。
- 61日以上の列は、リスク登録簿です。2か月以上遅延しているお金は、決定が必要です。丁寧なリマインダーではなく、エスカレーション、再交渉、出荷停止、または（会計士と相談して）貸倒処理が必要です。
- 総額だけでなく、比率にも注意してください。AR残高の増加は、ほとんどが当月のもので、卸売り収益もそれに伴って増加している場合は問題ありません。遅延残高の割合の増加は、回収よりも早く信用を供与していることを意味します。つまり、あなたはバイヤーにとって最も安価な貸し手になったのです。
The habit is almost embarrassingly simple: open the aging report once a week, same day every week, and act on anything that moved a bucket. Ten minutes. That's the entire discipline — but it only exists if every net-terms order became an invoice in the first place. Sales receipts feed this report nothing.
卸売注文に対する入金
Plenty of wholesale relationships — especially new accounts and large custom orders — run on a deposit: 50% up front, balance on net terms after delivery.
The accounting instinct to resist: a deposit is not revenue. Until you deliver, that money is a liability — you owe the buyer either the goods or their money back. The clean pattern is to record pre-delivery deposits to a customer-deposit liability account (or as a credit on the customer's record), then apply that amount against the invoice when you ship, so the invoice's open balance shows only what's still owed.
Book the deposit as income instead and revenue lands in the wrong period — and the eventual invoice either double-counts the sale or has to be manually shrunk. The liability route costs one extra account in the chart and saves the untangling.
回収衛生：支払いを確実に受け取るための地味な習慣
Net terms are a credit product, and the sellers who get paid on time run them like one. None of this requires software; all of it requires consistency.
- Put terms on every invoice, in writing. Due date, accepted payment methods, any late-payment policy. Ambiguity resolves in the buyer's favor.
- Invoice immediately. Every day between shipment and invoice is a day you added to your own terms for free.
- Remind before the due date, not after. A short "invoice #1042 is due Friday" note a week out catches AP-department slippage while it's still cheap to fix.
- Set credit limits per account — and an exposure cap overall. Decide the most any single buyer can owe you, and how much of your monthly revenue can sit on terms at once. New accounts start small (or with a deposit) and earn their way up.
- Have a stop-ship rule and honor it. No new orders ship to an account with an invoice 30+ days past due. Decided in advance, it's policy; decided in the moment, it's a negotiation you'll lose.
小売＋卸売の混在：2つの取引タイプの問題
Everything above assumes you can tell your books "this order is wholesale." The catch is that wholesale doesn't replace retail — it lands on top of it. Same storefront, same payout stream: 400 retail orders that should post as sales receipts or a daily summary, and 12 wholesale orders that must post as invoices with open AR.
Handled manually, someone inspects every order — or the sync runs one-size-fits-all and gets one side wrong. Sync everything as receipts and your wholesale AR evaporates (the Lie, automated). Sync everything as invoices and your retail books bloat with hundreds of instantly-paid invoices that make payout reconciliation miserable.
このルーティングの問題は、まさにオーダー・タギングが解決するものであり、どのツールを使用する場合でも、その仕組みを知っておく価値があります。LedgerPort — 私たちの製品なので、それに応じて判断してください — では、5つのオーダー同期方法のうちの2つです。請求書方法は、掛売りの販売者向けに構築されています。注文が確定したときにQuickBooksの請求書を作成し、注文が実際に支払われたときにそれに対する支払いを記録します。その間、未払いの売掛金があり、エイジングレポートは正しく表示され、支払われる前に何も支払済みにマークされません。タグベースルーティングは、混合ストアを処理します。ルールテーブルがオーダータグをQuickBooksのトランザクションタイプにマッピングするため、wholesaleとタグ付けされた注文は請求書として投稿され、retail注文は売上レシートとして投稿されるか、日次サマリーにまとめられ、do-not-syncタグはサンプルやテスト注文を完全に帳簿から除外します。卸売プラグインがすでにB2B注文にタグを付けている場合（WooCommerceのWholesale Suiteを含むほとんどのプラグインが可能です）、ルーティングはすでに持っているタグに乗ります。両方の方法は、オーダー同期方法の理解で比較されており、セットアップは同期設定のドロップダウンです。注意点、率直に言うと：タグベースルーティングはハイティア機能です — 価格で何がどこにあるかを示しています。
実行後：9,600ドルの注文は出荷日に請求書として投稿され、エイジングレポートには4月13日まで現行と表示され、銀行フィードは入金時に支払いを請求書に一致させ、小売側は以前と同様に照合を続けます。トレードオフは、事前に正直な作業を行うことです — 条件を決定し、タグを適用し、マッピングを一度設定します。その後、月曜日の朝のエイジングレビューがすべての仕事になります。
4月に見えなかったそのギャップ — 紙面上では最大の月、銀行では最も厳しい月 — は、収益性の問題では決してありませんでした。それは、それを監視する元帳エントリのない、稼いだ9,600ドルの収入でした。すべての掛売り条件の注文に請求書を発行してもギャップは閉じませんが、それは可視化され、日付が付けられ、回収可能になります — それがすべてです。
ストアで小売チェックアウトと卸売条件の両方を実行している場合は、タグから始めてください：タグベースルーティングが各側面を正しく投稿する方法を確認してください → — または、ストアを無料で接続して、次の卸売注文をレシートではなく請求書としてルーティングしてください。
