サブスクリプション事業で発生する決済エラーのうち、残高不足（Insufficient Funds）は約 40%（参考値）を占めます。ただし、この数字の本質は別のところにあります。残高不足は「顧客が解約を意思表示した」のではなく、「口座残高がたまたま薄かった月末に引き落としが当たった」だけ — つまりタイミングの問題です。リトライ実行とリトライ後の対応分類を別レイヤーで設計すれば、解約意思のない顧客の相当数を静かに戻すことができます。
残高不足エラーは「解約」ではなく「タイミング」の問題
サブスク事業者の管理画面に並ぶ決済エラー一覧で、「declined - insufficient funds」「残高不足によりお取扱いできません」というステータスは毎月末に集中します。業界レポートで頻繁に引用される参考値では、これらのうち相当数は「数日待てば自然に支払い可能な状態に戻る」性質のものとされています（参考値・出典は各種国際カードブランドおよび海外決済プラットフォームの公開レポート）。
残高不足エラーをそのまま「未払い」「解約候補」として処理してしまうと、戻せる顧客を自社の運用で流すことになります。
日本の給料日サイクルという「地域固有の口座残高カレンダー」
日本の給与支払い慣行には明確な周期があります。給料日前は残高が薄くなり、給料日後に回復する — このサイクルが、決済の成否に直接効きます。海外の決済プラットフォーム（Stripe Smart Retries、Recurly Recover、Chargebee Dunning など）は機械学習ベースのリトライ最適化を提供していますが、これらはグローバル平均の成功確率を学習しているのであって、日本の給料日が特定日に集中する、年金支給日が偶数月にある、賞与月が偏っているといった地域固有のカレンダーまでは前提に組み込まれていません。
日本市場での回収率を最大化するなら、事業者側で「リトライ後にどう分類して、いつ次のアクションを取るか」を上乗せ設計する必要があります。海外データを引いた参考値では、適切なタイミング再試行により未払いの20〜40%（参考値）が回収可能とされています。
理想の状態 — タイミング設計が組み込まれた分類
残高不足エラーを最大限回収できる状態とは、次のようなものです。
- 残高不足エラーは「Soft Decline（一時的拒否）」として自動分類される
- 顧客の課金日が給料日前に当たっている場合、「給料日後リトライ候補」として推奨タイミングが提示される
- 業界特性に応じて、給与日・賞与月・年金支給日など複数のカレンダー軸が考慮される
- カード期限切れ・銀行による永続拒否などは別カテゴリとして分離され、適切な対応に振り分けられる
この状態を作るのは技術的に複雑ではありません。重要なのは「リトライ実行」と「リトライ後の対応分類」を別レイヤーとして設計する発想です。
Recovery Monitor が担うのは「リトライ後の対応分類」
Recovery Monitor はリトライそのものを実行する仕組みではありません。リトライは Stripe Recovery、Recurly Recover、Chargebee Dunning、もしくは自社で実装した決済代行会社経由のリトライがすでに動いている前提です。そのうえで Recovery Monitor が担当するのは、リトライ後に残った決済エラーを「次にどう動くべきか」で分類することに絞っています。残高不足・カード期限切れ・銀行による一時拒否・恒久的拒否といった複数カテゴリへの振り分けと、それぞれに対する推奨アクションの提示が役割です。
海外プラットフォームが培ってきたリトライ最適化と、日本の口座残高周期に最適化された分類ロジックを、「決済エラー管理（Payment Error Management）」という独立したレイヤーとして整理しました。複数の決済代行会社を併用している事業者でも、同じ分類軸でエラー一覧を扱えるようにする — これは技術的工夫というより、運用側の認知負荷を下げる設計です。
自社の残高不足エラーは何件、いくら戻せるのか
残高不足エラーの推定回収可能額は、月間の決済エラー件数と平均単価が分かれば概算できます。決済エラー試算ツールでは、自社の数字を入力すると参考値ベースで即座に表示されます。実データに基づく分類を試したい場合は、30 日間無料トライアルで Recovery Monitor の分類ロジックを自社の決済データに当てて、対応候補一覧を確認できます。カード番号・CVC は一切扱わない読み取り専用の分析サービスです。