Notionとfreee会計を連携｜案件ごとの請求・入金・未決済残高を確認するには

Notionとfreee会計を連携すると、営業や案件担当者が、案件ごとの請求・入金確認に必要な情報を参照する構成を作れます。目的は、経理に毎回確認しなくても状況を把握しやすくすることです。

ただし、freeeを会計情報の正本とし、Notionは確認用の表示にするのがこの記事の基本方針です。入金の判定や消込をNotionのメモで上書きせず、違いがあれば経理へ確認する設計例を説明します。

請求・取引・入金・消込を分ける

言葉・状態	確認すること	混同した場合の問題
請求書作成	どの宛先へ何を請求する書類か	作成を入金と取り違える
会計取引の登録	どの売上・債権を記録したか	登録済みなら回収済みと誤解する
入金明細	口座等に入った金額と日付	どの請求の入金か未確定のまま対応する
消込・決済の登録	入金と対象取引を対応させたか	未決済残高と実際の確認状況がずれる
未決済残高	対象取引にどれだけ未決済分があるか	部分入金や手数料の差を見落とす

freeeの入金管理レポートでは、未決済取引の期日や残高などを確認できます。Notionへ表示する内容も、このような会計側の状態の意味を確認して定義します。

freee公式：未決済取引を入金管理・支払管理レポートで管理する

請求書の作成までを自動化したい場合は、入金確認とは処理を分けます。

Notionからfreee請求書を作る連携設計

案件と請求・取引IDを対応させる

会社名と金額だけで対応させると、同じ取引先へ同額の請求が複数ある場合に区別できません。案件、請求予定、請求書、会計取引を、それぞれのIDで結びます。

管理するID	使う目的
対象事業所ID	別事業所の情報を混ぜない
案件ID	Notionの業務案件を識別
請求予定ID	分割・月次の何回目かを識別
freee請求書ID	対象の帳票を参照
会計取引ID	残高・決済情報を確認する対象を識別
顧客・取引先ID	表記揺れに頼らず照合

請求書IDと会計取引IDは同じものとして扱いません。帳票を作った後、会計へ反映していないケースもあるため、対応できない時点では「未連携」「経理確認待ち」などと区別します。

一つの請求書に複数案件をまとめるなら、対応表を別に持ちます。その請求書全体の残高を、各案件へ丸ごと重複表示しないようにしましょう。案件別の配分が未確定なら、その旨と請求書全体の状態を表示します。

部分入金と手数料を例に表示を決める

架空の例として、11万円の請求に対し、最初に6万円の入金を確認したケースを考えます。

確認内容	表示の考え方
一部だけ入金・決済が登録された	全額入金済みにはせず、残額と確認日を表示
口座明細はあるが対応する請求が不明	入金確認中など、未確定の状態を残す
振込手数料と思われる差額がある	AIや営業担当の推測だけで差額を消さない
返金・訂正・取消がある	元の請求との関連と経理の処理結果を確認

この例は表示設計のためのもので、会計処理や税務判断を決める説明ではありません。手数料や差額の処理は、契約条件と経理の確認に従い、freeeで正しく処理された結果を参照します。

Notionに独自計算した「入金額」を作る場合も、その計算が何を集計したものか明記します。銀行口座の入出金合計、請求書の金額、取引の決済登録額を混ぜないことが大切です。

Notionの案件サマリーに持つ項目

案件一覧には、担当者が次の行動を決めるために必要なものだけを表示します。

項目	内容
対象請求	請求回・対象期間と帳票へのリンク
請求額	読み取り元と税込・税抜の区別
決済・未決済の状態	freeeで確認した状態
未決済残高	取得元・対象範囲が明確な値
最終取得日時	情報がいつのものか
同期状態	正常、未確認、エラー、要照合
確認担当・次の行動	経理確認、顧客への確認準備など

更新に失敗したとき、残高をゼロにしたり、空欄を入金済みと解釈したりしてはいけません。前回確認できた値を残す場合は「前回値」と日時を見せ、今回の取得に失敗したことが分かるようにします。

API・定期取得・既存ツールをどう選ぶか

freee会計APIで取得できる取引・決済等の項目を確認し、必要な範囲を取得します。請求書の情報も使うならfreee請求書APIとの役割を分け、利用する操作と権限を整理します。

freee公式：会計APIリファレンス

更新方法	向いている条件	注意点
手動確認してNotionへ記録	件数が少なく日々の変動も少ない	確認日と担当者を残す
定期的にAPI等で読み取る	毎朝・毎週の状況が分かればよい	取得範囲、実行履歴、古い情報の表示
既存自動化サービスを使う	必要な取得・更新操作に対応している	単なる取引追加の通知と残高照合を区別
個別の連携プログラム	合算・分割・配分など独自条件がある	認証更新、API制限、照合と復旧の担当

初期はNotionからfreeeへ会計情報を書き戻さず、確認用の読み取りに限定すると、責任の境界を整理しやすくなります。反映を急ぐ業務では、定期取得の間隔だけでなく、freee側の確定タイミングも確認します。

督促前の確認フローを決める

期日超過を見つけたら、すぐ顧客へ自動送信するより、次の確認を行う構成から始めます。

1. 対象の事業所・取引先・請求書が正しいかを確認する。
2. 最終取得日時と取得エラーの有無を確認する。
3. 部分入金・未消込明細・訂正・返金の有無を経理が照合する。
4. 連絡が必要な場合、担当者が顧客への文面を確認する。
5. 連絡結果と次回確認日をNotionへ残す。

AIを使うなら、確認済みの数値から状況説明や連絡文の案を作る範囲にします。入金の有無、差額の会計処理、督促の確定判断をAIの推測で置き換えません。

本番前に確認すること

テストケース	確認する結果
未入金・全額入金・部分入金	それぞれ区別して表示できる
同額・同じ取引先の別請求	IDで正しい請求へ対応できる
1請求に複数案件がある	残高を案件ごとに重複計上しない
取引との対応がない	ゼロや入金済みとして扱わない
取得エラー	古い値と現在の値を誤認しない
取消や訂正がある	旧帳票と有効な帳票を区別できる

ビットライトでは、案件管理と会計の管理範囲を整理し、担当者が確認すべき情報だけをNotionへ渡す連携を検討できます。請求書の件数、分割・合算の有無、現在の入金確認手順をもとにご相談ください。

Notion AIの業務連携・権限・費用をまとめた資料を請求する

仕様確認：2026年10月21日。金額・項目・フローは説明用の設計例です。実装時は公式APIの取得項目と、経理が運用する状態の意味を確認してください。

Notionの業務連携について相談する