freee for kintoneの設計方法｜営業・請求・会計をつなぐ業務構成

freee for kintoneは、kintoneとfreee会計をつなぐための選択肢です。

kintoneで管理している案件から見積書を作る。

kintoneの請求対象からfreeeの請求書を作る。

kintoneのレコードからfreee会計の取引を作る。

freeeの決済ステータスをkintoneから確認する。

freeeの勘定科目、税区分、取引先、部門などのマスタをkintoneへ取り込む。

こうしたことができるため、営業、管理、経理の間にある手入力や確認の往復を減らせます。

ただし、freee for kintoneを入れれば、営業から会計まで自然につながるわけではありません。

実務で詰まりやすいのは、連携機能そのものではなく、責任範囲です。

どの取引先情報を正本にするのか。

kintoneの請求金額とfreeeの請求書金額が違ったら、どちらを直すのか。

請求書をfreeeへ作成した後、kintone側で金額を変更してよいのか。

freee側で入金や決済状態が変わったとき、kintone側ではどこまで確認するのか。

勘定科目、税区分、部門、品目を、営業担当がkintone上で選んでよいのか。

月次締め後に、kintoneの請求対象レコードを再送してよいのか。

ここを決めないまま連携すると、次のような状態になります。

• kintoneの顧客名とfreeeの取引先名がずれ、同じ会社が別名で残る
• 請求書は作れるが、どの案件・受注から作った請求なのか追えない
• 営業担当が税区分や勘定科目を自由に選び、経理確認で差し戻しが増える
• freeeで修正した請求書金額が、kintoneへ戻らない前提を知らずに運用する
• 連携済みの請求対象をkintone側で再編集し、freee側と数字が合わなくなる
• 入金確認をkintoneで見たいのに、請求書、取引、決済ステータスの意味を混同する
• 月次締め後の取消、再作成、差額調整のルールがない
• freee for kintoneで足りる範囲と、個別API連携が必要な範囲が混ざる

freee for kintoneで最初に決めるべきなのは、連携ボタンの設定ではなく、「kintoneを営業・請求前の業務DB、freeeを会計の正本としてどう分けるか」です。

この記事では、freee for kintoneを、機能紹介ではなく、営業案件、請求、取引、入金確認、マスタ連携、会計側の正本、月次締め後の修正ルールまで含めた業務設計として整理します。

kintone請求書管理の設計方法はこちら
kintone見積書作成の設計方法はこちら
kintone売上管理の設計方法はこちら

freeeとkintoneの役割を分ける

freee for kintoneを設計するとき、最初に役割を分けます。

kintoneは、営業や現場が入力し、確認し、経理へ渡す前の業務データを扱いやすいです。

freee会計は、会計上の取引、請求書、決済、仕訳、マスタを扱う場所です。

領域	kintoneに置きやすい	freeeを正本にしやすい
営業案件	案件名、担当、見込み、受注予定、請求対象	原則置かない
見積	見積前の確認、社内承認、明細候補	正式な見積書、見積書ID、ステータス
請求	請求対象、請求前チェック、送信条件	正式な請求書、請求書ID、送付・決済状態
取引	連携対象、社内確認、連携ログ	会計上の取引、未決済・決済済み
マスタ	freeeマスタの参照、営業用補足	勘定科目、税区分、取引先、部門、品目
入金確認	ステータス参照、未入金一覧	決済情報、入金消込、売掛管理
修正履歴	連携前後の確認、差戻し理由	会計処理上の正式修正

freee公式ヘルプでは、freee for kintoneを、freee会計とkintoneを連携させるWebアプリケーションとして説明し、kintoneレコード情報からfreeeの見積書、請求書、取引を作成できること、freeeで管理している決済ステータスをkintoneから確認できることが説明されています。

freeeヘルプ：freee for kintone の概要

この機能範囲を踏まえると、設計の中心は次です。

設計項目	決めること
連携前	kintoneで誰が何を確認したらfreeeへ送るか
連携時	どのフィールドをfreeeのどの項目へ渡すか
連携後	freee側のID、URL、ステータスをkintoneへどう戻すか
修正時	kintoneとfreeeのどちらで直し、どちらへ合わせるか
締め後	削除・再作成・差額処理をどう承認するか

freee for kintoneは、kintoneを会計ソフトにするためのものではなく、営業・管理側のデータをfreee会計へ渡し、結果を追えるようにするための連携です。

kintoneに置く営業・請求前データ

kintoneに置くべきなのは、freeeへ送る前に営業・管理・経理で確認したいデータです。

たとえば、次のようなアプリ構成です。

アプリ	1レコードの意味	目的
案件	1商談、1受注候補	見積、受注、請求予定の起点
請求対象	1回の請求候補	freee請求書へ送る前の確認
請求明細	1請求の1行	品目、数量、単価、税区分を確認
経費申請	1申請	freee経費精算へ渡す候補
取引登録対象	1会計取引候補	freee取引へ渡す前の確認
連携ログ	1回の連携処理	成功、失敗、外部ID、再実行可否を残す

kintone側で重要なのは、freeeへ送ってよい状態を作ることです。

状態	意味
作成中	営業や担当者が入力している
確認待ち	経理や管理者が内容を確認する
差戻し	金額、取引先、税区分などに不備がある
送信待ち	freeeへ連携してよい
連携済み	freee側に請求書や取引が作成された
修正依頼	freee側またはkintone側で修正が必要
取消	連携済みデータの取消や再作成が必要

freeeへ送る前に、kintoneで見るべき項目は次です。

項目	確認する理由
取引先	freee取引先と照合するため
請求日/発生日	売上計上や請求月に影響するため
支払期限	未入金確認に使うため
品目/部門	会計レポートや管理会計に影響するため
勘定科目	会計処理の分類に使うため
税区分	消費税処理に影響するため
金額	請求、取引、入金確認の基準になるため
証憑/添付	請求根拠や経理確認に使うため

kintoneに置くデータは、freeeへ送るための下書きではありません。

営業や現場が入力し、経理が確認し、freeeへ渡す前に不備を見つけるための業務データです。

kintoneデータ連携の設計方法はこちら

freeeを正本にする会計データ

会計上の正本は、原則としてfreee側に寄せます。

freee for kintoneでkintoneからfreeeへ作成できるからといって、kintone側を会計の正本にすると危険です。

特に次のデータは、freee側を正式な管理場所にする前提で考えます。

データ	freee側を正本にする理由
請求書ID	freee側で作成された正式なID
取引ID	会計取引としての識別子
決済ステータス	入金、未決済、消込の状態
勘定科目	会計処理の分類
税区分	消費税処理に関わる
部門/品目/メモタグ	会計レポートや管理単位
振替伝票	会計処理そのもの

freee公式ヘルプでは、freee for kintoneでできないこととして、kintoneからのfreee請求書・見積書・取引などの更新操作や、freeeで編集した請求書・見積書・取引金額のkintoneへの反映が非対応であることが説明されています。

freeeヘルプ：freee for kintone の概要

これは設計上かなり重要です。

一度freee側へ作成した請求書や取引を、kintoneから自由に上書きできる前提で作ってはいけません。

連携後の修正は、次のように扱います。

状況	推奨する扱い
連携前に金額を直す	kintone側で修正し、再確認する
freeeへ作成後に誤りが見つかる	freee側で削除・修正・再作成方針を決める
kintone側にも同じ内容を残す	freee側の修正内容に合わせてkintone側を更新する
月次締め後に誤りが見つかる	差額処理、取消、再発行を経理ルールに従って扱う
freee側のIDが変わる	kintoneの連携ログと外部IDを更新する

freeeへ作成した後の請求書・取引を、kintoneから上書きできる前提にしないことが重要です。連携後の修正は、freee側の会計ルールに合わせます。

取引先・勘定科目・部門マスタの設計

freee for kintoneでは、マスタ連携の設計が重要です。

freee公式ヘルプでは、初期設定で必要なマスタ連携として、勘定科目、税区分、取引先、品目、部門、メモタグ、セグメント、経費科目、口座をkintoneへレコード登録できると説明されています。

freeeヘルプ：初期設定 - 2. マスタ連携を行う

マスタは、freeeを正本にしてkintoneへ参照用に持つのが基本です。

マスタ	kintoneでの使い方	注意点
取引先	請求先、見積先、取引登録先の候補	顧客マスタとの重複を整理する
勘定科目	請求明細や取引の会計分類	営業担当が自由に選ばない
税区分	明細の消費税処理	商品や取引種別とセットで制御する
品目	売上分類、レポート軸	商品マスタと同じ意味にしない
部門	部門別会計、管理単位	kintoneの部署・担当者と混同しない
メモタグ	任意の分析軸	増やしすぎると選択ミスが増える
セグメント	事業別・プロジェクト別管理	管理会計の設計と合わせる
口座	決済情報、入金確認	権限と表示範囲に注意する

取引先マスタは特に注意が必要です。

kintoneに顧客マスタがすでにある会社では、freeeの取引先とkintoneの顧客が別々に存在します。

このとき、次を決めます。

項目	決めること
顧客名	営業用の表記と請求書上の宛名を分けるか
取引先コード	freee側の取引先コードを使うか
freee取引先ID	kintone側に保存するか
請求先	顧客と請求先が違う場合をどう扱うか
担当者	営業担当、請求担当、経理担当を分けるか
更新責任	住所変更や社名変更をどちらで直すか

freee for kintoneのFAQでは、freee会計に連携する際のIDはAPIで自動採番されるため任意の文字列で連携できず、取引先コードを使う場合は任意文字列を指定できる一方で取引先IDは自動採番されると説明されています。

freeeヘルプ：freee for kintone よくある質問

つまり、kintone側の社内顧客番号を、そのままfreee側のすべてのIDにできるわけではありません。

社内顧客番号、freee取引先ID、取引先コードを分けて持つ設計が必要です。

請求書・取引・入金確認の流れ

freee for kintoneでは、見積書、請求書、取引、経費精算、ファイルボックス、振替伝票、試算表など複数の機能連携があります。

この記事では、特に相談が多い請求書、取引、入金確認に絞ります。

freee公式ヘルプでは、機能連携の初期設定として、見積書、請求書、経費精算、ファイルボックス、取引、取引の＋更新、振替伝票、試算表の連携が説明されています。

freeeヘルプ：初期設定 - 3. 機能連携を行う

請求書連携の基本フローは次のようになります。

段階	kintone	freee
請求候補作成	案件、受注、作業実績から請求対象を作る	まだ作らない
請求前確認	金額、取引先、税区分、支払期限を確認する	マスタを参照する
送信待ち	経理確認後に連携対象にする	作成待ち
請求書作成	freee for kintoneから連携する	請求書を作成する
結果保存	freee請求書ID、URL、ステータスを保存する	正式データを持つ
送付/決済	kintone側では状態を参照する	送付、決済、入金を管理する
入金確認	未入金一覧や営業確認に使う	決済ステータスを正本にする

取引連携では、さらに発生日、決済情報、勘定科目、税区分、部門などを見ます。

freee for kintoneの機能連携ヘルプでは、取引の連携で「決済情報の同時登録」をする/しないを選べ、同時登録しない場合はfreeeへ未決済の取引として登録し、取引登録後にfreee上で消込作業を行うと説明されています。

freeeヘルプ：初期設定 - 3. 機能連携を行う

ここは、経理運用に直結します。

設計	向いているケース	注意点
請求書を作成する	顧客へ正式な請求書を送る	請求書番号、送付、修正ルールを決める
取引を未決済で作成する	売掛や未払をfreeeで管理する	入金消込はfreee側で行う
決済情報も同時登録する	すでに入金済み、決済済みの情報を登録する	口座、決済日、金額の確認が必要
kintoneで入金状態を見る	営業や管理が未入金を確認する	freee側の決済状態を参照する前提にする

請求書、取引、決済ステータスは似ていますが、意味が違います。kintone側では「請求対象」「freee請求書」「freee取引」「入金確認」を分けて持ちます。

kintone請求書管理の設計方法はこちら

できないことと個別連携が必要なケース

freee for kintoneは便利ですが、すべての会計連携を吸収するものではありません。

公式ヘルプで説明されている非対応範囲は、設計段階で確認します。

特に重要なのは次です。

非対応・注意点	設計への影響
kintoneからfreee請求書・見積書・取引などを上書き更新できない	連携後修正はfreee側のルールで扱う
freeeで編集した請求書・見積書・取引金額がkintoneへ反映されない	kintone側の数字とfreee側の数字を照合する設計が必要
IDを任意文字列で指定できない	freee側ID、取引先コード、社内IDを分けて持つ
ゲストスペースで利用できない	社外共有アプリとは分ける
freeeとkintoneのアカウントを複数紐付けできない範囲がある	利用者と権限の設計が必要

freee公式ヘルプでは、これらの制約が「freee for kintoneでできないこと」として整理されています。

freeeヘルプ：freee for kintone の概要

次のような要件では、freee for kintoneだけで完結させず、個別API連携や別の連携基盤を検討します。

要件	検討すること
kintoneから連携済み請求書を自動更新したい	freee側の仕様と更新可否を確認し、個別APIで可能か調査する
freee側で修正した金額をkintoneへ戻したい	freee API、差分取得、照合ログを設計する
複数事業所・複数部署で権限を細かく分けたい	freee事業所、kintoneアプリ、ユーザー権限を分ける
大量請求を自動で流したい	件数、失敗ログ、再実行、月次締めを設計する
入金消込までkintone画面で細かく見たい	freee側の決済情報をどう取得・表示するか設計する
社外の取引先に入力させたい	kintoneゲストスペース制約や外部フォームを検討する

kintone API連携の設計方法はこちら
kintone連携サービスの選び方はこちら

月次締めと修正ルール

freee for kintoneで最も重要なのは、月次締め後の修正ルールです。

営業側から見ると、請求対象の金額修正は日常的に起きます。

しかし、経理側では、請求書発行、取引登録、入金消込、月次締めが進むほど、修正の扱いが重くなります。

状態ごとに、修正方法を分けます。

状態	kintoneでの修正	freeeでの修正	ルール
作成中	可能	まだ不要	営業が入力し、経理確認へ回す
確認待ち	条件付きで可能	まだ不要	経理が差戻し、再確認する
送信待ち	原則止める	まだ不要	送信前の最終確認にする
連携済み	勝手に変更しない	freee側を確認	修正依頼フローにする
請求書送付済み	直接変更しない	訂正、再発行、取消を判断	顧客通知が必要
入金済み	原則変更しない	差額、返金、追加請求を判断	経理承認が必要
月次締め後	直接変更しない	締め後修正のルールに従う	管理者承認を必須にする

kintone側には、少なくとも次の項目を持たせます。

項目	理由
freee連携日時	いつfreeeへ送ったか分かる
freee請求書ID/取引ID	freee側の正式データと照合する
freee URL	経理がすぐ確認できる
連携ステータス	未連携、連携済み、失敗、取消依頼を分ける
修正理由	連携後変更の理由を残す
再作成フラグ	削除・再作成が必要な対象を管理する
締め対象月	月次締め後に編集制御する

連携ログも必要です。

ログ項目	内容
実行日時	いつ連携したか
実行者	誰が実行したか
対象レコード	kintone側の請求対象や取引候補
連携種別	見積書、請求書、取引、経費精算など
freee側ID	作成されたID
結果	成功、失敗、保留
エラー	項目不足、マスタ不一致、権限不足など
再実行可否	そのまま再実行してよいか

freee for kintoneの導入では、作成できるかよりも、連携後に直したいときのルールを先に決める方が重要です。

よくある失敗

freee for kintoneの導入でよくある失敗を整理します。

失敗	原因	対策
顧客と取引先が重複する	kintone顧客マスタとfreee取引先を分けていない	freee取引先ID、取引先コード、社内顧客番号を分ける
税区分や勘定科目がばらつく	営業担当が自由に選んでいる	freeeマスタを参照し、候補を絞る
請求書作成後にkintoneで金額を直す	連携後の正本を決めていない	連携済み以降は修正依頼フローにする
freee側の修正がkintoneへ戻らない	自動反映される前提で設計した	照合項目と手動反映ルールを持つ
入金確認が曖昧	請求書ステータス、取引、決済を混同している	見る状態と用途を分ける
マスタ連携だけで止まる	請求・取引の機能連携設計がない	マスタ、請求、取引、ログを一体で設計する
月次締め後に再送する	締め対象月や編集制御がない	締め後修正の承認ルールを作る
エラー原因が追えない	連携ログを残していない	成功、失敗、freee側ID、再実行可否を保存する

特に危ないのは、freee for kintoneを「営業がfreeeへ直接作成できるボタン」としてだけ導入することです。

ボタンを押す前に、取引先、税区分、勘定科目、部門、請求日、支払期限、金額、連携対象月が正しいかを確認する必要があります。

ボタンを押した後は、freee側に正式なIDやステータスができます。

この前後で、編集できる人、編集できる項目、差戻し方法を変えます。

実装前チェックリスト

freee for kintoneを導入する前に、次を確認します。

チェック	確認内容
利用条件	kintone、freee会計、freee for kintoneの対象プランを確認したか
役割分担	kintoneとfreeeのどちらを正本にする項目か
対象業務	見積、請求、取引、経費精算、ファイル、試算表のどれを使うか
取引先	freee取引先ID、取引先コード、社内顧客番号を分けたか
マスタ	勘定科目、税区分、部門、品目をどこまでkintoneで見せるか
請求対象	どの状態になったらfreeeへ送るか
取引連携	未決済で作るか、決済情報も同時登録するか
入金確認	freee側のどの状態をkintoneで見るか
連携後修正	freee作成後にkintone側を直接変更させない設計か
月次締め	締め後の取消、再作成、差額処理のルールがあるか
ログ	成功、失敗、freee側ID、再実行可否を残すか
権限	営業、管理、経理、管理者でできる操作を分けたか
個別開発	標準機能で足りない要件を切り分けたか

利用条件や対象プランは変更される可能性があるため、導入時点で必ず公式ヘルプを確認します。

freee公式ヘルプでは、freee for kintoneの必要なものとして、kintoneスタンダードコース、freee会計の対象プラン、freee for kintoneが案内されています。

freeeヘルプ：freee for kintone の概要

Bitlightに相談できること

Bitlightでは、freee for kintoneを、単なる連携設定ではなく営業・請求・会計の業務フローとして設計できます。

たとえば、次のような相談に対応できます。

• kintone案件、見積、請求対象、請求明細、連携ログのアプリ設計
• freee取引先、勘定科目、税区分、部門、品目、メモタグのマスタ連携設計
• freee請求書、取引、決済ステータスを前提にした責任分界の整理
• 連携後の修正、取消、再作成、月次締め後対応のルール作成
• freee for kintoneで足りる範囲と、freee API・個別連携が必要な範囲の切り分け
• 営業、管理、経理の権限、承認、差戻し、送信条件の設計
• 既存kintoneアプリからfreee連携へ移すためのデータ整理

freee for kintoneは、kintoneとfreee会計をつなぐ有力な選択肢です。

ただし、導入前に、kintoneで確認するデータ、freeeを正本にするデータ、連携後に直せないデータ、月次締め後の扱いを分ける必要があります。

freee for kintoneは、営業と経理の間にある請求前確認をkintoneで整え、正式な請求・取引・決済管理をfreeeへ渡す設計にすると使いやすくなります。