%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
請求漏れを防ぐには、受注から請求までの状態をつなぎ、次の処理に進めない案件を見つけられるようにすることが重要です。
請求漏れを防ぐには、受注から請求までの状態をつなぎ、次の処理に進めない案件を見つけられるようにすることが重要です。
「納品した案件の請求書が発行されていなかった」「締め処理で売上計上漏れに気づいた」「担当者の異動後に未請求案件が見つかった」。こうした事態が起きたときは、受注後の情報と作業を順にたどります。提供完了が記録されていないのか、請求条件が確定していないのか、承認後の発行が止まっているのかで、直すべき工程が変わるためです。
請求漏れとは、請求が必要な商品やサービスについて、請求書の発行に至っていない状態です。売上計上漏れは、会計上記録すべき売上が適切に記録されていない状態を指します。請求書の発行状況だけで売上計上の要否や時期は決められません。それぞれに必要な情報と判断者を分けて確認します。
本記事では、受注、提供完了、請求、入金を案件単位でつなぐ方法を整理します。未処理を見つけたときの判断順序に加え、CRM上のデータ、通知、承認、照合をどの条件がそろった段階で整えるかを解説します。
本記事は「販売管理とは？業務フロー・システム化のメリット・選び方を基礎から解説」シリーズの一部です。
この記事でわかること
納品後の請求状況を追えない、月次決算で未処理案件が見つかる、担当者が替わると請求条件が分からなくなる場合に、原因の確認から運用の見直しまで、次の順序で進められます。
- 請求漏れと売上計上漏れが起きる原因 — 受注連絡、提供完了の記録、請求開始、承認、発行の履歴を並べ、情報の不足と作業の停止を見分けます。
- 受注から請求までをつなぐデータ設計 — 案件の識別子と状態をそろえ、未請求、意図的な保留、請求不要を区別します。
- 請求漏れ防止に役立つ自動化 — タスク、ドラフト、承認、アラート、突合を追加する前に、それぞれの開始条件と確認者を決めます。
- HubSpotを全体フローへ組み込む考え方 — 取引と請求情報を関連付け、担当者が対象案件から次の対応を判断できるようにします。
- 運用を定着させる進め方 — 未請求一覧で対象を確認し、例外案件や通知後の状態を使って入力項目と処理条件を見直します。
請求漏れ防止の起点は担当者ではなく業務設計
請求漏れが起きたら、まず受注後の処理をたどります。受注情報が経理へ届いていなかったのか、届いていても請求開始の条件が分からなかったのかによって、直す場所は異なります。状態が記録されていないなら入力方法を、状態は変わったのに作業が始まらないなら引き継ぎ条件を確認します。
注意喚起だけでは再発を防ぎにくい
「受注したら経理へ連絡する」「納品後は請求を忘れない」という周知だけでは、連絡を受けた後の作業状態を案件から確認できません。担当者の不在や引き継ぎがあっても処理を続けられるよう、受注状態を更新する人、請求開始を判断する人、発行後に入金を確認する人を決めます。
例えば提供完了後に請求書が見つからない案件では、最初に請求条件と検収状態を確認します。条件がそろっていれば請求担当者へ作業を渡し、未確定なら確認担当者と必要な判断を記録します。次の担当者が案件を開いてもこの区別ができない場合は、通知を増やす前に記録項目と更新責任者を決めます。
Excelやスプレッドシートに分散する管理の限界
スプレッドシート自体が問題なのではありません。営業の案件表、経理の請求一覧、担当者個人の進行表に同じ案件が別々に記録され、それぞれが手動で更新されると、どの記録を基準に次の処理へ進むかが分からなくなります。
まず受注識別子で記録を対応付け、提供完了状態、請求状態、請求予定日を比較します。状態が一致すれば担当者は次の作業へ進み、不一致があれば更新元と確認担当者を特定してから処理します。請求書の記録がない案件も、直ちに発行漏れと決めず、請求不要や承認待ちの理由が記録されているかを確かめます。
| 分散した管理 | つながった管理 |
|---|---|
| 受注連絡をメールやチャットで送る | 受注状態の更新を次の処理の起点にする |
| 営業と経理が別々の一覧を更新する | 同じ案件に請求状態を関連付ける |
| 担当者が期限を覚えておく | 請求予定日をデータとして管理する |
| 締め処理で未請求を探す | 未請求状態を日常的に抽出する |
| 例外対応を口頭で共有する | 例外の種類と承認状態を記録する |
コンタクトから請求までを一気通貫で捉える
CRMには顧客情報だけでなく、取引の進行と後工程に必要な情報を関連付けます。StartLinkは、営業プロセスを標準化し、部門間の引き継ぎと経営判断を支える業務基盤として設計することが重要だと考えています。
請求漏れ防止では、コンタクトや会社に関連する取引から、受注後の提供、請求、入金へ進む際に、どの状態を誰が更新するかを決めます。各部門が同じ案件を参照し、現在の状態と次の作業を確認できるかが判断基準です。対応する請求情報が見つからない場合は、請求開始条件を確認してから担当者へ渡します。
| 業務の状態 | 主に管理する情報 | 次の処理につながる条件 |
|---|---|---|
| 商談進行中 | 顧客、案件内容、金額、予定日 | 受注条件の確定 |
| 受注済み | 契約条件、提供内容、請求条件 | 納品やサービス提供の開始 |
| 提供完了 | 完了日、検収状態、請求可否 | 請求処理の開始 |
| 請求済み | 請求書識別子、請求日、支払条件 | 入金確認 |
| 入金確認済み | 入金日、入金額、消込状態 | 案件処理の完了 |
請求漏れと売上計上漏れが生まれる原因
原因を調べる際は、受注連絡、提供完了の記録、請求開始、承認、発行の順に履歴を並べます。状態は更新されたのに次工程が始まっていなければ引き継ぎ条件を、状態自体が更新されていなければ入力責任者と完了条件を見直します。会計上の記録に疑問がある案件は、請求処理の状況と分けて経理担当者が確認します。
手動の引き継ぎと属人化
受注後に営業担当者が経理担当者へメールやチャットで連絡し、それを見た経理担当者が請求書を作る流れでは、連絡を受けた後の作業状態が案件に残らないことがあります。対応が保留されても、案件側からは理由を判別できません。
特別な請求タイミングや顧客との合意を担当者だけが把握している場合は、他の担当者が請求可否を判断できません。請求条件と次の対応を案件に記録し、担当者が替わっても請求開始の可否を説明できるか確認します。説明できなければ、口頭の引き継ぎ内容を入力項目と判断手順に反映します。
| 原因 | 現場で見られる状態 | 生じる問題 |
|---|---|---|
| 手動連絡 | 受注後に個別のメールやチャットを送る | 連絡の見落としや対応保留を検知できない |
| 記憶への依存 | 特別な請求日を担当者が覚えている | 不在時に他の担当者が判断できない |
| 役割の曖昧さ | 営業と経理の双方が相手の対応を待つ | 請求開始の責任者が分からない |
| 口頭の例外対応 | 値引きや追加作業の扱いを口頭で決める | 判断の履歴が残らず引き継げない |
提供完了日と処理日のずれ
サービスの提供完了日、請求書の発行日、会計上の売上計上日が異なる案件では、請求書の発行有無だけで会計処理を判断できません。提供が完了した時点と、請求や計上の判断に必要な条件を分けて記録します。
月末に提供が完了して請求処理が翌月になった場合や、顧客の検収待ちで請求を保留した場合は、提供完了状態と請求可能状態を別々に確認します。継続契約や分割請求では、契約期間、今回の請求対象期間、請求済みの範囲、残額を並べます。対象範囲に未処理分があれば請求担当者へ、計上時期の判断が必要なら経理担当者へ渡します。
例えば、提供は完了していても顧客の検収結果を待っている案件では、請求書がないという結果だけで発行作業を始めません。検収が請求開始条件に含まれるかを契約条件と照らし、必要な確認が終わった時点で請求担当者が作業を始められる状態にします。
| 業務の状況 | 管理すべき情報 | 確認する点 |
|---|---|---|
| 月末の提供完了 | 提供完了日、請求予定日 | 計上対象の期間と請求処理の関係 |
| 顧客の検収待ち | 納品日、検収状態、検収完了日 | 請求開始条件が満たされているか |
| 継続契約 | 契約期間、更新状態、請求予定 | 対象期間の請求が作成されているか |
| 分割請求 | 請求予定、請求済みの範囲、残額 | 未処理分が残っていないか |
CRMと会計ソフトのデータ断絶
CRMで受注を管理し、会計ソフトで請求書を作成していても、両者を案件単位で照合できなければ請求状況を確認しにくくなります。営業側の「受注済み」と経理側の「請求済み」が別の識別方法で管理されている場合は、まず同じ案件を指しているかを確認します。
受注識別子と請求書識別子の対応を持ち、金額、請求先、請求対象の範囲を照合します。一致しない項目があれば、請求済みへ更新する前に、どちらの記録を誰が修正するか決めます。請求書が見つかっても対象範囲が違う場合は、対応済みと扱わず、請求担当者が不足分の有無を確認します。
例外案件が標準フローから外れる
値引き、無償提供後の有償切り替え、追加作業、スポット対応、分割請求などは、通常の請求フローと判断条件が異なります。例外と分かった時点で、請求可否を決める人と、標準フローへ戻す条件を記録します。
「請求不要」「承認待ち」「条件確認中」などの状態を分け、理由と判断者を残します。保留理由があっても次に確認する条件や担当者が決まっていなければ、その案件は確認対象に残します。これにより、意図的な保留と、判断が止まっている案件を区別できます。
受注から請求までをつなぐデータ設計
先に管理項目と状態の意味を定義します。受注識別子、提供完了状態、請求状態、請求予定日、例外区分を使い、未請求、意図的な保留、処理済みを区別できるか確認します。区別できない案件があれば、その判断に必要な項目を追加します。
受注と請求を案件単位で対応付ける
受注情報と請求情報を対応付けるには、それぞれを識別できる値を記録します。受注済みの案件から、対応する請求書が見つからないものを抽出して確認します。案件名だけでは表記揺れや重複によって対応付けを誤るおそれがあります。ただし、抽出された案件がすべて請求漏れとは限らないため、個別に請求状況を確認します。
分割請求では、請求書ごとに受注のどの範囲を請求しているかを照合し、その対応関係を記録します。識別子が一致していても対象範囲を確認できない請求書は、処理済みと判断せず確認対象として残します。
| データ項目 | 管理する内容 | 請求漏れ防止での役割 |
|---|---|---|
| 受注識別子 | 受注案件を区別する値 | 請求情報との照合基準にする |
| 提供完了状態 | 納品やサービス提供の進捗 | 請求開始条件を判断する |
| 請求状態 | 未請求、作成中、承認待ち、発行済み | 現在の処理段階を可視化する |
| 請求予定日 | 請求処理を開始する予定日 | 遅延や保留を検知する |
| 請求書識別子 | 対応する請求書を区別する値 | 発行済みであることを確認する |
| 入金状態 | 未入金、確認済み、消込済み | 請求後の処理を追跡する |
| 例外区分 | 値引き、分割、請求不要など | 標準フロー外の理由を明示する |
状態の遷移と担当部門を定義する
基本となる流れは、受注確定、提供完了、請求書作成、承認、発行、入金確認、消込という順序です。各状態について、移る条件、更新する担当者、次に始まる作業を決めます。
例えば「提供完了」は、納品やサービス提供が終わり、必要な検収情報を確認できる状態として定義します。「請求済み」は、請求書を作成中か、発行まで終えたかが混同されないようにします。
担当者ごとに状態の判断が分かれるなら、通知やタスクの設定へ進む前に定義をそろえます。同じ案件を見て同じ状態を選べるようになったら、その変更を起点に次工程を設定します。判断が分かれた案件は、どの情報が不足したかを記録し、状態の定義か入力時点のどちらを直すべきか決めます。
例外処理を標準フローへ戻す
例外案件も同じ管理対象に含め、例外区分と承認状態を記録します。例外一覧では、保留理由、判断者、次に確認する条件を見られるようにします。
| 例外の種類 | 登録する情報 | 標準フローへ戻す条件 |
|---|---|---|
| 値引き | 変更後の金額、理由、承認状態 | 金額の承認完了 |
| 分割請求 | 請求予定、各回の金額、処理状態 | 対象分の請求条件確定 |
| 無償提供 | 請求不要の理由、対象範囲 | 有償への切り替え条件成立 |
| 追加作業 | 作業内容、金額、顧客確認の状態 | 請求対象として承認 |
| 条件確認中 | 未確定事項、確認担当者 | 請求条件の確定 |
区分を作る際は、実際の例外案件を当てはめます。区分を選べても標準フローへ戻す条件を書けない場合は、名称より先に判断手順を見直します。既存の区分で扱えない案件が出たときに、区分の追加を検討します。承認後も保留状態に残る案件があれば、承認結果を誰がどの状態へ反映するか確認します。
更新履歴を引き継ぎに使う
請求状態だけでなく、誰が、どの判断で、いつ状態を変更したかを確認できるようにします。保留理由と次の対応も残せば、担当者が替わったときに案件の経緯をたどれます。
引き継ぎ時には、現在の状態を読んだ担当者が次の作業と判断者を説明できるか確認します。説明できなければ、履歴の記録方法や状態の定義を見直します。履歴に判断理由はあっても次の確認条件がなければ、引き継ぐ前に条件を明確にします。
パイプラインを請求漏れ防止に生かす設計
受注前に請求先や請求条件が未確定のまま進むと、その確認が受注後の担当者へ持ち越されます。取引パイプラインでは、受注時点で次工程に渡す情報を決め、確定していない条件をどこで確認するか明示します。
ステージ・角度・定義・必須プロパティをそろえる
パイプライン設計では、取引ステージ、角度、ステージ定義、必須入力プロパティをセットで考えます。受注ステージへ進む前に請求先、金額、請求条件を確認し、確定した情報は記録します。未確定の項目があれば、確認担当者と確定する段階を決めます。
| 設計要素 | 役割 | 請求業務との接続 |
|---|---|---|
| 取引ステージ | 商談の進行状態を表す | 受注後の処理を開始する起点になる |
| 角度 | 商談の見込みを整理する | 受注前の見込みと受注後の実績を区別する |
| ステージ定義 | その状態へ移る条件を示す | 受注や提供完了の判断をそろえる |
| 必須入力プロパティ | 次工程に必要な情報を集める | 請求先、金額、請求条件などの不足を防ぐ |
請求担当者が処理を始めるたびに営業担当者へ同じ項目を確認しているなら、受注時の入力設計を見直します。一方、受注時点では確定しない情報まで必須にせず、確定する状態と更新者を指定します。受注後に確定する項目は、請求開始前に誰が確認するかまで決めます。
項目は最小限から始める
入力項目を決めるときは、請求開始、請求書作成、承認、照合のどの判断に使うかを確認します。利用目的を説明できない項目は初期段階で追加せず、実際の案件で判断に必要と分かったときに追加します。
入力が欠けた案件を見つけたら、項目を増やす前に、既存項目の意味、入力する時点、更新担当者を確かめます。同じ情報が別の場所にあるなら、参照先を定めます。情報そのものがない場合に、判断に必要な項目として追加します。
受注ステージを後工程の起点にする
取引が受注ステージへ移ったら、請求担当者への通知、請求タスクの作成、必要情報の確認を始める設計にします。受注ステージは、次の担当者が案件を受け取れる状態を表す必要があります。
契約の合意、金額、請求条件を確認し、後工程に必要な情報がそろっていれば受注へ進めます。未確定の条件があれば、入力担当者へ確認を戻し、どの条件がそろえば進めるかを記録します。受注後に確定する条件については、請求開始までの保留理由と確認担当者を残します。
CRMだけで会計判断を完結させない
CRMでは顧客・会社・取引・請求状態の関連を確認し、確認が必要な案件を経理担当者へ渡せます。引き継ぐ際は、対象の取引と請求状態、判断が必要な点を明記します。ただし、CRM上の請求状態だけでは会計上の計上時期や税務上の扱いは決められません。経理担当者が契約内容と取引条件を確認して判断します。
提供完了日、検収完了日、請求日、契約上の条件を並べます。定めた処理条件に当てはまる案件は所定の確認へ進め、不一致や例外があれば承認対象にします。自動化する範囲と人が判断する範囲を、この時点で分けておきます。判断結果は案件から追えるように記録し、その結果を受けて請求状態と会計上の記録をそれぞれ確認します。
自動化で請求漏れを防止する
状態と担当者の定義がそろったら、未処理の検知と作業の受け渡しから自動化します。通知を受けた人が案件を開き、何を確認して次へ進むか分かるように設定します。対象案件を見ても判断が分かれる間は、先に状態の定義と入力内容を見直します。
受注確定を起点に請求タスクを作る
取引が受注状態になったら、請求担当者、期限、請求金額、請求先情報を確認するタスクを作成します。担当者を割り当てる条件には、案件の担当部門、顧客、契約種別など、社内で判断根拠を説明できる情報を使います。
タスクが完了しても請求状態が変わらない場合は、作業が終わったのか、状態の更新が漏れたのか確認できません。タスクの完了条件と請求状態の更新条件を対応付け、両者が一致しない案件を確認対象にします。請求条件が未確定なら、発行作業のタスクへ進める前に、条件を確認する担当者へ渡します。
請求書ドラフトと承認を分ける
請求書ドラフトの作成前に、金額、請求先、支払条件、請求対象を確認します。定めた条件に当てはまる案件はドラフト作成へ進め、値引き、分割請求、請求先の変更、追加作業がある案件は、変更内容を判断できる担当者へ渡します。
ドラフトの作成と発行の間には、内容確認と承認を置きます。承認者がどの情報を見て発行可否を決めるかを明示し、承認後に発行状態を更新します。差し戻された場合は、修正する項目と担当者を記録し、再確認の条件を明確にします。
見積書から請求書を自動生成する仕組みでは、見積情報を請求へ渡す際に確認する項目と、ドラフト作成後の承認を設計する考え方を解説しています。
未請求アラートを業務状態から出す
アラートは、業務上の不整合を知らせるために使います。提供が完了しているのに請求処理が始まっていない案件や、請求予定日を過ぎても請求書識別子がない案件を、確認する担当者へ渡します。
| 検知する状態 | 主な通知先 | 通知後の対応 |
|---|---|---|
| 受注済みで請求条件が未登録 | 営業担当者 | 不足情報を登録する |
| 提供完了で請求処理が未開始 | 請求担当者 | 請求可否と予定日を確認する |
| 請求書が承認待ちのまま | 承認者 | 内容を確認して判断する |
| 請求済みで入金が未確認 | 経理担当者と営業担当者 | 入金状況と顧客対応を確認する |
| 例外状態で更新がない | 案件担当者と管理者 | 保留理由と次の対応を見直す |
| 請求書発行後、支払期日を過ぎても入金が確認できない | 経理担当者 + 営業担当者 | 支払期日超過を検知した時 |
| 未請求案件の滞留を管理者へ通知 | 管理者 | 未請求案件の滞留を検知した時 |
| 受注確定後、納品が未完了 | 営業担当者 + 上長 | 毎週チェック |
各通知について、受け取った人が不足情報の登録、請求開始、承認、保留理由の更新のいずれを行うか決めます。通知後も状態が変わらない案件があれば、通知先、対象条件、対応手順を順に確認します。通知対象外で漏れが見つかった場合は、その案件が条件から外れた理由を調べ、検知条件を追加・修正します。
受注・請求・入金を突合する
受注データ、請求データ、入金データを案件単位で対応付けます。受注済みで請求書がない案件、請求済みで入金が確認できない案件、請求額と入金額が一致しない案件を分けて確認します。入金だけが存在し、対応する請求書を特定できない場合も、確認担当者を決めます。
突合の結果を見て、識別子の不一致なら対応関係を、金額の不一致なら請求・入金の記録を、処理待ちなら担当者と次の作業を確認します。不一致の理由を確かめる前に片方の記録へ合わせず、更新元と修正担当者を決めてから状態を更新します。見積から入金までを通した設計は「Quote-to-Cash（見積から入金まで）とは？業務フロー全体の設計と自動化のポイント」でも解説しています。
HubSpotを起点に一元管理・自動化・可視化する
HubSpotを活用する場合は、コンタクト、会社、取引、請求情報の関係を決めます。取引から請求状況をたどれるようにしたうえで、状態の変更をワークフローの起点とし、未処理案件をレポートで確認する順序で設計します。
取引レコードに請求情報を関連付ける
取引レコードに請求情報を関連付けると、営業担当者は商談の経緯と請求状況を同じ案件から確認できます。経理担当者も、請求がどの取引や会社に対応するかをたどれます。
取引レコードと請求情報の対応を確認し、請求状態を案件単位でたどります。
次の画像は、HubSpot取引レコードの請求情報一覧とfreee連携カードを示します。
取引の概要と請求情報を確認するときは、同じ案件を指しているか、請求状態がどこまで進んでいるかを見ます。対応する請求情報を見つけられない場合は、請求前の保留なのか、案件の識別方法や関連付けに問題があるのかを確認します。理由が分かったら、状態の更新か対応関係の修正を担当者へ割り当てます。
ワークフローで次の作業へつなぐ
取引ステージや請求状態の変更を起点に、担当者への通知、タスク作成、プロパティ更新を設定します。例えば、受注状態へ進んだ取引に請求予定日がなければ営業担当者へ確認を促し、提供完了後も請求状態が変わらなければ請求担当者へ渡す設計です。
設定前に、起点となる状態、完了条件、更新者、次の処理を案件ごとに書き出します。通常案件と例外案件で、同じ通知を出すべきかも確認します。担当者が同じサンプル案件を見て同じ処理を選べれば設定へ進み、判断が分かれるならステージ定義と入力ルールを修正します。
ダッシュボードで未処理を可視化する
ダッシュボードでは、受注済みで未請求の案件、請求済みで入金未確認の案件、請求処理が止まっている案件、例外状態の案件を区別します。対象を担当者、顧客、取引ステージ、請求状態で絞り、個別の取引までたどれるようにします。
案件ごとに担当者と次の対応を決められれば、その一覧を運用に使えます。一覧には載っているのに理由を判断できない案件があれば、表示項目や例外区分を見直します。複数の案件が同じ状態で止まるなら、担当者への通知に加え、ステージ定義やワークフローの条件を確認します。
会計ソフトとの連携範囲を決める
HubSpotと会計ソフトをつなぐ場合は、顧客・取引情報の更新元、請求・会計処理の更新元、同期する項目、更新方向、重複時の扱い、エラー時の確認担当者を整理します。更新元が曖昧な項目があれば、優先する記録と上書き条件を決めてから設定へ進みます。
請求書作成の連携を検討する際は、StartLinkが提供するSync for Money ForwardとSync for freeeも確認できます。導入経路として、Sync for freeeのHubSpotマーケットプレイスページとSync for Money ForwardのHubSpotマーケットプレイスページがあります。
連携後は、請求条件が未確定の案件と例外案件を分け、受注識別子、金額、請求先を照合してから処理します。エラーが出た場合は対象案件、応答内容、再処理の結果を記録し、原因を判断できない案件は担当者へ渡します。APIを使う構成では、利用するAPIの制限とエラーへの対応を実装前にHubSpotのAPI利用ガイドラインで確認します。
段階的に請求漏れ防止を定着させる
現状の流れをたどり、未請求案件を一覧にできる状態を作ってから、通知、ドラフト作成、突合へ進みます。各段階で実際の案件を確認し、次の処理に必要な情報がそろっているかを判断します。
現状フローと漏れた地点を可視化する
受注から入金までに誰が何を行い、どのシステムへ何を入力しているかを書き出します。請求漏れが起きた案件は、受注、提供完了、請求開始、承認、発行、入金確認の順に履歴を並べます。状態の更新が止まった地点では入力者と完了条件を、状態更新後に作業が止まった地点では通知先と次工程の開始条件を見直します。
| 確認対象 | 確認する内容 | 見直しにつなげる観点 |
|---|---|---|
| 受注時 | 誰が受注を確定し、何を登録するか | 次工程に必要な情報がそろうか |
| 提供完了時 | 完了を誰が判断し、どこへ記録するか | 請求開始条件が明確か |
| 請求時 | 誰が作成、承認、発行するか | 作業状態を追跡できるか |
| 入金時 | どの情報で請求と照合するか | 不一致を案件までたどれるか |
| 例外発生時 | 誰が判断し、理由をどこへ残すか | 標準フローへ戻せるか |
履歴をたどっても止まった地点が分からない場合は、次の仕組みを追加する前に、どの作業の開始と完了を記録する必要があるか決めます。地点を特定できたら、その工程に必要な入力、担当者、次へ進む条件を整えます。
未請求一覧とアラートから始める
受注済みで請求状態が未処理の案件を一覧にし、それぞれの請求可否、担当者、次の作業を確認します。請求不要や条件確認中の案件が混ざる場合は、先に例外状態を区別します。
一覧に載るべき案件が載らない場合は、アラートを追加する前に受注状態、提供完了状態、請求状態の入力ルールを見直します。一覧から対象案件を特定でき、通知先が次の作業を判断できるようになったら自動化へ進みます。判断できない案件が残る場合は、請求条件か保留理由のどちらが不足しているかを確認します。
請求書作成と突合へ広げる
未請求の検知が運用できたら、受注情報と請求条件を照合して請求書ドラフトを作り、担当者が金額と請求先を確認して承認する流れを検討します。会計ソフトとの連携や入金情報との突合を追加する際は、処理ごとに確認項目と不一致時の担当者を決めます。受注情報だけでは請求内容を確定できない場合は、担当者が判断します。
| 段階 | 実施する内容 | 確認する状態 |
|---|---|---|
| 現状整理 | 業務フローと過去の漏れ原因を整理する | 漏れた地点と理由を説明できる |
| データ整備 | 受注、提供完了、請求状態を関連付ける | 未請求案件を一覧にできる |
| 検知 | 未請求や保留案件を通知する | 通知後の担当者と対応が明確になる |
| 作成支援 | 請求書ドラフトと承認をつなぐ | 転記内容と承認履歴を確認できる |
| 突合と可視化 | 受注、請求、入金を照合する | 不一致を案件単位で追跡できる |
次の段階へ進む前に、その段階で見つかった案件の理由を担当者が説明できるか確かめます。説明できないまま処理を増やすと、未確定の条件や例外を次工程へ渡してしまうため、先に入力と判断手順を見直します。
テストと引き継ぎを運用に含める
自動化を公開する前に、通常案件、値引き、分割請求、請求不要、条件変更のテスト案件を用意します。起点となる状態を更新し、対象案件、通知先、作成されたタスク、請求状態を照合します。期待した状態と異なる案件があれば、公開前に条件を修正して再確認します。
運用手順には、担当者の交代時に確認する項目、エラー発生時の連絡先、例外区分を追加する基準を含めます。引き継いだ担当者が案件の状態から次の作業を決められるかを確認します。判断できなければ、担当者の説明に頼っている情報を特定し、案件から確認できる形に整えます。
運用後に見直す評価基準
運用を始めた後は、未処理案件とアラートの結果を確認します。総件数だけで判断せず、どの工程で止まり、担当者が何を確認すれば進めるかを見ます。未処理と判定された案件に、意図的な保留や請求不要が混ざっていないかも確認します。
未処理案件を状態別に確認する
提供完了後に請求処理が始まっていない案件、承認待ちの案件、例外条件の確認中の案件では、次に動く担当者が異なります。状態ごとに一覧を分け、止まっている理由を確認します。
| 確認する対象 | 分かること | 主な見直し先 |
|---|---|---|
| 受注済みで請求条件がない案件 | 営業から経理への情報不足 | 受注時の必須入力 |
| 提供完了で請求未処理の案件 | 請求開始の引き継ぎ漏れ | タスクと通知条件 |
| 承認待ちで止まる案件 | 承認経路の詰まり | 承認者と代替担当者 |
| 例外状態が長い案件 | 判断基準や責任者の不明確さ | 例外処理ルール |
| 請求と入金が一致しない案件 | 識別子や金額の不一致 | 連携項目と突合条件 |
一覧にある案件から理由と担当者を特定できれば、その状態に応じて処理します。理由が分からない案件が続く場合は、通知の頻度ではなく、状態を更新する条件と記録する情報を見直します。
アラートの有効性を見直す
アラートごとに、通知日時、通知先、対象案件、通知後の状態変更を並べます。通知を受けた担当者が必要な作業を行えたなら条件を維持します。状態が変わらなかった場合は、通知先、対象条件、対応手順の順に確認します。
不要な通知が届く場合は、例外状態や承認中の案件が対象に含まれていないか調べます。漏れが見つかったのに通知されなかった場合は、その案件がどの条件から外れたかを確認してから検知条件を直します。通知された案件を開いても対応方法が分からない場合は、通知文だけでなく、案件に残す請求条件や保留理由も確認します。
漏れた案件をプロセス改善へ戻す
請求漏れが見つかった場合は、受注情報、提供完了の記録、請求状態、通知履歴をたどります。入力値が欠けていれば入力時点と担当者を、状態更新後に止まっていれば次工程の開始条件を、例外判断で止まっていれば承認者と標準フローへ戻す条件を確認します。
修正後は、その案件と同じ条件で処理をたどり、担当者が次の作業を決められるかを確かめます。別の担当者でも同じ判断に至れるなら運用へ反映し、判断が分かれるなら条件の記録方法を再度見直します。
よくある質問
請求漏れ防止では、請求と売上計上をどう分けるか、どの情報から管理を始めるか、誰が判断を担うかが論点になります。次の質問では、未処理案件を見つけた後に確認する情報と、次の作業へ進む条件を整理します。
請求漏れと売上計上漏れは同じ問題ですか？
同じ問題ではありません。請求漏れは必要な請求書が発行されていない状態で、売上計上漏れは会計上記録すべき売上が適切に記録されていない状態です。
請求書の発行有無と会計処理の状態を別々に確認します。提供完了日や契約条件と会計上の記録に差がある場合は、経理担当者が計上時期を判断できるよう、関連する日付と条件をそろえて渡します。請求処理も未完了なら、その理由と請求開始条件を請求担当者が確認します。
請求漏れ防止で最初に整えるべきものは何ですか？
受注済みで請求が必要な案件を一覧にし、請求状態を確認できるようにします。そのために、受注を識別する情報、提供完了状態、請求状態、請求予定日を同じ案件に関連付けます。
一覧を作ったら、未請求、意図的な保留、請求不要を区別できるか確認します。区別できた案件から担当者と次の作業を決め、判断が分かれる案件では状態の定義を先に整えます。一覧に載らないはずの案件が混ざる場合も、検知条件を追加する前に例外区分と入力ルールを確認します。
スプレッドシートでも請求漏れを防げますか？
更新担当者と確認手順を明確にし、案件ごとの状態を照合できれば、スプレッドシートで管理する方法もあります。営業用と経理用の表を分ける場合は、共通の受注識別子で案件を対応付け、請求状態と更新日時を確認します。
記録が一致しなければ、どちらの情報を更新すべきかを担当者が判断してから次へ進みます。複数部門での更新や例外処理を追いにくくなったときは、どの情報の確認が止まるかを特定し、CRMや会計ソフトとの管理方法を見直します。
どの部門が請求漏れ防止を主導すべきですか？
受注条件を把握する営業部門、請求・入金を扱う経理部門、システムを管理する担当者が、状態と引き継ぎ条件を一緒に決めます。主導する部門は、案件全体の流れを確認し、部門をまたぐ未処理の判断者を決められるようにします。
受注条件の更新者、請求開始の担当者、請求内容の承認者、入金確認の担当者を状態ごとに割り当てます。責任者が決まらない状態があれば、その判断を終えてから通知や自動化を設定します。判断が必要な案件をどの部門へ戻すかも、あわせて決めます。
まとめ
請求漏れ防止では、受注、提供完了、請求、入金を案件単位でつなぎ、未処理や不一致を見つけた担当者が次の作業を決められるようにします。売上計上については、請求状態だけで確定せず、経理担当者が取引条件と記録を確認します。
まずは過去に請求漏れが起きた案件を使い、情報や作業が途切れた地点を確認してください。
- 受注から入金までの現状フローと担当者を書き出します。
- 受注済みで請求状態が未処理の案件を一覧にし、請求不要や保留中の案件を区別します。
- 状態を判断できない案件では入力項目と担当者を整え、判断できる案件から通知、承認、照合へ進みます。
企業様によって最適な形は異なります。現在の管理方法でどの状態を確認でき、どこで判断が止まるかを起点に、必要な項目と自動化の範囲を決めます。CRMを活用した業務効率化やAIとの連携については、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
