Notionとfreee請求書を連携するには？案件DB・分割請求・経理確認の設計

Notionとfreee請求書は、APIや外部の自動化サービスを使って連携できます。Notionにある案件名、取引先、請求対象の金額や明細を使い、freee請求書へ転記する構成です。

実務で最初に目指しやすいのは、Notionで請求候補を管理し、経理の確認後にfreeeへ送付前の請求書を作る流れです。分割請求や金額変更がある会社では、案件のステータスだけで自動発行するより、この確認工程を先に決めると運用を組み立てやすくなります。

この記事では、営業・経理・開発担当者が一緒に検討できるよう、案件DBの項目、接続設定、プログラムを動かす場所、重複や訂正への対応を整理します。掲載するDBや承認フローは設計例です。自社の請求条件と権限に合わせて調整してください。

Notionとfreeeは何を連携させるのか

Notionには、案件の進捗と「これから請求する内容」を置きます。作成した請求書の正式な内容や送付状態はfreeeで確認し、Notionには請求書IDと処理結果を戻します。

管理する内容	主に管理する場所	連携で行うこと
案件名、契約範囲、営業担当、検収の確認	Notion	請求してよい案件を絞る
請求回、対象期間、請求予定の明細	Notionの請求予定DB	今回作る1件分の情報を揃える
取引先ID、帳票の設定、作成した請求書	freee	確認済みデータから請求書を作る
請求書ID、作成結果、エラー、確認日時	連携側の記録とNotion	作成済みか、確認が必要かを追う
顧客への送付、会計取引への反映、決済の確認	freee側の運用	請求書の作成とは別に管理する

freeeの公式リファレンスには、請求書の作成・取得・更新のAPIが用意されています。取引先などの会計マスタはfreee会計APIで扱うため、請求書APIだけで必要なマスタ操作もすべて済むとは限りません。

freee公式：請求書APIリファレンス

ここでいう「請求候補」はNotionで人が確認するための業務上の状態です。freeeのAPIに同名のステータスがある、という意味ではありません。また、請求書の作成と、会計連携で使う「取引の下書き」も別に考えます。

連携方法はノーコード・API・MCPから選ぶ

「Notionとfreeeをつなぎたい」だけでは、最適な方法は決まりません。毎月同じ条件で1件作るのか、複数案件を合算するのか、分割請求があるのかで必要な処理が変わるからです。

方法	向いている場面	選ぶ前に確認すること
freee側の既存機能と手作業	件数が少なく、毎月の内容もほぼ同じ	転記にかかる時間が、連携の維持費を上回るか
Yoomなどの自動化サービス	条件が比較的単純で、対応アクションに収まる	必須項目、条件分岐、作成結果の取得、エラー時の確認方法
自作のAPI連携	分割・合算・独自の承認や照合が必要	実行環境、認証更新、重複防止、保守担当と費用
MCPを使うAIエージェント	担当者が対話しながら情報取得や作成を進めたい	対応する操作、対象事業所、実行内容の確認、継続実行の管理

たとえばYoomには、Notionの更新を検知し、レコードを取得して条件分岐し、freee請求書を作る設定例があります。まずはこうした既存のアクションで、自社の請求条件を表現できるかを確認するとよいでしょう。

Yoom：Notionのステータス更新からfreee請求書を作成する設定例

MCPで連携する場合も、請求金額や税区分の確定、作成してよい対象の判定は残ります。AIに文章で指示できることと、毎月の請求を誤りなく継続処理できることは分けて検討します。

外部ツールを使う際の権限や連携台帳は、次の記事で説明しています。

Notionインテグレーションの基本と権限管理

案件DBと請求予定DBを分ける

分割請求があるなら、Notionは「1案件＝1請求書」に固定しない方が扱いやすくなります。案件DBに対して、請求予定DBの複数レコードを関連付ける構成を考えましょう。

1案件を2回に分けて請求する例

たとえば、税抜契約金額30万円を、着手時12万円・納品時18万円に分ける案件を考えます。金額は説明用の架空の例です。

案件ID	請求予定ID	請求回	税抜の請求予定額	作成してよい条件
PJ-1042	BILL-1042-01	着手時	120,000円	契約内容と着手条件を確認済み
PJ-1042	BILL-1042-02	納品時	180,000円	納品・検収など契約上の条件を確認済み

案件が「受注」に変わっただけで2件とも作ると、納品前の請求まで進んでしまいます。請求予定ごとに作成条件を持たせれば、着手分だけを先に作り、納品分は条件が揃うまで待てます。

契約の変更があった場合も、契約総額、既に請求した分、これから請求する分を分けて見直せます。消費税や端数の扱いは、契約条件とfreeeの設定を経理担当者が確認します。

請求予定DBに用意する項目

項目	例・目的
請求予定ID	BILL-1042-01。同じ請求を識別する固定の番号
案件	案件DBへのリレーション
対象事業所・取引先ID	作成先と宛先を名称だけで判定しない
請求回・対象期間	着手時、納品時、月次などを区別
請求日・入金期日	締日だけでなく、実際の日付を確定
明細	品名、単価、数量、税の扱いを確認できる情報
承認状態・承認者・承認日時	誰が今回の内容を確認したか
承認した内容の版	承認後の変更を検知するための記録
freee請求書ID	作成後に返されたIDを保存
連携状態・最終エラー	未処理、処理中、作成済み、要照合など

明細が複数行になるなら、請求予定に関連付けた明細DBや、連携側で管理する明細データを用意します。合計金額だけでは、品目ごとの税の扱いや数量の誤りを確認できません。

同じ取引先へ複数案件をまとめて請求する場合は、請求書の単位となる「請求グループ」を設け、その配下に案件別明細を関連付けます。分割と合算をどちらも、案件IDだけで判定しないのが要点です。

Notion側には何を設定するのか

自作API連携では、DBを用意したうえで、外部プログラムからアクセスできる接続を設定します。Yoomなどを使う場合は、そのサービスのNotion認可画面で対象ページを選ぶ流れになります。

1. 接続と対象ページのアクセスを設定する

社内用のプログラムなら、Notionの内部接続が選択肢になります。接続を作成し、必要な能力を設定して、案件DB・請求予定DBなど対象のページへアクセスを付与します。

今回の例では、請求情報の読み取りと、作成後のID・結果の更新を使います。新しいページを作る処理も加えるなら挿入の能力を含め、実際の操作に必要なものを選びます。

接続を作っただけでは、対象DBを自由に読み書きできるわけではありません。 トークンの能力と、ページへのアクセスの両方を確認します。親ページを共有すると子ページにも範囲が広がるため、請求連携専用の対象を整理してから付与しましょう。

Notion公式：接続の認証とアクセス許可

2. 対象データと処理条件を決める

「経理確認済み」かつ「請求書IDが未登録」の請求予定を、処理対象の候補にします。ただし、ステータスだけで作成権限を保証してはいけません。

編集者が自分で確認済みに変えられるなら、それは承認者の確認とは限りません。誰が承認できるかを決め、連携側でも承認者と承認した内容を検証します。Notionの権限だけで要件を満たせない場合は、別の承認手段を組み合わせます。

3. 使用するDBとプロパティを記録する

プログラムには、対象ページ・データソースとプロパティの対応を設定します。NotionのAPIバージョンによってDBの扱いが異なるため、使用するSDK・自動化サービスの対応も合わせて確認します。

営業担当が列を追加・改名したときに止まらないよう、どの項目を連携に使うか、変更時に誰へ知らせるかも残しておきます。

連携プログラムはどこで動かすのか

通常の自作API連携では、Notionに権限を設定し、連携プログラムは外部の実行環境で動かします。 Notionのページへプログラムのコードを貼るだけで、毎月動き続ける仕組みにはなりません。

実行場所	構成例	運用で持つもの
自動化サービス	YoomなどがNotionとfreeeのAPIを呼ぶ	接続アカウント、実行履歴、利用量、失敗通知
AWS Lambdaなどのクラウド関数	定期起動やWebhookで自作処理を動かす	認証情報の保管、実行ログ、処理状態、監視
自社のサーバーやジョブ基盤	既存の販売管理・社内システムと連携	定期実行、認証、障害対応、更新担当

自作する場合の基本的な処理は、次の流れです。

1. Notionから対象の請求予定と明細を取得する。
2. 承認者、承認後の変更、宛先、日付、明細の不足を確認する。
3. 請求予定IDを使い、作成済み・処理中でないかを連携側の記録で確認する。
4. freee請求書APIで請求書を作る。
5. 返された請求書IDと内容を記録し、Notionへ結果を戻す。
6. 経理担当者がfreee上で請求書を確認し、送付へ進める。

freee側はOAuth 2.0で認証します。自作アプリでは、対象事業所への認可、必要な権限、トークンの保管と更新処理を設定します。認証情報はNotionの通常のメモ欄や公開されるコードに保存せず、実行環境の保護された保管先で管理します。

freee公式：APIクイックスタートとテスト事業所

Webhookを使う場合も、受け取った通知をそのまま請求指示にせず、処理時点のデータと承認内容を取り直します。定期処理なら、締めの確認後に対象一覧を取得する方法から始められます。

Notion Webhook連携の仕組みと運用

金額・税区分は確定データ、AIは摘要案に使う

Notion AIを使いたい場合も、請求金額や税の扱いをAIに推測させる必要はありません。契約で決めた単価・数量・請求条件を使い、集計は決めた計算式やプログラムで行います。

処理	担当するもの	確認する内容
請求対象の判定	契約条件・検収情報と担当者	今回、請求してよいか
単価・数量・金額	確定した明細と計算処理	契約・対象期間と一致するか
税の扱い・端数処理	経理が決めたルールとfreeeの設定	税込・税抜、明細、端数の計算が揃うか
摘要・件名の文章案	Notion AIなど	提供した作業と表現が一致するか
最終確認と顧客への送付	経理担当者など	宛先、金額、明細、振込先、送付先が正しいか

freee請求書APIでは、請求日、明細、税込・税抜の区分、端数処理などを指定します。Notionの「税区分」という列を、そのまま一つのAPI項目へ渡せば済むとは限りません。帳票上の消費税の設定と、会計連携に使う明細の設定を分けて項目を対応させます。

AIの出番は、確定した作業明細から「○月分の保守対応」といった摘要の候補を作るところです。摘要案を直しても金額が変わらないよう、文章と金額の項目を分離しておきます。

なお、請求連携そのものにAIは必須ではありません。Notion APIでデータを読み、決まった条件でfreeeへ登録するだけでも、転記の手間は減らせます。

Notion AIとNotion APIの違い、外部AIを使う構成

重複・変更・通信エラーにどう対応するか

日々の運用で確認したいのは、正常に1件作れることに加え、同じ処理をもう一度動かした場合や、途中で止まった場合の動きです。

請求書IDが空でも、すぐ作り直さない

freeeで作成に成功した直後、Notionへの結果更新に失敗することがあります。このときNotionの請求書IDは空でも、freeeには既に請求書が存在します。

通信がタイムアウトした場合も、作成が失敗したとは限りません。自動的に再作成せず「要照合」にし、連携側の実行記録とfreeeの内容を確認してから再開します。

状況	設計しておく対応
同じ通知が届いた・定期処理が重なった	請求予定IDで処理を識別し、同時に作成を進めない
作成は成功したがNotion更新が失敗した	連携側に残したfreee請求書IDを使い、結果更新だけを再実行
作成リクエストがタイムアウトした	成否不明として止め、freee側と照合して判断
認可が切れた・権限が変わった	エラーを通知し、認証・権限の復旧後に未処理分を確認
承認後に金額や宛先が変わった	承認をやり直すまで作成対象から外す

Notionの列だけで同時実行を厳密に制御するのは避け、要件に応じて連携側に一意な実行記録と排他制御を持たせます。自動化サービスを使う場合も、同時実行・再試行・結果保存がどう動くかを確認しましょう。

訂正・再請求は、送付状態を確認してから進める

送付前の内容変更と、顧客へ送付した後の訂正は扱いを分けます。Notionを直したら、送付済みの請求書まで無条件に上書きする構成にはしません。

経理がfreee上の作成・送付・取引反映の状態を確認し、更新、取消、作り直しなどの対応を決めます。元の請求予定ID、元の請求書ID、訂正理由と対応先を残して、どれが有効な請求かを追えるようにします。

まず試す範囲と確認チェックリスト

最初は、取引先を一つ、請求のパターンを一つに絞り、送付前の請求書作成までを試します。freeeの開発用テスト環境など、実際の取引先への送付や会計処理と切り分けられる環境で確認してから、本番の業務へ広げましょう。

次の表は、営業・経理・開発担当者でそのまま確認に使える項目です。

確認すること	合格の目安
通常の1件を作る	事業所、宛先、明細、日付、合計が確認した内容と一致する
分割請求を作る	今回分だけが作成され、次回分は未作成で残る
同じ処理を再度動かす	同じ請求予定から重複した請求書が増えない
明細や取引先IDが不足している	作成せず、何を直すか担当者に分かる
承認後に金額を変える	再承認まで作成が進まない
作成後のNotion更新を失敗させる	請求書を再作成せず、結果だけ復旧できる
作成の成否が分からない	自動再作成を止め、照合が必要だと分かる
経理が確認して送付する	作成済みと送付済みを区別して記録できる

導入効果は、請求書を作る時間だけで測らず、確認・差戻し・エラー対応を含めた月次の作業時間で比べます。件数が少ないなら既存機能と手作業を続けた方がよい場合もあります。

よくある質問

Notion AIの有料契約は必要ですか？

この記事の基本構成は、Notion APIで確認済みデータを読み、freeeへ登録するものです。AIで文章を作る機能を含めなければ、Notion AIを処理の前提にはしません。Notionの自動化機能や外部サービスを使う場合は、その機能ごとの契約条件を確認してください。

freee会計のAPIで請求書を作ればよいですか？

請求書作成は、現在のfreee請求書APIを確認します。古いfreee会計APIの請求書作成例を、そのまま新規の実装へ使わないようにしましょう。取引先などの会計マスタを扱うAPIは、請求書作成のAPIと分けて確認します。

freee公式：会計APIリファレンスと請求書APIへの移行案内

作成から送付まで、すべて自動にできますか？

必要な機能と契約条件を確認したうえで検討します。ただし、この記事で提案している最初の範囲は、確認済みデータから送付前の請求書を作るところまでです。送付方法の設定、実際の送付、会計取引への反映、入金確認は別々に確認します。

作った請求書をNotionから自由に変更してよいですか？

送付・取引反映の状態を確認せずに上書きする運用は避けます。作成後はfreee側の内容を正として扱い、変更したいときは元の請求書IDを参照し、経理が対応を決める流れにします。

Notionとfreeeの連携を検討している方へ

「案件はNotionにあるのに、毎月の請求はExcelと手入力が残っている」という場合は、まず次の4点を書き出してみてください。

• 月に何件の請求書を作り、転記・確認にどれくらい時間がかかっているか。
• 一括・分割・月次・複数案件の合算のうち、どの請求があるか。
• 誰が、何をもって請求内容を確認しているか。
• 作成後の変更やエラーが起きたら、誰が確認するか。

ビットライトでは、こうした業務の整理から、NotionのDB設計、外部システムとの連携方法、運用時の確認手順まで相談できます。現在の請求一覧や項目名が分かる状態であれば、既存の自動化サービスで足りるか、個別のプログラムが必要かを検討しやすくなります。

Notion AIや外部データ連携の全体像を先に知りたい方は、Notion AI / Notion Workers活用ガイドもご覧ください。請求書専用の手順書ではなく、DB設計やAIと人の役割分担を扱う資料です。

Notion AI / Notion Workers活用ガイドを請求する

仕様の確認日：2026年10月21日。APIの項目・利用条件は変更されるため、実装時にはリンク先の公式資料と利用環境を照合してください。