B2B SaaS企業のHubSpot、Stripe、NetSuiteを1セント単位で照合

課題

収益の仕組みは、パイプラインをHubSpot、サブスクリプションとカードをStripe、元帳とASC 606をNetSuiteで運用していました。ドラッグ＆ドロップ型のコネクタとCSVエクスポートでつないでいたため、3つのシステムは常に食い違っていました。請求スケジュールはCRMの契約条件からずれ、チャージバックはERP上の顧客残高に反映されず、毎月の月末には経理チームが8営業日をかけてStripeの入金を銀行口座と手作業で突き合わせていました。繰延収益はオフラインの償却ワークブックで管理されていました。

実施内容

コネクターを、認証付きの直接エンドポイントと決済エンジンに置き換えました。HubSpotで受注が成立すると、NetSuiteの顧客と受注伝票が作成され、税ID、通貨、子会社が検証され、Stripeの顧客とサブスクリプションスケジュールが作成されます。Stripeの各支払いWebhookは構成要素に分解されます。総額の顧客入金、正確な純入金額の仮勘定借方、処理手数料の費用計上が同一トランザクションで転記されます。案件の明細行は成立時に収益認識ルールへマッピングされるため、ASC 606の契約とその償却仕訳はワークブックなしで作成されます。すべてのペイロードはStripeのイベントIDに対してハッシュ化されるので、再送されたWebhookは作成済みのレコードを更新します。

この図はワークフロー設計の一つであり、統制ポイントと関連するエビデンスを含みます。

仕組みの概要

1. ゲートウェイ手数料の差異

   汎用コネクタは、$10,000の請求書に対して$10,000の入金を記録しますが、Stripeは$290の手数料を差し引いた$9,710を入金するため、銀行照合は1セント単位の調査作業になります。決済リスナーは残高取引を読み取り、総額、純額、手数料を1つの仕訳の3つの明細として計上するため、入金額は到着した当日に1セント単位で一致します。

2. ASC 606 複数要素の配分

   エンタープライズ案件では、導入サービス、年間ライセンス、従量課金ティアが一括で契約されますが、これらは顧客への請求方法にかかわらず、それぞれ異なる時期に収益認識されます。HubSpot の明細行は成約時に NetSuite の収益認識ルールへマッピングされるため、顧客が年額を前払いする場合でも、月額を後払いする場合でも、契約の登録と同時に、取引契約、繰延残高、償却仕訳が作成されます。

3. 冪等なリトライとWebhookの重複排除

   ネットワークは障害を起こし、Stripeは再送します。受信したすべてのペイロードは、Stripeのイベントidに対してSHA-256でハッシュ化され、管理された監査レコードに記録されます。重複イベントは既存のレコードを検出し、StripeにHTTP 200を返し、二重計上は行いません。

結果

この事例から得られる示唆

1. CRMは販売のため、ERPは真実のため

   営業担当者が総勘定元帳の税コードや為替レートを管理すべきではありません。商取引条件はCRMに記録し、会計ルールへの変換はコードで行います。

2. 取り込み時にゲートウェイ手数料を分割

   総額の入金だけを計上し、手数料を月次決算に残す連携は、経理チームを人間の計算機として働かせているのと同じです。

3. 直接エンドポイントは多段ミドルウェアに勝る

   スキーマ検証を備えた認証済みRESTletにより、1秒未満での計上、ミドルウェアのサブスクリプション不要、元帳に届く内容の完全な制御を実現します。

複合的な振り返り。クライアントはアーキタイプとして示しており、数値は仕組みを説明するためのものです。関連記事：ネイティブ連携とiPaaSミドルウェアの比較：クローズ時に引き継がれる継続的な負担