Deal-to-Cash / Business-Ideas

契約管理（Deal-to-Cash）業務の構造
— 10工程 × ツールカバレッジ × 組み合わせの継ぎ目

更新 2026-07-05 ・出典リポジトリ koike-ya/business-ideas ・関連 Issue #6（顧客ヒアリング）

申込〜契約〜請求〜入金〜提供の業務を操作者（現場・バックオフィス・経理）の視点で工程分解し、①既存ツールがどの工程を埋めているか、②複数ツールを組み合わせた時にどこがどう痛むか（継ぎ目）を体系化する。

0.一行結論

単一ツールで①〜⑩を通しでカバーする国産は無い（Scalebaseが最も広いがセールス主導寄り＋連携前提）。

現実の構成（HubSpot＋電子契約＋Stripe＋請求／会計＋内製プロビジョニング）は「工程ごとに別ツール」で、価値が漏れるのは工程そのものより「工程と工程のあいだ＝継ぎ目」。特に痛いのは ②締結↔④請求の条件転記／⑥→⑦振込消込／⑨提供と入金の連動／⑩変更解約の多重反映／証跡の分断。

1.業務の構造 — 10工程（Issue #6 のチェックリストと1:1）

「受注が決まった瞬間 → サービス提供開始・入金確認まで」を、実際に手を動かす順に。各工程で 誰が / 真実の源 / 次工程へ渡すもの / モード差（低単価カード vs 高単価請求書） を押さえる。

#	工程	主担当	真実の源	次へ渡すもの	モード差
①	受注確定（Deal成立）	営業	HubSpot Deal	契約条件（金額/商品/期間/相手方）	低単価はセルフ申込＝受注と同時のことも
②	申込・契約書の作成＋締結・署名・証跡	営業/バックオフィス＋顧客	契約書（締結後は電子契約の証跡）	締結済み契約＝請求の根拠	高単価は契約交渉あり／低単価は規約同意で軽い
③	社内承認フロー	マネージャ/経営	稟議・与信・値引き記録	承認済みの条件	高単価で重く、低単価はほぼスキップ
④	請求書発行（適格請求書）	バックオフィス/経理	請求書（インボイス番号・税区分）	債権＋請求書	低単価はカード即時で請求書省略も
⑤	入金	顧客	決済/入金データ	入金事実	カード（低単価）／銀行振込（高単価）で分岐
⑥	入金消込	経理	突合結果（入金↔請求）	消込済み債権	カード=自動／振込=手作業の温床
⑦	督促	経理/営業	未入金リスト	回収 or 貸倒判断	振込・請求書払いで発生、カードは失敗リトライ
⑧	会計仕訳	経理	会計帳簿（freee/MF/奉行）	記帳済み	—
⑨	提供開始と入金の連動	CS/プロダクト	提供状況（内製プロダクト）	「入金済み↔提供中」の一致	低単価は自動プロビジョニング／高単価は手動が多い
⑩	更新・変更・解約の反映（日割り）	営業/経理	変更後の契約・請求	改定された契約条件＋請求	サブスク・従量で頻発、日割り計算が絡む

狙い：Dealの情報が、契約→請求→入金→会計→提供へ「手で転記／目視突合」されている継ぎ目を、工程の間に特定する。そこが本プロダクトの束ねる価値。

2.ツール・カバレッジ・マトリクス

国内 SMB SaaS が使う主要プロダクトを ①〜⑩ に対してマッピング。

プロダクト（役割）	①	②締結	③	④請求	⑤入金	⑥消込	⑦督促	⑧会計	⑨提供	⑩変更
HubSpot（CRM）	◎	△¹	△	×²	△³	×	×	×	×	△
Cacheflow / HubSpot Commerce	○	○	○	○	○	△	△	×	×	○
クラウドサイン / GMOサイン	×	◎	×	×	×	×	×	×	×	×
freee / MF 請求	×	×	×	◎	△	△	○	↔	×	×
Stripe（PSP）	×	×	×	△	◎	◎	△	×	×	△
請求管理ロボ（ROBOT PAYMENT）	×	×	×	○	○	◎	◎	↔	×	△
Scalebase（アルプ）	↔	○⁴	△	◎	○	◎	○	○	△	◎
Salesforce Revenue Cloud	◎	○	○	○	○	○	○	○	△	○
freee / MF 会計	×	×	×	↔	×	△	×	◎	×	×
自社内製（提供・プロビジョニング）	×	×	×	×	×	×	×	×	◎	△

◎ 中核でカバー ○ カバー △ 部分・要連携 × 非対応 ↔ 連携で受け渡し

¹ HubSpot電子署名は日本では第三者連携（クラウドサイン等）が実質標準。 ² HubSpot単体で日本の適格請求書は出せない（登録番号・税率別端数なし）。 ³ 日本は Stripe連携が実質唯一、かつ JPYはカード中心（口座振替は弱い）。 ⁴ Scalebaseは2026年にクラウドサイン連携で締結→初回請求を自動化。

読み取り

①〜⑩を1本で通す国産は無い。 Scalebaseが最広（②〜⑧⑩）だが①はHubSpot連携頼み・⑨は薄い・セールス主導寄り。
電子契約勢（クラウドサイン等）は②で止まり、③以降に構造化データを渡さない（PDF＝人が読んで転記）。← 世界共通の分断。
HubSpotは①が強いが④以降がほぼ空（適格請求書×・非カード決済×・消込×・会計×）。→ 現場は複数ツールを縫う。
Salesforce Revenue Cloudは通しでカバーするが高価・重い・SF前提。

3.継ぎ目カタログ — 「この組み合わせだとこうつらい」本メモの核

想定構成＝あなたが手作りした現実解 HubSpot ＋クラウドサイン＋ Stripe ＋ freee/MF請求＋ freee/MF会計＋内製プロビジョニング。工程は各ツールが埋めるが、工程の"あいだ"で人がデータを運ぶ／目視で突合する。★＝価値が漏れる重点。

#	継ぎ目	何が起きるか	構造的な理由	手作業の量（要実測）	仮説/数字
S1	①→④ Deal→請求の転記	Dealの金額/商品/契約期間/顧客を請求書へ手入力	HubSpotが適格請求書を出せず別ツールへ手渡し	1件◯分 × 月◯件	H1／数字5
S2 ★	②締結→④請求条件の転記	締結した金額・開始日・期間を請求システムに再入力	電子契約はPDFで止まり構造化データを渡さない（③↔④分断）	1件◯分／齟齬◯件	H1／数字5
S3	⑤の分岐 2モード二重管理	低単価=セルフ+Stripeカード、高単価=営業+契約書+振込。台帳が2つ	PLGとsales-ledでツールも手順も分岐、集計が合わない	2フロー分の管理工数	H2／数字2
S4 ★	⑥→⑦ 銀行振込の消込	振込名義ゆらぎを入金明細と請求で目視突合	バーチャル口座が無いと自動特定できない（カードは自動）	月◯時間（最大のボトルネック候補）	H3／数字3
S5 ★	⑨ 提供と入金の連動	「払ったのに未提供／提供したのに未入金」	入金状態（Stripe/銀行）と提供状態（内製）が別システムで非同期	事故◯件/月・逸失◯円	数字4（トラブル例）
S6 ★	⑩ 変更・解約の多重反映	アップセル/解約を HubSpot・契約・請求・会計の4箇所に手で反映＋日割り	サブスクの状態が各ツールに分散、単一の真実が無い	1変更◯分・請求漏れ/過請求◯件	数字4／H1
S7 ★	横断証跡の分断	「誰がいつ何に同意し／いくら請求し／いつ入金したか」を1本で出せない	締結証跡=クラウドサイン、請求・入金履歴=別ツールで紐づかない	監査/トラブル時に◯時間	H4
S8	④ インボイス制度の継ぎ目	適格請求書のため freee/MF請求へ手渡し＋登録番号・税区分管理	HubSpot単体で適格請求書非対応	発行◯件/月＋確認工数	数字5／H1

示唆：価値が漏れているのは工程内部ではなく S2・S4・S5・S6・S7（＝継ぎ目）。ここが「束ねるオーケストレーション層」の狙い所。どれが実際に一番痛いかは未確定 → Issue #6 のヒアリングで各行に実測（分/件/円）を入れて確定する。

4.ヒアリング（Issue #6）への接続

この継ぎ目カタログの各行を、ヒアリングの 7つの数字 と 仮説 H1〜H6 で埋めにいく。

継ぎ目	ヒアリングで取る事実	対応する数字	検証する仮説
S1・S2・S8	Deal→契約→請求の手作業転記の箇所数・分/件	数字5（継ぎ目の箇所数）・数字3（工数）	H1
S3	カード/振込/口座振替/後払いの金額比率	数字2（決済手段比率）＝採算の鍵	H2
S4	振込消込の月間工数・名義ゆらぎ頻度	数字3（工数）	H3
S5・S6	直近の請求/入金/提供トラブルの具体例と損失	数字4（トラブルと損失）	—
S7	証跡を後から出せず困った具体例	数字4	H4
全体	この領域に払っている金額・意思決定者	数字6（コスト）・数字7（決裁者）	H5・H6

このメモの使い方（次アクション）

ヒアリング前に、相手企業が使うツールを §2 のマトリクスに当てはめ「その会社の構成」を1枚にする。
その構成で発生するはずの継ぎ目（§3）を仮説として持ち込み、実測（分/件/円）で埋める。
5〜10社で「どの継ぎ目が最も痛いか」の順位が出たら、MVPの初手（Phase1: Deal→申込書→クラウドサイン締結→請求書→振込明細取込）を、最痛の継ぎ目に合わせて確定する。

姉妹メモ：市場・競合視点は landscape.md、実装・採算（Stripe Connect・2%・消込アーキ）は implementation-notes.md、ヒアリング設計（Mom Test・7数字・H1〜H6）は customer-interview-guide.md。

business-ideas リポジトリの調査メモを HTML 化した閲覧用ビュー。内容の正はリポジトリの Markdown。