Notionで着手金・前受金を管理し、未入金だけを自動で督促して着手前に回収する方法
着手金をもらう約束だったのに、入金を確認しないまま作業に入ってしまい、納品間際で「まだ振り込まれていない」と気づく——受託の現場で起きやすい事故です。原因は担当者の不注意ではなく、着手金を後払いの請求書と同じ台帳で管理していることにあります。この記事は、着手金・前受金運用をしているフリーランス・制作会社に向けて、着手金を後払い請求と分けてNotionで継続管理し、未入金だけを自動で督促して「入金前に着手しない」を仕組みで守る方法を、請求書の実務とあわせて第三者視点で整理します。
この記事の要点（TL;DR）
- 着手金は「業務着手前に受け取る前払い」であり、納品後に発生する後払いの請求とは管理ルールが逆。同じ台帳で回すと「未入金のまま着手」という事故が起きる。
- 対策は会計ソフトの消込ではなく、着手金専用の列・ステータス・ビュー設計。入金ステータスに「着手可」を持たせ、着手の前提条件として使う。
- 未入金の着手金は「入金ステータス=未入金」のビューで抜き出し、取引先がNotionを使わなくてもメールで督促を自動化できる。入金済みには送らない（誤督促の防止）。
- Kapselとは、Notionの期日・担当・ステータスを監視し、Notionを使わない取引先にもメールで自動リマインド／督促を送り、受信者のワンクリックでNotionのステータスに書き戻すツールです。入金済み・完了には送りません。
着手金・前受金とは何か（後払いの請求書管理と分けて考える理由）
着手金・前受金とは、業務に着手する前・サービスを提供する前に、報酬の一部または全部を先に受け取るお金のことです。納品や検収を終えてから請求する「後払いの請求書」とは、お金が動く順序が逆になります。この順序の違いが、管理設計を分けるべき理由の核心です。
後払い請求は「納品 → 請求 → 入金」で進むため、入金が遅れても成果物はすでに相手に渡っています。一方の着手金は「契約 → 着手金入金 → 着手」で進むべきもので、入金前に着手してしまうと、未回収のまま労力だけを先に投下することになります。つまり後払い請求の督促が「渡したものの対価を回収する」話なのに対し、着手金の管理は「渡す（着手する）前に回収を確認する」話です。
着手金／前受金／内金／手付金の違い（前提として整理）
実務では似た言葉が混在します。会計・契約上の性格は次のように整理できます（既知の前提として一度確認しておけば十分です）。
| 用語 | 主な意味 | 性格・注意点 |
|---|---|---|
| 着手金 | 業務に着手する段階で受け取る報酬の一部 | 報酬の前払い的性格。成果物の対価に充当される |
| 前受金 | 商品・サービス提供前に受け取る代金 | 会計上は負債（前受金勘定）。提供完了で売上に振替 |
| 前払金（前渡金） | 代金を前もって支払うこと全般の総称 | 支払う側から見た呼び方として使われることが多い |
| 内金 | 代金の一部を前払いするもの | 手付と異なり、解除権（解約手付）としての性格は持たない |
| 手付金 | 契約成立の証として交付する金銭 | 解約手付なら、買主は放棄・売主は倍返しで解除し得る |
💡 ポイント：名称よりも「着手前に受け取る前払いか／納品後に請求する後払いか」で分類するのが管理上は実用的です。呼び方が何であれ、前払いは専用の管理ルールに乗せます。
なぜ「後払い請求の督促」と同じ管理にすると事故が起きるのか
後払い請求の台帳に着手金を混ぜると、次の3つのズレが生じます。
- 督促の緊急度が逆：後払いは「納品後なので多少遅れても成果物は守られている」。着手金は「入金前に着手すると無防備」。同じ優先度で並べると、本来いちばん急ぐべき着手金が埋もれます。
- 着手の可否判断ができない：後払い台帳は「請求したか・入金されたか」しか持たず、「このお金が入るまで作業を始めてはいけない」という着手ゲートの情報を表現できません。
- 消込のタイミングが違う：着手金は納品後の本請求で「受領済」として差し引く必要があり、後払い請求と同じ消込ロジックでは二重計上や差引漏れが起きやすくなります。
⚠️ 注意：着手金を後払い請求と同じ場所で管理している限り、「入金前に着手しない」というルールは人の記憶に頼り続けます。事故を防ぐには、台帳の構造そのものに着手ゲートを埋め込む必要があります。
Notionで着手金専用のデータベースを作る列（プロパティ）設計
事故を構造で防ぐ最初の一歩は、着手金を**専用データベース（以下、着手金DB）**として持つことです。後払い請求とは別テーブルにすることで、督促条件・着手ゲート・消込を独立して設計でき、「未入金のまま着手」を可視化できます。
必須プロパティ
次の7項目があれば、請求から督促、着手判断、本請求への差引までを一貫して追えます。各項目は「後で督促条件やビューの絞り込みに使う」ことを前提に型を選びます。
| プロパティ | 型 | 役割・ベネフィット |
|---|---|---|
| 取引先名 | テキスト／リレーション | 誰からの着手金かを特定。督促メールの宛名差し込みに使える |
| 案件 | リレーション（案件DB） | どの案件の着手金かを紐づけ、案件側に入金状況を反映できる |
| 着手金額 | 数値（円） | 回収予定額。未回収額の集計やロールアップに使う |
| 請求日 | 日付 | 請求を出した日。督促の起算点になる |
| 支払期限 | 日付 | 「期限を過ぎた未入金」を機械的に抽出する基準 |
| 入金ステータス | セレクト | 未請求／請求済・未入金／入金済（着手可）を1項目で表す中核 |
| メールアドレス | メール | 取引先がNotionを使わなくても督促を届ける宛先 |
💡 ポイント：支払期限とメールアドレスを最初から列として持つことが、後の自動督促を可能にします。ここが空欄だと「誰に・いつ送るか」を機械判定できず、結局は手作業に戻ります。
ステータスの選択肢設計（未請求／請求済・未入金／入金済・着手可）
入金ステータスは、督促と着手判断の両方を1つのセレクトで駆動させる心臓部です。最小構成は次の3段階です。
- 未請求 — 契約はしたが着手金の請求書をまだ出していない。督促対象外。
- 請求済・未入金 — 請求書を発行済みだが入金が確認できていない。督促対象であり、着手してはいけない状態。
- 入金済（着手可） — 入金を確認した。督促は停止し、着手してよい状態。
「入金済」と「着手可」を同じ状態に重ねているのが要点です。入金の確認＝着手の許可を1つのステータスで表すことで、「入金されたから着手できる」という条件を台帳の構造として持てます。
案件DBと着手金DBをリレーションで繋ぎ、入金状況を案件側に反映する
着手金DBと案件DBをリレーションで繋ぎ、案件側にロールアップで着手金の入金ステータスを引き込むと、案件を開くだけで「このプロジェクトは着手金が入っているか」を確認できます。制作を始める前に見るのは案件ページなので、入金確認をその場で完結させる狙いです。
| 設計 | 持たせ方 | 読者にとっての意味 |
|---|---|---|
| 着手金DB → 案件DB | リレーション（案件を選択） | 着手金が「どの案件のものか」を一意に特定 |
| 案件DB ← 着手金DB | ロールアップ（入金ステータスを表示） | 案件ページを開くだけで入金状況が分かる |
| 案件DB | フォーミュラ（着手可かどうかの判定表示） | 「着手OK／入金待ち」をひと目で色分けできる |
このようにリレーション＋ロールアップで繋ぐ設計は、月謝や会費の継続課金を案件・会員と紐づけて管理する考え方と共通します。継続課金側の運用ロジックは月謝・会費の未払いを防ぐ集金・督促の自動化でも整理しています。
未入金の着手金だけを抜き出すビューの作り方
専用DBを作ったら、次は未入金の着手金だけを常に見える場所に集める「督促ビュー」を用意します。全件を眺めて目視で探す運用は、件数が増えると見落としが生じやすくなります。ビューで条件を固定すれば、開いた瞬間に「今アクションすべき着手金」だけが並びます。
フィルタ条件（入金ステータス=未入金 AND 支払期限が過ぎている）
督促ビューの基本フィルタは次の2条件のANDです。
- 入金ステータス＝請求済・未入金（＝請求済みだが入っていない）
- 支払期限 is on or before 今日（＝期限を過ぎている。Notionの相対日付フィルタ「今日」を使う）
この2条件で、督促すべき着手金だけが残ります。さらに支払期限で昇順ソートすれば、滞留が長いものから上に並び、優先順位がそのまま可視化されます。期限前のものを早めに案内したい場合は、別ビューで「支払期限が3日以内」を抜き出し、予告リマインド用に分けておくと督促と予告を混同せずに回せます。
着手金に明確な期限がないケースの社内運用ルール
着手金は「契約後すぐ」「着手前まで」といった曖昧な言い方になりがちで、請求書に支払期限が明示されないことがあります。期限が無いと上記フィルタが機能しないため、社内で督促起算のルールを決めて支払期限列に必ず日付を入れる運用にします。
| 期限の定め方 | 支払期限列に入れる値の例 | 督促を始める目安 |
|---|---|---|
| 契約書に期日あり | その期日 | 期日の翌日から |
| 「着手前まで」等の曖昧な定め | 請求日＋7日などの社内標準 | 設定した期限の翌日から |
| 口頭のみ・未設定 | 請求日＋5営業日（暫定） | 暫定期限の翌日から確認 |
💡 ポイント：曖昧な期限こそ、社内で「請求日からN日」という既定値を決めておくと、担当者ごとの判断ブレがなくなり、督促開始が属人化しません。期限が無いのではなく、こちらで期限を置くのが実務のコツです。
着手金が未入金のまま着手してしまう事故を防ぐ運用
着手金管理の本丸は、督促そのものより「入金前に着手しない」を守ることです。回収が多少遅れても、着手前なら損失は労力ゼロで止められます。ここを仕組みにできるかどうかが、後払い請求の督促記事には無い着手金特有の設計ポイントです。
「着手可」のステータスを着手条件として使う
案件を進める前に、案件ページにロールアップされた入金ステータスが**「入金済（着手可）」になっているかを確認してから着手する**——これを業務フローの正式な手順に組み込みます。チェックリストや着手判定フォーミュラで「入金待ち」を赤く表示しておけば、確認を飛ばしにくくなります。
入金済みの着手金には督促を送らない設計の重要性
着手金の自動督促でもっとも避けたい事故は、すでに払ってくれた取引先に督促メールを送ってしまうことです。これは関係を損ない、信頼を一度で失いかねません。だからこそ督促の送信条件には「入金ステータス＝請求済・未入金」を必ず含め、入金済に変わった瞬間に送信対象から外れる設計にします。
⚠️ 注意：督促は「送る条件」だけでなく「送らない条件（停止条件）」を設計してはじめて安全に自動化できます。入金を確認したらステータスを即「入金済」に更新する運用を徹底し、ステータスが督促の唯一の判断材料になるようにします。
Notionを使わない取引先にも届く、着手金だけの自動督促（Kapsel接続）
ここまでの設計（専用DB・未入金ビュー・着手ゲート・停止条件）は、督促の送信を自動化してはじめて運用負荷ゼロになります。ところが取引先の多くはNotionを使っていないため、Notion内のリマインドやメンションは相手に届きません。このギャップを埋めるのがKapselです。
未入金の着手金だけをメールで自動リマインド（社外にも届く）
Kapselは着手金DBの「入金ステータス＝請求済・未入金 かつ 支払期限を過ぎている」といった条件を監視し、条件に合う着手金だけを、取引先のメールアドレス宛に自動でリマインド・督促します。相手はNotionアカウントもログインも不要でメールを受け取れるため、経理担当が毎回手作業で対象を確認して文面を送る巡回がなくなります。
受信者がメールのボタンを押すとNotionの入金ステータスが書き戻る（双方向）
さらにKapselのメールにはワンクリックのボタンを置け、取引先がそれを押すとNotionの入金ステータスが書き戻ります。つまり相手の操作がそのまま着手ゲートの開錠につながり、担当者が入金確認の反映を手入力する手間と、反映漏れによる二重督促が減ります。
期限超過の督促・定期便・送信記録で運用を回す
着手金は反応がないと着手が止まるため、段階的な追いかけが要ります。Kapselには期限超過の督促、一定間隔で送る定期便、誰にいつ送ったかの送信記録、宛名などを差し込む差し込み変数があり、手作業の督促を条件ドリブンの運用に置き換えられます。未入金一般の督促を段階設計する考え方は請求書の入金リマインドを自動化する方法、文面の型は未入金の催促メール文例集に整理しています。
着手金の請求書を出すときの注意点（実務の補完）
運用設計と並行して、着手金の請求書まわりの実務も押さえておきます。ここは会計・税務の一般知識で、設計の前提になる部分だけ簡潔に補完します。
発行タイミングと必須記載項目・インボイス制度対応
着手金の請求書は、契約締結後〜業務着手前に発行するのが基本です。着手前に入金を確認するという設計上、請求が遅れるほど着手も遅れるため、契約が固まったら速やかに出します。記載項目は通常の請求書と同じで、品目欄に「着手金」である旨を明記します。
| 必須記載項目 | 着手金での注意点 |
|---|---|
| 宛名（取引先名） | 正式名称で。督促メールの宛名とも一致させる |
| 発行日・取引年月日 | 発行日が督促の起算点。支払期限もあわせて明記 |
| 品目・内容 | 「着手金」「○○案件 着手金」と前払いである旨を明記 |
| 金額・税率・消費税額 | 税率（標準10%等）と税額を区分表示 |
| 登録番号（適格請求書） | インボイス制度対応時は発行事業者の登録番号を記載 |
💡 ポイント：適格請求書（インボイス）として発行する場合、登録番号・税率ごとの区分・税額の記載が要件です。着手金であっても要件は変わりません。
消費税・源泉徴収の扱い
着手金・前受金が課税取引（資産の譲渡・役務提供）の対価の一部であれば、消費税の課税対象になります。会計上は受領時に前受金（負債）として処理し、役務提供の完了時に売上へ振り替えるのが一般的です。源泉徴収については、報酬が原稿料・デザイン料など源泉徴収の対象となる報酬にあたる場合、その前払いである着手金部分も源泉徴収の対象になり得ます。具体的な判断は取引内容で変わるため、国税庁の資料や税理士で確認してください。
分割払い・中間金を設ける場合の請求書の出し方
大きな案件では「着手金 → 中間金 → 最終金」と分割するのが一般的です。各段階でそれぞれ請求書を発行し、着手金DBや請求管理では段階ごとに行（レコード）を分けて管理すると、どの段階が未入金かを個別に督促できます。
| 段階 | タイミング | 請求書の書き方 |
|---|---|---|
| 着手金 | 契約後〜着手前 | 「着手金（総額の○%）」と明記 |
| 中間金 | 一定の工程完了時 | 「中間金」とし、進捗の節目を明記 |
| 最終金（本請求） | 納品・検収後 | 総額から着手金・中間金を差し引く（下記） |
納品後の本請求書での着手金の記載方法
納品後の本請求書では、総額を示したうえで、受領済みの着手金・中間金を差し引く書き方が明快です。例として、品目に総額を記載し、その下に「着手金（受領済）」をマイナス表記、差引残額を請求額とします。備考に「着手金○○円は○月○日受領済」と添えると、取引先との金額認識のズレを防げます。
着手金・前払い導入そのものが未払い対策になる
着手金や前払いの導入は、文面の工夫以上に効く未払いリスク対策です。初回取引の相手や個人の取引先では特に、着手金を受け取ってから作業に入ることで、未回収のまま労力を投下するリスクを構造的に減らせます。契約書には返金条件・分割条件・支払期日を明記しておくと、後のトラブルを避けられます。契約・更新まわりの管理はNotionで契約・更新を管理する方法、商談から着手前段階の追客はNotionで見積・商談を追客する方法も参考になります。
それでも未入金が続くときの段階的エスカレーション
着手金が未入金のまま反応がない場合は、関係に配慮しつつ段階的に強度を上げます。
| 段階 | 内容 | 記録 |
|---|---|---|
| ①やんわり確認 | 「ご確認のお願い」。行き違いを前提に丁寧に | 送信記録を残す |
| ②明確な督促 | 支払期日・金額・振込先を明記した正式な督促 | 送信日時を記録 |
| ③内容証明・法的手段 | 内容証明郵便、支払督促・少額訴訟の検討 | 書面・配達証明を保管 |
遅延損害金まで含めて回収を検討する段階では、金額の目安を遅延損害金計算ツールで把握できます。より一般的な未入金の追いかけ方は未入金の督促を進める手順や支払い遅延の催促の進め方に整理しています。全体の入金管理フローはフリーランスの入金管理・督促を自動化する完全ガイドにまとめています。
よくある質問（FAQ）
着手金と前受金の違いは何ですか（推定）
着手金は「業務に着手する段階で受け取る報酬の一部」で、前払い的性格を持ちます。前受金は会計上の用語で、商品・サービスの提供前に受け取った代金を**負債（前受金勘定）**として処理するものです。着手金を受け取って会計処理すると、多くの場合その実体は前受金として計上されます。性格が重なる言葉と理解して差し支えありません。
着手金には消費税がかかりますか（推定）
その着手金が課税取引（資産の譲渡や役務の提供）の対価の一部であれば、消費税の課税対象になります。会計上は受領時に前受金として処理し、役務提供の完了時に売上へ振り替えるのが一般的です。取引の内容によって扱いが変わるため、国税庁の資料や税理士で確認してください。
着手金の請求書はいつ発行すればいいですか（推定）
契約締結後〜業務着手前が基本です。着手前の入金確認を前提にする場合、請求が遅れると着手も遅れるため、契約が固まり次第すみやかに発行し、支払期限を明記します。
着手金を支払ってもらえない場合はどうすればいいですか（推定）
まず行き違いを前提にやんわり確認し、反応がなければ支払期日・金額・振込先を明記した正式な督促に進みます。それでも支払われない場合は内容証明郵便や支払督促・少額訴訟を検討します。各段階で送信記録・書面を残しておくと、後の交渉や法的手続きで役立ちます。
着手金は後から返金しなければなりませんか（推定）
返金の要否は契約内容によります。トラブルを避けるため、着手金が返金対象になるか（着手後のキャンセル時の扱いなど）を契約書にあらかじめ明記しておくことが重要です。内金・手付金とは解除時の扱いが異なる点にも注意します。
着手金の適切な金額・割合はどのくらいが一般的ですか（推定）
案件規模や業界によりますが、総額の一定割合（例として3〜5割程度）を着手金とし、残りを中間金・最終金に分ける運用がよく見られます。初回取引やリスクの高い案件ほど着手金の割合を厚めにするのが一般的です。金額・割合は取引先と合意のうえ契約書に明記します。
着手金の領収書に収入印紙は必要ですか（推定）
金銭の受取書（領収書）は印紙税の課税文書にあたり、記載金額が一定額以上の場合に収入印紙が必要になります（電子発行など例外あり）。着手金の領収書も同様に扱われます。具体的な金額区分は国税庁の印紙税の資料で確認してください。
着手金が未入金のまま作業を始めてしまったらどうすればいいですか（推定・独自角度）
まず作業を止める前に、未入金である事実を記録し、取引先に支払いの確認を行います。再発を防ぐには、入金ステータスに「着手可」を持たせ、入金を確認するまで着手しない手順を業務フローに組み込むのが有効です。案件ページに入金状況をロールアップで表示しておくと、着手前の確認を飛ばしにくくなります。
まとめ
着手金・前受金の管理は、後払い請求の督促とは順序が逆の「渡す前に回収を確認する」問題です。会計ソフトの消込だけでは着手ゲートを表現できないため、Notionに着手金専用DBを作り、入金ステータスに「着手可」を兼ねさせ、未入金だけを抜き出すビューで可視化するのが実務的です。
- 着手金は後払い請求と別テーブルで管理し、入金ステータスを着手ゲートとして使う。
- 「請求済・未入金 かつ 期限超過」のビューで督促対象を自動抽出し、期限が曖昧なら社内既定で期限を置く。
- 取引先がNotionを使わなくても、Kapselで未入金の着手金だけをメール督促でき、ワンクリックで入金ステータスが書き戻る。入金済みには送らない。
まずは今ある案件DBの横に着手金DBを1つ作り、入金ステータスと支払期限・メールアドレスの3列を埋めるところから始められます。督促の自動化まで必要になったら、無料プラン（Free ¥0）で社外への送信を試し、本格運用はStandard（¥1,980）で広げられます。
補足・注記
- 公開日：2026-10-25。本記事は執筆時点の情報に基づく第三者視点の解説です。
- 着手金・前受金の会計処理、消費税の課税判断、源泉徴収の対象可否、印紙税（収入印紙）の要否は取引内容により異なります。実際の処理は国税庁の公表資料（消費税・源泉徴収・印紙税の各案内）や税理士等の専門家で確認してください。
- 契約条件（返金・分割・支払期日）は当事者間の契約に従います。法的手段（内容証明・支払督促・少額訴訟）の要否・手続きは個別事情により異なります。
- Notionの機能（データベース、リレーション、ロールアップ、フィルタ、相対日付フィルタ等）は、Notion公式ヘルプの記載に基づきます。仕様は変更される場合があります。
- Kapselの機能（Notionの期日・担当・ステータスの監視、社外へのメール自動リマインド／督促、ワンクリックでの書き戻し、期限超過の督促・対象の絞り込み・定期便・送信記録・差し込み変数、入金済み・完了への送信停止）および料金（税込：Free ¥0／Standard ¥1,980／Pro ¥4,980）は執筆時点のものです。最新はgetkapsel.comで確認してください。
