Notionで外注・発注を管理する——支払漏れを防ぐデータベース設計

外注先に払い忘れた、という経験はほとんどの人にないと思います。実際に起きるのは「請求書が来ていないことに気づかないまま2ヶ月過ぎた」「検収は終わっているのに発注書の控えがどこにあるか分からない」「今月いくら出ていくのかが、月末に通帳を見るまで分からない」のほうです。発注はSlackと見積書PDFとメールに散っていて、どこにも一覧がない。これが支払漏れの正体です。

Notionで外注・発注を管理するなら、発注を1件1行のデータベースにして、外注先データベースから支払サイト日数をロールアップで引き、支払予定日と支払ステータスを数式で自動で出す——この形にすると、手で入れるのは外注費・請求書受領日・支払日の3つだけになり、未払い合計と今月の支払額が常に見えている状態になります。

Notionの発注管理とは、外注1件（＝1つの発注）を1行としたデータベースに、案件・外注先・外注費・納期・請求書受領日・支払日といった情報をプロパティとして持たせ、支払予定日やステータスを数式で計算して、ビューで「今月払うもの」「まだ払っていないもの」に切り替えて見る管理方法です。

この記事の要点

• 発注は案件ページの中にメモとして書かず、独立したデータベースの1行にする
• 支払サイトは外注先データベースに1回だけ持ち、発注ごとに入力しない。支払予定日は数式で出す
• 見るビューは「今月の支払」「未払い一覧」「請求書待ち」の3つ。この記事の数式はそのままコピーして貼れる

なぜ発注を案件ページのメモにしてはいけないのか

案件管理をNotionで作っている場合、外注の情報は案件ページの中に書きたくなります。「デザイン Aさん 12万 8/20納品」のように1行メモで書けば、その案件を開けば分かるからです。

これが行き詰まるのは、案件をまたいで見たいときです。支払は案件単位ではなく月単位で発生します。「今月出ていくお金はいくらか」を知るには、進行中の案件を全部開いて、ページの中のメモを目で拾って足すことになります。案件が10本あれば10ページ開きます。月に一度ならまだしも、資金繰りの判断のたびにこれをやることになります。

もうひとつは、支払が終わったかどうかの状態を持てないことです。メモに「支払済」と書き足す運用は、書き忘れた瞬間に嘘になります。チェックボックスや日付プロパティなら、空かどうかでフィルタできます。外注管理をどう組み立てるかの全体像は外注管理の方法にまとめています。

発注を独立したデータベースにすると、案件からはリレーションで見え、月からはビューで見えます。同じ1行を2つの切り口から見られるのが、データベースにする理由です。

発注データベースのプロパティ設計

フルページのデータベースを作ります。空のページで /table と打ち、「データベース - フルページ」を選びます。プロパティは次の20個です。

手で入れるのは10個、残り10個は数式とロールアップです。発注時に入れるのは案件・外注先・発注内容・発注日・納期・外注費の6つ、検収のときに検収チェック、請求書が届いたら受領日、払ったら支払日。追加入力は1件につき3回だけです。

外注先データベース

外注先は小さくて構いません。重要なのは支払サイト日数を数値で持つことです。

支払サイトを「翌月末」のような文字列ではなく日数で持つのは、数式で足すためです。月末締め翌月末払いなら45日、翌々月末払いなら75日あたりが目安になります。厳密な日付が必要な取引先は、支払サイト日数を0にして支払予定日を手で入れる運用に切り替えてください。支払サイトそのものの決め方は支払いサイトとはを参照してください。

外注先を選ぶ段階の見方は外注先の探し方と選び方に書いています。

コピーして使う数式——支払予定日・源泉徴収・支払ステータス

以下はNotionの数式2.0の記法です。プロパティ名は上の表と同じにしてください。名前を変える場合は prop("...") の中も合わせて変えます。

支払サイト日数（ロールアップ）は、リレーション＝外注先、プロパティ＝支払サイト日数、計算＝合計を選びます。「元の値を表示」にすると数式側でリストとして扱われて足せません。外注先は1件しかつながないので、合計＝その外注先の値になります。

消費税（数式。税率10%前提）:

round(prop("外注費（税抜）") * 0.1)

外注費（税込）（数式）:

prop("外注費（税抜）") + prop("消費税")

源泉徴収税額（数式。100万円以下は10.21%、超えた部分は20.42%）:

if(
  not prop("源泉徴収あり"),
  0,
  if(
    prop("外注費（税抜）") <= 1000000,
    floor(prop("外注費（税抜）") * 0.1021),
    floor((prop("外注費（税抜）") - 1000000) * 0.2042) + 102100
  )
)

税額は、支払金額が100万円以下なら10.21%、100万円を超える場合は超えた部分に20.42%を掛けて102,100円を足し、1円未満は切り捨てます（出典：国税庁「No.2795 原稿料や講演料等を支払ったとき」、2026年10月1日確認）。外注費（税抜）を元に計算しているのは、請求書で報酬の額と消費税額が明確に分かれていれば、報酬の額だけを源泉徴収の対象にしてよいとされているためです（出典：国税庁「No.2795 原稿料や講演料等を支払ったとき」、2026年10月1日確認）。

源泉徴収が必要かどうかは、相手が個人か法人か、報酬の種類が何かで変わります。法人に支払う報酬で源泉徴収の対象になるのは、馬主である法人に支払う競馬の賞金だけです（出典：国税庁「No.2792 源泉徴収が必要な報酬・料金等とは」、2026年10月1日確認）。個人に支払う原稿料や、グラフィックデザイン・広告デザインなどのデザイン料は対象です（出典：国税庁「所得税基本通達〔原稿等の報酬又は料金（第1号関係）〕」、2026年10月1日確認）。ただし、個人への外注がすべて対象になるわけではありません。チェックボックスにしているのは、この判断を人がするためです。

振込額（数式）:

prop("外注費（税込）") - prop("源泉徴収税額")

支払予定日（数式）:

dateAdd(prop("請求書受領日"), prop("支払サイト日数"), "days")

請求書受領日が空のあいだは結果も空になるので、条件分岐は要りません。

支払ステータス（数式）:

if(
  not empty(prop("支払日")),
  "支払済",
  if(
    empty(prop("支払予定日")),
    "請求書待ち",
    if(prop("支払予定日") < now(), "⚠️ 超過", "支払予定")
  )
)

未払い額（数式）:

if(empty(prop("支払日")), prop("振込額"), 0)

支払月（数式。月でグループ化するためのキー）:

formatDate(prop("支払予定日"), "YYYY-MM")

未払い額をわざわざ数式で持つのは、ビュー下部の計算行で「合計」を選ぶだけで未払い総額が出るようにするためです。フィルタで絞った合計でもよいのですが、フィルタを変えると数字も変わってしまうので、どのビューで見ても同じ意味になる列を1つ用意しておくほうが安全です。

ビューを3つ作る——今月の支払・未払い一覧・請求書待ち

データベースは1つのまま、ビューだけ増やします。

「今月の支払」は月初に開いて、振込額の合計を見ます。これが今月出ていく外注費です。入金予定と突き合わせれば、その月に手元が足りるかが分かります。

「未払い一覧」を支払予定日の昇順にしておくと、超過している行が一番上に来ます。支払ステータスが「⚠️ 超過」の行は、払い忘れているか、請求書の日付を入れ間違えているかのどちらかです。

「請求書待ち」が支払漏れを防ぐうえで一番効きます。検収は終わったのに請求書が来ていない発注が並ぶビューです。ここに2週間以上いる行があったら、相手に請求書の発行を促します。支払漏れの多くは「払い忘れ」ではなく「請求書が来ていないことに気づいていない」なので、この1ビューで大半が消えます。請求と入金の側の手順は請求・入金管理のやり方にまとめています。

「外注先別」はグループ化ビューです。次に同じ工程を頼むときに、前回いくらで誰に頼んだかをここで見ます。

発注書のテンプレートをページの中に置く

発注DBの「新規」ボタンの右の ∨ から「新しいテンプレート」を選ぶと、中身つきの新規行を作れます。発注は毎回書くことが同じなので、ここに発注書の本文を置いておくと、コピーして送るだけになります。

置いておく項目は次の6つです。

1. 件名（案件名と工程）
2. 作業範囲（やること・やらないこと）
3. 納品物の形式と納品方法
4. 納期と、こちらが素材を渡す期限
5. 金額（税抜・税込）と支払条件（請求書受領月の翌月末払い、など）
6. 修正回数の上限と、それを超えた場合の扱い

4番と6番を最初に書いておくと、無償対応で外注費が膨らむのを防げます。素材を渡すのが遅れたのに納期だけそのまま、という形になりやすいので、こちらの期限も同じ紙に書いておきます。

テンプレートの本文はページ側に置き、金額や納期はプロパティ側に入れます。両方に同じ数字を書くと、あとで直したときにどちらかが古くなります。

Notionで発注管理を作るときに詰まる3点

正直に書いておきます。この設計でも、次の3つは素直にはいきません。

1. 月別の支払予定を横に並べられない。 「今月の支払」ビューで今月の合計は出せますが、3ヶ月先までを月ごとに横並びで見る形にはなりません。ビューを月ごとに複製する手はありますが、月が変わるたびにフィルタを直すことになります。先々の資金繰りを月単位で見たい場合は、スプレッドシートの資金繰り表を併用するのが現実的です。
2. 期日の通知が弱い。 支払予定日が近づいたら知らせる、という動きは数式では作れません。データベースオートメーションを使う方法がありますが、無料プランで作れるのはSlack通知のオートメーションだけで、それ以外は有料プランの機能です（出典：Notion「Notionのデータベースのオートメーション」、2026年10月1日確認）。ビューを週1で開く運用のほうが確実です。
3. 粗利と支払を同じ画面で見られない。 案件DB側で外注費の合計をロールアップすれば粗利は出せますが、「粗利が薄い案件の支払がいつ出ていくのか」を1画面で見ようとすると、ロールアップを何段も重ねることになります。案件側の作り方はNotionで受託の案件管理を作るに書いていますが、発注DBと案件DBをまたいだ集計はNotionの苦手な領域です。

無料プランについては、Notionの料金ページで制限として挙がっているのが、2人以上のメンバーで使う場合のブロック数、外部ゲスト10人まで、ページ履歴7日などで、リレーション・ロールアップ・数式はプラン比較の項目に入っていません（出典：Notion「料金プラン」、2026年10月1日確認）。

発注と支払を案件の粗利と同じ画面で見る

ここからは自社製品の紹介です。私たちが作っている Pipelia では、発注ごとの外注費・進捗・支払状況（未払い／支払予定／支払済）が案件とつながっていて、未払い合計が常に見えています。入金予定と支払予定は12ヶ月先まで月次で突き合わさるので、上の3点目に挙げた「粗利が薄い案件の支払がいつ出ていくか」が1画面に出ます。

外注先もPipeliaを使っていれば、こちらの発注がそのまま相手の受注になり、進捗と支払状況が共有されます。登録なしで触れるデモを demo.pipelia.com に置いています。

同じ発注台帳をGoogleスプレッドシートで作る場合の列設計と数式は発注管理表をスプレッドシートで作るにまとめています。

よくある質問

発注データベースを作らず、案件データベースに外注費の列を足すだけではだめですか？

1つの案件に外注が1件しかない前提なら足りますが、デザインとコーディングを別の人に頼んだ時点で合計が出せなくなります。列を「外注費1」「外注費2」と増やす方法もありますが、3件目が来ると破綻しますし、支払日や請求書受領日も同じ数だけ増えます。発注を別データベースにしてリレーションでつなげば、何件ぶら下がってもロールアップの合計が自動で追従します。

Notionの無料プランでも、この発注管理は作れますか？

この記事の設計はリレーション・ロールアップ・数式だけで組んでいて、Notionの料金ページのプラン比較では、この3つは制限の項目に入っていません。無料プランの制限として挙がっているのは、2人以上のメンバーで使う場合のブロック数、外部ゲスト10人まで、ページ履歴7日などです（出典：Notion「料金プラン」、2026年10月1日確認）。データベースオートメーションで通知を飛ばしたい場合は、無料プランで作れるのがSlack通知のオートメーションに限られます（出典：Notion「Notionのデータベースのオートメーション」、2026年10月1日確認）。

支払条件が「月末締め翌月末払い」の場合、支払サイト日数は何日にすればよいですか？

月末締め翌月末払いは、締め日からの日数が月によって変わるため、日数で表すと28日から31日の幅が出ます。請求書受領日を起点にすると実務上は45日前後になることが多いので、まずは45日で入れて、数ヶ月運用してから実際の着金日とのズレで調整するのが簡単です。日付を厳密に合わせたい取引先については、支払サイト日数を0にして支払予定日を手入力に切り替えてください。