Notionで継続請求・定期請求を管理する方法(次回請求日の数式から社外督促まで)

毎月の請求は、金額が同じでも「今月分を出し忘れる」「先月の入金がまだなのに次の請求を送る」の二つで静かに崩れていきます。継続案件が5件を超えたあたりから、頭の中の記憶だけでは請求漏れと入金確認漏れが同時に起き始めます。この記事は、継続請求・サブスクをNotionひとつで管理したい受託者・小規模事業者に向けて、請求DBの作り方・次回請求日の数式・そして上位記事がほぼ触れない「未入金の相手にだけ、社外にも督促を届ける」運用設計までを事実ベースでまとめたものです。
要点(TL;DR)
- 継続請求の管理は「請求DBの最小設計」「次回請求日の数式」「入金ステータスで督促を切り分ける運用」の3点で決まります。
- 単発請求との違いは、各レコードに次回請求日を持たせること。
dateAdd()で請求日から周期を足せば、次に出すべき日が自動で並びます。- Notion標準のReminder・Slack通知が届くのは「Notionを開く本人」だけ。取引先(社外)には一通も届きません。これが請求管理で大きな落とし穴になります。
- Kapselは、Notionの請求DBの期日とステータスを監視し、未入金のものだけをメールで督促します。入金済み・完了には送らないため「払った相手にまた催促が飛ぶ」事故を防げます。
継続請求の運用設計は、関連する請求リマインドの自動化やNotionの契約・サブスク管理と地続きです。本記事は「継続して発生する請求を、漏れなく出し、漏れなく回収する」ための設計に絞って解説します。
Notionで継続請求・定期請求を管理する全体像
結論から言うと、Notionでの継続請求管理は次の3レイヤーに分けて設計すると破綻しません。それぞれが「請求漏れ」「入金確認漏れ」「督促漏れ」という別々の事故に対応しています。
| レイヤー | 担うこと | 防げる事故 | 使う機能 |
|---|---|---|---|
| ① 請求DB設計 | 請求先・金額・請求日・入金日・状態を1件=1レコードで記録 | 情報の散在・二重請求 | データベース+プロパティ |
| ② 次回請求日の数式 | 周期(月次/年次)から次に出す日を自動算出 | 請求の出し忘れ | 数式(dateAdd/lets) |
| ③ 入金・督促の運用 | 未入金を抽出し、相手に督促を届ける | 入金確認漏れ・督促漏れ | ビュー+外向き通知 |
①②はNotion単体で完結します。③のうち「社内で未入金を一覧化する」まではNotionで可能ですが、「取引先に督促を届ける」はNotion標準の通知では届きません(後述)。まず①から順に作っていきます。
💡 ポイント:継続請求は「出す(請求)」と「回収する(入金)」の2サイクルが並走します。1つのDBで両方のステータスを持たせると、ビューを切り替えるだけで「今月出すもの」「まだ入金されていないもの」を同じデータから見られます。
継続請求DBの最小構成—請求先/請求日/金額/入金日/ステータスの5項目
最初から多機能にすると運用が続きません。継続請求の管理DBは、次の5項目前後があれば回ります。多く作るより、毎月必ず埋まる最小セットにするのがコツです。
| プロパティ名 | 型 | 役割 | 補足 |
|---|---|---|---|
| 請求先 | テキスト or リレーション | 誰への請求か | 取引先DBがあればリレーション推奨 |
| 請求日 | 日付 | いつ発行したか | 次回請求日の計算の起点になる |
| 金額 | 数値(通貨表示) | 請求額 | 表示オプションで¥表示に |
| 入金日 | 日付 | 入金を確認した日 | 空=未入金の判定に使う |
| ステータス | セレクト or ステータス | 請求済/入金待ち/入金済 | ビュー分割の軸になる |
💡 ポイント:「入金日」を日付プロパティにしておくと、空かどうかで未入金を機械的に判定でき、入金済みの集計も日付でできて一石二鳥です。チェックボックスより使い回しが効きます。
これに加えて、継続請求では請求周期(月次/年次など)と、通知の宛先になるメールアドレスをプロパティとして持たせておくと、後の自動化がそのまま乗ります。メールアドレスは請求先リレーション側に1つ持たせておくと重複入力を避けられます。
単発請求との違い—継続案件は『次回請求日』を持たせる
単発の請求DBと継続請求DBの決定的な違いは、各レコードが「次回いつ請求するか」を持つかどうかです。単発は一度送れば終わりなので次がありません。継続請求は「前回の請求日+周期」で次の請求日が決まるため、この1プロパティがあるだけで「次に何を出すべきか」が日付順に並びます。
| 観点 | 単発請求 | 継続請求・サブスク |
|---|---|---|
| 発行回数 | 1回 | 毎月/毎年くり返す |
| 次回請求日 | 不要 | 必須(周期で自動算出) |
| 管理の起点 | 案件ごと | 請求先×周期 |
| 事故 | 請求漏れ | 請求漏れ+二重請求 |
継続請求では「先月出したつもりが出していない」と「先月の分をもう一度出した」が両方起きます。次回請求日を数式で持たせることが、この両方の予防線になります。
案件DBとのリレーション+Rollupで累計請求額を見る
案件管理DBをすでに運用しているなら、請求DBを案件DBにリレーションでつなぎ、ロールアップで継続案件ごとの累計請求額・入金済み額を自動集計できます。手計算の必要がなくなり、案件単位の取りこぼしに気づけるのがメリットです。
- 案件DB側にロールアップを追加 → 関連する請求レコードの「金額」を**合計(Sum)**で集計 = 累計請求額。
- もう一つロールアップを足し、入金済みの金額だけを集計すれば「いくら回収済みか」も案件カードから見えます。
- 継続案件のページを開けば、過去の請求履歴と累計が1画面に並ぶため、更新・値上げ交渉の材料にもなります。
リレーションとロールアップの基本的な組み方はNotionの自動化入門側で触れています。ここでは「累計を人が電卓で出さなくて済む」のが継続請求における実利だと押さえてください。
次回請求日を数式で自動管理する
継続請求の心臓部が、この「次回請求日」の数式です。周期ぶんを請求日に足すだけなので、考え方さえ分かれば月次でも年次でも応用できます。
dateAdd/lets()を使った月次・年次サイクルの考え方
Notionの数式では、ある日付に一定期間を足す dateAdd(日付, 量, 単位) が使えます。たとえば請求日から1か月後を返すなら、次のように書くイメージです(構文は環境で細部が異なることがあるため、考え方として捉えてください)。
// 月次サイクル:請求日の1か月後を次回請求日に
dateAdd(prop("請求日"), 1, "months")
年次サイクルなら単位を "years" に変えるだけです。周期プロパティ(数値や選択)に応じて足す量を切り替えたい場合は、lets() で変数にまとめると読みやすくなります。
// 周期(月数)プロパティを使って月次/四半期/年次を切り替える例
lets(
cycle, prop("請求周期(月)"),
dateAdd(prop("請求日"), cycle, "months")
)
⚠️ 注意:数式プロパティは自動で翌月へ繰り越したりはしません。あくまで「今セットされている請求日を起点に、次回日を表示する」だけです。実際に次サイクルへ進めるには、請求を出したあとに請求日(または次回請求日)を人が更新するか、ボタン/オートメーションで前進させる運用を決めておく必要があります。ここを決めないと「次回請求日が過去のまま止まる」のが典型的なつまずきです。
残り日数を出したいときは dateBetween(prop("次回請求日"), now(), "days") で「今日から次回請求日まであと何日か」を数値で得られます。これが次の色分けの材料になります。
『あと○日』で色分けし請求漏れを視覚的に防ぐ
数値の残り日数だけでは見落とします。dateBetween の結果を条件分岐で絵文字・ラベルに変換し、一覧で色がつくようにすると、請求漏れが視覚的に拾えるようになります。
// 次回請求日までの残り日数をラベル化する例
lets(
d, dateBetween(prop("次回請求日"), now(), "days"),
ifs(
d < 0, "🔴 期限超過",
d <= 3, "🟠 まもなく",
d <= 7, "🟡 今週",
"🟢 先"
)
)
この数式列を使って「🔴/🟠」を上に並べるソート、または期限超過のみを抽出するフィルタを置けば、毎朝その一覧を見るだけで「今日出すべき請求」が分かります。手帳やカレンダーで請求日を別管理する必要がなくなるのが実利です。
💡 ポイント:色分けラベルは「人が見て気づく」ための仕組みです。この時点ではまだ通知は飛びません。人が毎日Notionを開く前提なので、開く習慣が切れると請求漏れに戻ります。通知で push したい場合は後半の督促設計に進みます。
数式での期日の色分け・残り日数の考え方はNotionリマインダーの基礎でも扱っています。
入金ステータスの設計で入金確認漏れを防ぐ
請求を出したら、次は「入金されたか」を取りこぼさない設計です。継続請求では件数が毎月積み上がるため、ステータスの持たせ方を間違えると「どれが未入金か」がすぐ埋もれます。
請求済/入金待ち/入金済の3〜4ステータスとビュー分割
ステータスは増やしすぎず、3〜4段階に絞るのが運用のコツです。多すぎると人によって付け方がぶれ、結局あてになりません。
| ステータス | 意味 | 次のアクション |
|---|---|---|
| 下書き(任意) | 請求準備中・未発行 | 発行して「請求済」へ |
| 請求済 | 発行して相手に送った | 入金予定日まで待つ |
| 入金待ち | 入金予定日を過ぎても未入金 | 督促の対象 |
| 入金済 | 入金を確認した | これ以上触らない・督促しない |
このステータスを軸に、同じDBをビューで切り替えます。ボードビューでステータス列ごとに並べれば全体像が、フィルタ付きのテーブルビューなら「入金待ちだけ」の作業リストが作れます。
- ボードビュー:ステータスで列分け → 請求全体のパイプラインを俯瞰。
- 「入金待ち」テーブル:ステータス=入金待ち かつ 入金日が空 で絞り込み → 今日追いかける相手だけが残る。
- 「今月請求」テーブル:次回請求日が今月 で絞り込み → 出し忘れ防止。
⚠️ 注意:ステータスと入金日プロパティは二重管理になりがちです。「入金日が入ったら自動で入金済にする」をデータベースオートメーションで組んでおくと、片方の更新忘れで未入金が残り続ける事故を防げます。
Notion標準Reminder/Slack通知の範囲—届くのは『Notionを開く本人』だけ
ここは継続請求でよく誤解されるポイントです。Notionの日付リマインダー(@リマインド)やSlack連携の通知は便利ですが、届く先はそのNotionワークスペースのメンバー本人です。言い換えると、通知は「自分(と社内)に、入金予定日の前日に気づかせる」ところまでしかできません。
| 通知手段 | 届く相手 | 継続請求での使いどころ |
|---|---|---|
| Notion日付リマインダー | 自分・メンションした社内メンバー | 自分への「前日に請求を出す」リマインド |
| Slack通知 | Slackに居る社内メンバー | 社内での入金予定日の共有 |
| メール(取引先向け) | Notion不要の社外も含む相手 | 取引先への請求・督促(標準機能では不可) |
つまり標準機能でできるのは「入金予定日の前日に自分が気づく」軽い督促設計までです。取引先が入金を忘れていても、Notion側のリマインダーは取引先には一通も届きません。継続請求で本当に減らしたいのは「相手が払い忘れている未入金」なので、ここで通知の設計を一段先へ進める必要があります。
定期請求の督促を社外のクライアントにも自動で届ける
継続請求の運用で最後に残るのが「出した請求が、期日を過ぎても入金されない」ケースです。ここは人が毎回メールを書くと気まずさと手間で後回しになり、結果として入金が遅れます。この区間を仕組みにするのが督促の自動化です。
Kapselとは、Notionの期日・担当・ステータスを監視し、条件に合うものだけを自動でメールリマインドするツールです。社内メンバーだけでなく、Notionを持たない社外の取引先にもメールで届き、受信者はログイン不要でそのまま受け取れます。Kapselは個人開発のツールで、Notionを外から補完する通知レイヤーという位置づけです。
期日とステータスを監視し、未入金のものだけメールで送る仕組み
Kapselは請求DBの期日プロパティとステータス(または入金日の有無)を監視し、「期日を過ぎていて、かつ入金済みでない」レコードだけを督促の対象にできます。送る文面には差し込み変数で請求先名・金額・期日を埋め込めるため、1件ずつ手書きする必要がありません。これにより、人が毎朝一覧を巡回して個別にメールを書く作業がなくなります。
督促は一度きりではなく、段階的に設計できるのが継続請求では重要です。上位の解説記事の多くは「入金予定日の前日に通知」で止まりますが、実務で効くのは期日後に何回・いつ送るかの段階設計です。
| 段階 | タイミング(例) | トーン | Kapselでの実現 |
|---|---|---|---|
| 予告 | 入金予定日の数日前 | やわらかい案内 | 定期便で期日前に配信 |
| 初回督促 | 期日当日〜数日後 | 事実確認 | 期限超過の督促対象に入る |
| 再督促 | 1〜2週間後 | 明確な依頼 | 未入金が続く限り再送 |
段階的な督促の文面は入金催促メールの例文や支払い遅延の催促に型があります。Kapselは「いつ・どの対象に送るか」の運用を自動化し、文面はこれらの型を差し込み変数で流用できます。
💡 ポイント:継続請求で怖いのは「毎月の少額未入金が積もる」ことです。1回の督促で止めず、未入金が続く限り段階的に送る設計にしておくと、少額だから後回し、が減ります。
完了・入金済みには送らない—事故防止を重要な設計ポイントにする
督促の自動化に踏み切れない最大の理由は「もう払った相手に、また催促が飛んだらどうしよう」という不安です。継続請求は毎月くり返すぶん、この事故の機会も毎月あります。
Kapselは入金済み・完了のステータスには送りません。監視しているのはあくまで「未入金のまま期日を過ぎたもの」なので、入金を確認してステータスを更新した(または入金日が入った)瞬間に、そのレコードは督促対象から外れます。督促を自動化しても「払ってくれた相手に催促が飛ぶ」事故を仕組みで防げる、というのが継続請求における大きな安心材料です。
毎月、全請求を手で巡回 → 未入金を目視で探す → 気まずさで督促を後回し → 入金遅延
未入金だけ自動抽出 → 段階的に自動督促 → 入金済みは自動で対象外 → 手動の巡回が不要になり気まずさも減る
受信者のクリックでNotionのステータスに書き戻る(双方向)
多くのNotion請求管理は「自分がNotion側で記録する」一方通行です。Kapselは受信者がメール内のボタンをワンクリックするだけで、その結果がNotionのステータスへ書き戻ります。取引先はNotionにログインする必要がなく、こちらは入金状況の反映を手入力で待たなくて済みます。
- 取引先側:メールを開いてワンクリックするだけ。Notionアカウント不要。
- 自分側:クリックの結果がNotionのステータスへ反映 → 次の督促対象から自動で外れる。
- 結果:請求DBが「実態と同期した状態」に保たれ、二重督促や確認漏れが減る。
この双方向性により、継続請求のDBが「送った/反応があった」の実態をそのまま映すようになります。Stripe Webhookのような外部決済連携はエンジニア向けで実装難度が高く、銀行振込には使えませんが、Kapselはステータスプロパティの監視だけで同種の「状態に応じて動く」自動化を、非エンジニアでも実現できます。
始め方(3ステップ)
- 既存の請求管理DB(請求日・ステータス・メールのプロパティがあるもの)をそのまま用意する。新しくテンプレートを作り直す必要はありません。
- KapselにNotionを接続し、監視する期日プロパティと「送らない」ステータス(入金済み・完了)を指定する。
- 送信条件(期限超過の督促・定期便)と差し込み文面を設定する。あとは条件に合う未入金だけに自動配信されます。
無料プラン(¥0)で接続と少量の送信を試せます。本格運用はStandard(¥1,980・税込)、複数のNotionワークスペースや差出人ブランディング(会社名・署名)が要る場合はPro(¥4,980・税込)です。まずは手持ちの請求DBを1つ接続し、未入金の1件に督促が正しく飛ぶか(入金済みには飛ばないか)を確かめるところから始めると安全です。
継続請求だけでなく、フリーランス全体の入金管理を整理したい場合はフリーランスの入金管理ハブ、月謝・会費のような定期集金は月謝・会費の未払い催促も近いケースです。
よくある質問(FAQ)
Notionで請求書管理はどう作る?
請求先・請求日・金額・入金日・ステータスの5項目前後をプロパティに持つデータベースを1つ作るのが基本です。金額は通貨表示にし、入金日は日付型にして空かどうかで未入金を判定します。ステータスでビューを分ければ「今月出すもの」「未入金のもの」を同じデータから切り替えて見られます。
Notionで繰り返しタスク(定期請求)を自動作成する方法は?
Notionのテンプレートボタンや繰り返しテンプレ機能で、毎月の請求レコードのひな形をワンクリック生成できます。ただし完全な自動発行ではなく、次回請求日の前進は人の操作やボタン/オートメーションで補うのが実務的です。詳しくはNotionの自動化を参照してください。
サブスクや継続案件の次回更新日・次回請求日をNotionの数式で自動計算するには?
dateAdd(prop("請求日"), 1, "months") のように、請求日に周期ぶんを足す数式で次回日を表示できます。周期をプロパティで切り替えたい場合は lets() で変数化すると読みやすくなります。ただし数式は表示するだけで自動繰り越しはしないため、請求後に起点日を更新する運用を決めておきます。
未入金・入金確認漏れを見逃さないためのNotionの使い方は?
入金日が空、かつ入金予定日を過ぎたレコードだけを抽出するフィルタビューを作り、毎日そこだけを見る運用が基本です。さらに dateBetween で残り日数を色分けすると見落としが減ります。人がNotionを開かない日が続くと漏れるため、相手への督促まで含めるなら通知の仕組み化が必要です。
NotionとStripeを連携して入金確認を自動化できる?
Stripe Webhook経由でNotionのステータスを更新する連携は技術的には可能ですが、実装にはコードが必要でエンジニア向けです。銀行振込など Stripe を使わない請求には適用できません。Kapselは決済連携なしに、ステータスプロパティの監視だけで「状態に応じて督促を送る/送らない」を実現できるため、非エンジニアでも扱えます。
フリーランスの請求管理におすすめのNotionテンプレートは?
請求先・請求日・金額・入金日・ステータスを持つシンプルなDBが続けやすいです。凝ったテンプレートより、毎月必ず埋まる最小構成が実務では強いです。既存のDBをそのまま使って督促だけ自動化する方法は請求リマインドの自動化にまとめています。
Notionのリマインダーは取引先(社外)にも届く?
いいえ。Notionの日付リマインダーやSlack通知が届くのは、そのワークスペースのメンバー本人だけです。Notionを使っていない取引先には届きません。社外の取引先に請求・督促をメールで届けたい場合は、Kapselのように外向きのメール通知を持つ仕組みが必要になります。
補足・注記
- 公開日:2026-10-11。
- Notionの機能(データベース、数式、
dateAdd/dateBetween/lets、テンプレートボタン、リマインダー、ロールアップ、データベースオートメーション等)および挙動は、Notion公式ヘルプを一次情報として参照しています。数式の構文やプラン別の提供範囲は変更されることがあるため、最新の仕様は公式ヘルプで確認してください。 - 本記事で紹介した数式は考え方を示す例であり、実際の環境・プロパティ名に合わせて調整が必要です。
- Kapselの機能(Notionの期日・担当・ステータスの監視、未入金のみへのメール督促、入金済み・完了の除外、差し込み変数、定期便、送信記録、受信者のワンクリックによるステータス書き戻し)および料金(税込:Free ¥0/Standard ¥1,980/Pro ¥4,980)は、執筆時点(2026-10-11)のものです。最新の提供内容は getkapsel.com で確認してください。


