契約書と請求書をそろえる：請求から逆算する契約設計

見積書には「月額X円」と書かれているのに、契約書は年額一括払い、請求システムには月次請求として登録されている。同じ契約なのに、顧客・営業・経理がそれぞれ違う金額を「正しい金額」だと思っている状態です。

ここで壊れているのは価格そのものではありません。見積書、契約書、請求システムは、同じ契約を三つの版で記録しています。価格を、どの期間・どの単位・どの変更ルールで扱うかという取り決めが、資料ごとにずれているのです。

契約は請求システムから逆算して書く、というのが私の立場です

通常の商流は、価格表から始まり、営業が個別条件を詰め、契約書に落とし、最後に請求システムへ設定する、という順序で進みます。

私はこの順序そのものが、請求トラブルの主因だと考えています。価格表から契約書へという流れで書くと、契約書には文章として書けても、請求システムの設定粒度には分解できない条件が必ず残るからです。この条件を、本記事では「請求不能条項」と呼びます（定義は次節）。

だから私は、先に請求システムで設定できる形を固定し、契約文言と価格表をそこへ書き戻す逆算を推します。契約書を書いてから請求に合わせにいくのではなく、請求から契約書を書く。順序そのものを逆転させます。

ただし、この立場が効く範囲は限られます。請求運用が定型化しているBtoB SaaSの継続課金までです。個別大型契約のように、交渉そのものが価値の主戦場になる領域では、逆算より交渉余地を残すことのほうが優先されるため、ここでは扱いません。この境界は、リスト vs セールスプライシングで扱った「価格を先に固定できる条件」と「要件整理が先に必要な条件」の線引きと同じです。

本記事で使う二つの言葉

以降はこの二つの言葉で語ります。

検算可能性: 顧客が契約書と利用明細だけで、営業や経理に問い合わせずに請求額を自分で再現できる状態です。整合の到達点を、この一語に固定します。この定義は、姉妹記事「顧客が納得しやすい請求書の作り方」が扱う「追える請求書」――契約条件・数量と計算順序・変更差分を請求書だけで検算できる状態――と同じ地点を指します。あの記事が到達点（請求書そのものの設計）を扱うのに対し、本記事はその手前の工程、つまり契約書と請求システムの粒度を先にそろえる工程を担当します。

請求不能条項: 契約書には文章として書けるが、請求システムの設定粒度に分解できず、毎回人手の判断が要る条件です。ずれの発生源を、この語で名指します。

顧客が請求額を自分で再現しようとして詰まる場所は、姉妹記事の整理に沿って言えば、契約条件・数量と計算順序・変更差分のどれかが請求書から読み取れない場所です。これは自社の顧客対応を観察した一次情報ではなく、姉妹記事の枠組みを借りた分析です。本記事で言う請求不能条項は、この三点のどこかを構造的に生み出してしまう契約条項、と言い換えられます。

請求不能条項はどこで生まれるか

請求トラブルは、単価そのものの誤りより、契約開始日、支払い時点、利用量の測り方、途中変更の扱いが資料ごとに異なることから生まれます。表現がずれている資料の組み合わせを見ると、請求不能条項がどこに生まれるかが見えてきます。

四つの行に共通するのは、「契約書には書けているが、請求システムのどのフィールドに入れればいいか決まっていない」という構造です。これが、そのまま請求不能条項の実例になります。

ずれが放置されると、見積・申込書・請求書のどれを正とするかが曖昧になり、営業・契約管理・経理がそれぞれ個別に確認し直すことになります。そして、標準の請求設定から外れた個別調整という、見えにくいコストになりやすい例外作業が積み上がっていきます。

契約モデルを、請求不能条項が生まれやすい順に並べる

契約モデルを固定額・従量・混合の3つに分類する目的は、価格の種類に名前をつけることではありません。契約書に置くべき条件と、請求システムに設定すべき項目をそろえるためです。

3つを請求不能条項が生まれやすい順に並べ替えると、混合型がもっとも高リスクだというのが私の判断です。理由は数値ではなく構造にあります。固定額は契約期間と金額さえ決まれば請求は完結します。従量は計測単位さえ一致していれば請求は再現できます。混合型は、基本料金と超過単価のどちらを優先するか、繰越分をどう失効させるか、更新時に基本枠を見直すかどうかという、設定の分岐点そのものが増えます。分岐点が増えるほど、契約書には書けても請求システムの1フィールドには落ちない条件が残りやすくなります。

固定額契約は、価格表に「何が含まれるか」を書き、契約書に「いつまで有効か」と「どの変更が別見積になるか」を書けば足ります。従量契約では、画面上の利用ログ、請求明細、契約書の単位名が一つでもずれていると、顧客は請求額を再計算できなくなります。混合型は、基本料金と超過分のどちらが優先されるかを契約書で明示しない限り、請求システム側で毎回人の判断が入ります。

逆算の手順：請求項目を先に固定し、契約文言をそこへ書き戻す

1. 請求システムに必要な項目を先に洗い出す

請求システムに必要な情報を先に洗い出すと、契約書に必要な条項が見えてきます。価格表や契約書から書き始めると、この順序は逆転し、書いてから請求できるかどうかを後追いで確かめることになります。

先に請求項目を並べておくと、後から「契約書にはあるが請求できない条件」――請求不能条項――を減らせます。

2. 価格表の単位を、請求項目に対応する契約用語へ変換する

請求項目が決まったら、価格表の言葉を契約書の言葉に変換します。営業資料の言葉をそのまま契約書に移すと、運用上の解釈が残ることがあります。契約書では、請求システムで設定できる粒度まで分解します。

3. 途中変更のルールを、設定と文章の両方でそろえる

契約期間の途中で、数量追加、プラン変更、利用停止、請求先変更が起きます。ここを決めずに契約を始めると、請求担当が都度判断することになり、判断のたびに新しい請求不能条項が生まれます。

途中変更の条項は、顧客との交渉余地を残すほど曖昧になります。標準ルールと個別合意の余地を分けて書くと、請求担当の判断が入る回数を減らせます。

検算チェックリスト：検算可能性が壊れる典型ポイント順に

契約前と運用開始後、それぞれで確認すべき項目を、検算可能性が壊れやすい典型的な順に並べました。

契約前に確認すること

• 見積書、申込書、契約書でプラン名と数量が一致している
• 初回請求日と契約開始日の関係が明記されている
• 基本料金、追加料金、初期費用が分けて記載されている
• 割引の開始日、終了日、適用条件が明記されている
• 契約書の条件を請求システムに設定できる

運用開始後に確認すること

• 利用量の計測値と請求明細の単位が一致している
• 顧客に提示できる利用明細が残っている
• 途中変更の差額計算が社内で再現できる
• 更新時に旧条件と新条件を並べて確認できる
• 個別合意が発生した場合の承認ログが残っている

価格改定条項の考え方

価格を将来も変えない前提で契約を書くと、更新時の交渉が難しくなります。一方で、契約期間中に一方的に価格を変えられるように書くと、顧客の予算管理を損ねます。

ここでも問うべきことは同じです。改定条項は、契約書には書けても、請求システムのどのタイミングで、どの範囲に反映されるかが設定できなければ、それ自体が新しい請求不能条項になります。

条項例は、あくまで契約レビューの出発点です。

第X条（価格改定）
1. 当社は、契約更新時に次期の価格条件を提示できる。
2. 価格条件を変更する場合、当社は契約満了前の所定期日までに通知する。
3. 契約期間中の価格条件は、別途合意がある場合を除き変更しない。

実際の文言は、取引形態、管轄、社内の承認プロセスに合わせて確認してください。

私が契約書に求めているのは、逆算できているかどうかだけです

価格、契約、請求がずれるのは、たいてい価格表から書き始めて契約書に落とし、最後に請求システムに合わせようとするからです。私はこの順序を疑うところから始めるべきだと考えています。請求システムで設定できる形を先に固定し、契約文言と価格表をそこへ書き戻す。この一点さえ守れれば、固定額でも従量でも混合型でも、請求不能条項は大きく減らせます。

ただし、この原則が効くのは請求運用が定型化しているBtoB SaaSの継続課金までです。交渉そのものが価値の主戦場になる個別大型契約では、逆算より交渉余地を残すことを優先してください。

自社の見積書、契約書、請求設定を並べて、請求不能条項――契約書には書けるが請求システムには設定できない条件――がどこに残っているかを探してみることでしか、たぶん確かめられません。

参考リソース

• SaaS Revenue Recognition Guide - Stripe
• Subscription Billing Guide - Zuora
• Enterprise Sales Contracts Best Practices - Salesforce
• FASB ASC 606 Revenue Recognition Standard
• SaaS Pricing Models - OpenView
• Consumption-Based Pricing - Bessemer

“

請求/Billing シリーズ

導入

• 意味ある請求とは

詳細

• 契約体系との連動（この記事）
• リスト vs セールス
• BtoB変動の壁

応用

• Zuoraの成長理由

本記事は請求/Billingシリーズの一部です。