顧客は4回払いで支払います。あなたは一度だけ支払いを受け取ります。そして、まさにそこで簿記がうまくいかなくなります。
あなたは3月にShop Pay分割払いを有効にしました。コンバージョン率が向上するとケーススタディで述べられていたため、KlarnaやAfterpayを追加したかもしれません。そして、月末になり、銀行フィードに新しい問題が発生しました。Shopifyの支払いレポートと一致しない金額で、これまで照合したことのない名前からの入金です。一方、マージンは通常より0.5ポイント低く、損益計算書(P&L)のどこにもその理由を説明するものはありません。
そこで、あなたはこれらの奇妙な入金を「Shopifyの収益」としてまとめて処理しました。帳簿は一致しましたが、それは静かに間違っていました。BNPL会計は、「静かに間違っている」ことが、その組み合わせが増えるにつれて毎月蓄積される分野です。
この投稿の基盤となっている考え方は次のとおりです。バイ・ナウ・ペイ・レーター(BNPL)は、収益をいつ得るかについては全く何も変えません。顧客の分割払いはあなたの問題ではありません。あなたの帳簿には決して触れません。BNPLが実際に変えるのは2つのことです。手数料が高くなり、お金が異なるストリームに着金します。どちらも、それらを理解すれば午後中に修正できます。
BNPL会計のルール1:あなたは前払いを受け取る
多くの混乱がここで解消されるため、仕組みから始めましょう。
顧客がShop Pay分割払い、Klarna、またはAfterpayでチェックアウトすると、3つのことが起こります。
- 他の販売と同じように注文を発送します。プロバイダーはチェックアウト時に顧客を承認しました。取引はあなたの側では完了しています。
- プロバイダーはあなたに前払いします。注文金額全額から、彼らの販売手数料を差し引いた金額です。分割払いではありません。一度だけです。
- 顧客は時間とともにプロバイダーに支払います。4回の支払い、月々のプランなど、顧客が選択した方法です。顧客が支払いを停止した場合、それは顧客とプロバイダーの間の問題です。あなたはすでにあなたのお金を持っています。
プロバイダーは実質的にあなたから売掛金を購入しています。彼らは顧客の信用リスクを負い、その特権のためにあなたに高い手数料を請求します。標準的なカード処理よりも大幅に高いです。普遍的なレートはありません。あなたの実効コストは、契約とプランタイプの組み合わせによって異なりますので、ご自身の契約を確認してください。しかし、方向性は一貫しています。BNPLは、カード決済よりも注文あたりのコストが高くなります。
会計上の結果は、ほとんどの人が考えるよりも単純です。収益はカード販売と全く同じように認識されます — 販売時点での注文総額、常に同じです。繰延収益も、売掛金も、QuickBooksで反映する必要のある分割払いスケジュールもありません。BNPLが「分割払いが来るたびに収益を認識すること」を意味すると誰かに言われたら、それはあなたの帳簿とプロバイダーの帳簿を混同しています。
嘘:「ただの支払い方法」
その前払いメカニズムが直接的な落とし穴につながります。収益のタイミングは通常通りなので、簿記のニーズを変更する必要はないと結論付けがちです。支払いオプションをオンにし、コンバージョンが改善するのを見て、完了です。
それが嘘であり、寛大な嘘です — なぜならそれはほぼ真実だからです。2つのことが変更されましたが、どちらもスイッチを切り替えた日には見えません。
第一に、手数料が大きくなり、場所が変わりました。カード手数料はShopify Paymentsの入金レポート内にありますが、見つけるのは面倒ですが、どこを見ればよいかはわかります(Shopifyの手数料をQuickBooksで確認する方法ですべての隠し場所をマッピングしました)。サードパーティのBNPL手数料は、まったく別の場所にあります。Klarnaのマーチャントポータル、Afterpayの決済レポートです。手数料追跡の習慣が「Shopifyの入金レポートを読む」ことであれば、処理コストのかなりの部分が視野から外れてしまいます。そして、Shopify Paymentsを利用していない場合、またはBNPLがサードパーティゲートウェイとして機能する場合、Shopify独自のサードパーティトランザクション手数料が追加される可能性があります — プランを確認してください。
第二に、お金は新しいストリームで到着します。 Shop Pay Installmentsは通常のShopify Paymentsの入金を通じて決済されるため、それらの注文はカード販売と一緒に処理されます。KlarnaとAfterpayは、独自のゲートウェイとして機能し、独自のスケジュールでバッチ処理され、独自の名称で入金されます。銀行フィードには、かつては1つだったものが2つまたは3つの決済ストリームがあり、それぞれに独自のタイミング、独自の料金、そして特定の入金を説明するために開く必要がある独自のレポートがあります。
どちらの変更も自己申告しません。最初の変更は明細を残さずに利益率を侵食し、2番目の変更は長年頼ってきた入金照合ルーチンを壊します。あなたは何も間違ったことはしていません — ダッシュボードは同じように見えましたが、システムは2番目の配管システムを成長させました。
100ドルの注文、2つの方法
数字がこれを具体的にします。以下の図は説明のための架空のもので、カード処理は通常の2.9% + 30¢、BNPLプロバイダーは架空のフラット6%とします。実際の契約は異なりますが、構造は変わりません。
| カード決済 | BNPL決済 | |
|---|---|---|
| 注文合計(顧客が見るもの) | $100.00 | $100.00 |
| 記録する収益 | $100.00 | $100.00 |
| 処理手数料 | $3.20 | $6.00 |
| 受け取る現金 | $96.80 | $94.00 |
| 受け取る時期 | 次のShopify入金 | 前払い — プロバイダーの決済スケジュール |
| 手数料が表示される場所 | Shopify入金レポート | プロバイダー独自のポータル/レポート |
| 顧客から徴収するのは誰か | あなた、決済時に | プロバイダー、4回以上の支払い |
収益行を2回読みます:同一です。どちらの場合も販売額は100ドルで、どちらの場合も販売時点で記録されます。異なるすべては、この行の下にあります — ほぼ2倍の大きさの手数料が、異なるパイプを通じて到着し、異なるレポートに記録されます。
注文あたり2.80ドルの差額は小さく聞こえますが、ミックスではそうではありません。詳細は以下で説明します。
お金の着地点:ストリームごとに1つのクリアリング口座
決済問題に対する運用上の修正は次のとおりです。これは、どこでもマルチゲートウェイの記帳を解決するのと同じパターンです。すべての決済ストリームに独自の決済口座を設けます。
当社の支払い調書作成の柱をお読みになったことがあるなら、その仕組みはご存知でしょう。総売上、返金、手数料が決済口座に計上され、銀行預金がそこから引き落とされ、残高ゼロがすべて一致していることを証明します。BNPLはこの方法を変更しません。それを増幅させます。
- Shop Pay Installments — 新しい決済口座は不要です。SPIはShopify Paymentsの支払い内で決済されるため、それらの注文は既存のShopify Payments決済口座を流れます。手数料は支払い明細で項目別に記載されています。それらの注文では手数料が大きくなるだけです。
- Klarna — 独自の決済口座。Klarnaの決済はKlarnaのスケジュールでバッチ処理され、Klarna名義の預金として着金します。Klarnaの注文の総売上と手数料をそこに計上し、各預金が入金されたときに口座を決済します。
- Afterpay — 同じです。独自の決済口座、独自の決済レポート、独自のゼロチェック。
各口座は、各決済サイクル後に独立してゼロになるはずです。いずれかがゼロにならない場合は、レポートを1つ開く前にどのストリームに問題があるかがわかります。これがこのパターンの目的です。KlarnaまたはAfterpayをゲートウェイプラグイン経由で実行するWooCommerceストアは、まったく同じ構造に直面します。WooCommerce–QuickBooks同期ガイドは、プラットフォーム固有のバージョンを説明しています。
してはいけないのは、3つのストリームすべてを区別されない1つの収益口座に流すことです。それがKlarnaの入金が収益として計上される理由です(手数料控除後です。収益が過少計上され、手数料が失われます)。また、Afterpayの決済が見逃されて四半期にわたって気づかれない理由でもあります。
BNPLを通じた返金
返金は、BNPLの配管が最も明確に現れる場所なので、最初の返金を行う前にその流れを把握してください。
BNPL注文を返金する場合、プロバイダー経由で返金します。通常、通常どおりの返金ボタンと同じです。プロバイダーが顧客側の処理を元に戻します。残りの分割払いをキャンセルし、顧客がすでに支払ったものを返金します。それらのどれもあなたの帳簿に記載されるべきではありません。
あなたの帳簿に記載されるべきなのは、他の返金と同じ逆収益エントリです。売上返品が増加し、次の決済から回収された現金がそのストリームに入ります。ひねりは手数料です。プロバイダーが返金された注文の手数料を返金するかどうかは、プロバイダーと契約によって異なります。全額返金するプロバイダーもいれば、一部を保持するプロバイダーもいれば、すべてを保持するプロバイダーもいます。仮定しないでください。契約を確認してください。手数料が返金されない場合は、保持された部分を照合のギャップに消えないように処理費用として計上してください。
BNPLの払い戻しは、カードの払い戻しよりも決済期間をまたぐことが多いため(顧客が気が変わる前に決済がすでに支払われている)、ゼロにならないクリアリング口座の一般的な原因となります。期間をまたぐ払い戻しを含む、払い戻しタイミングを正しく把握する仕組みについては、払い戻しと返品の会計ガイドで詳しく説明しています。
損益計算書(P&L)の疑問:BNPLがブレンドマージンに与える影響
次に戦略的な部分です。利益率が0.5ポイント低下した理由であり、損益計算書では何も説明されていない理由です。
BNPL手数料は、完全に処理費用です。マーケティング費用でも、売上控除でも、預金内の不明な控除でもありません。それらは独自の費用項目(または加盟店処理手数料の下にグループ化)に記載されるべきであり、そこでそれらの変動を確認できます。
そして、それらはミックスとともに変動します。以前と同じ架空のレートを使用した場合、BNPLのシェアが成長するにつれて、月に50,000ドルの売上を上げている店舗で何が起こるかを見てみましょう。
| 売上におけるBNPLのシェア | カード手数料(2.9% + 30¢、例) | BNPL手数料(6%、例) | 総処理費用 | 実効ブレンドレート |
|---|---|---|---|---|
| 0% | 約1,600ドル | $0 | 約1,600ドル | 約3.2% |
| 20% | 約1,280ドル | $600 | 約1,880ドル | 約3.8% |
| 40% | 約960ドル | $1,200 | 約2,160ドル | 約4.3% |
同じ収益。同じ製品。利益率が1ポイント失われた — 失われたのではなく、BNPLが実際に提供するコンバージョン率の向上とより大きなカートのために費やされたのです。その取引は価値があるかもしれません。しかし、ミックスがシフトするにつれて変動する費用として、損益計算書にその費用が記載されていなければ、それを評価することはできません。純預金に埋もれていると、単にビジネスが悪化したように見えます。
ご自身の帳簿に問いかけるべき質問:もし来四半期にBNPLが売上の10%から30%に増加した場合、損益計算書はコストを示しますか?答えがノーであれば、手数料はどこかで相殺されています — そしてその修正は上記のクリアリング口座構造です。
自動化された場合の様子
上記すべては手作業で可能です。ストリームごとのクリアリング口座、総収益の仕訳、各プロバイダーのレポートからの手数料の記帳、決済期間をまたぐ払い戻しの追跡。これは、照合の柱からの同じ6ステップの方法であり、ストリームごとにサイクルごとに実行されます。それがまさに問題です — BNPLは方法を難しくしたのではなく、異なるポータルのレポートに対して、それを並行して2〜3回実行させるようにしました。
これは、同期ツールが存在するカテゴリの作業です。LedgerPortは、ストアから注文、払い戻し、手数料を読み取り、構造を維持したままQuickBooksに投稿します — 総収益、目に見える費用としての手数料、各決済ストリームは個別にクリアされ、ゲートウェイごとに同じパターンです。注文は、選択した支払いステータスに達したときに投稿されるため、BNPL注文は約束されたときではなく、キャプチャされたときに帳簿に入力されます — 注文同期方法のドキュメントでそのトリガーがどのように機能するかを示しています。支払い仕訳と手数料処理はScaleプラン以上で提供されます。ラインがどこにあるかについては、価格を参照してください。
正直な注意点:どのツールもBNPLの経済性を変えることはありません。手数料は、契約に記載されている通りです。自動化が変えるのは、その手数料が行動できる損益計算書上の数値であるかどうか — それとも4月に発見する残渣であるかどうかです。
答えは最初から前払いだった
BNPLは分割払いの追跡問題、つまり学習すべき新しい収益認識体制だと期待して来たのでしょう。逆です。プロバイダーは分割払いを完全にあなたの負担から外し、代わりに、見慣れないレポートでのより大きな手数料と、銀行フィードでの新しい入金ストリームという、はるかに一般的な2つの問題をもたらしました。
どちらも構造に従います。各ストリームにゼロになるべき決済口座を設定します。BNPL手数料は独自の費用項目に計上し、ミックスが変化するにつれてブレンドレートを監視します。最初の返金前に、返金手数料の動作について契約を確認してください。後からではなく。
KlarnaまたはAfterpayの入金が現在「Shopify income」に着金している場合、それが今週引っ張るべき糸です。そして、3つの決済ストリーム全体で決済口座方式を実行することが、まさにあなたが引退しようとしている月末処理の種類であるように聞こえるなら、LedgerPortの無料プランは自動化されたバージョンをテストするための低リスクな方法です — 上記の100ドルの実例は、スプレッドシートなしで、ストリームごとに注文ごとに実行されるまさにその翻訳です。
