kintone請求書管理の設計方法｜請求データ・帳票・入金・会計連携の境界

kintoneで請求書を作成したい相談では、最初に帳票の話になりやすいです。

会社ロゴ。

宛名。

請求番号。

品目。

数量。

単価。

消費税。

合計金額。

振込先。

PDF出力。

たしかに、顧客へ送る請求書として見た目が整っていることは重要です。

ただし、実務で崩れるのは「請求書をPDFにできないこと」だけではありません。

本当に困るのは、次のような状態です。

• 請求番号の採番ルールがなく、同じ番号や欠番が発生する
• 受注データと請求データがつながらず、請求漏れが分からない
• 請求明細の税区分や品目名が自由入力でばらつく
• 締め処理前と締め処理後のデータを同じように編集できてしまう
• PDFは出せるが、誰にいつ送ったかが残らない
• 送付済み、未送付、再送、差し替えの状態が分からない
• 入金期日、入金日、入金額、差額が追えない
• freeeなどの会計ソフトと、どちらが正式な請求データなのか決まっていない
• インボイス対応や電子取引データ保存を、kintoneだけで満たせると思い込んでいる

請求書作成は、帳票を作る仕事ではありません。

請求すべき取引を確定し、顧客へ送り、入金を確認し、会計へつなげる仕事です。

kintone請求書管理で最初に決めるべきなのは、帳票レイアウトではなく、「請求データ・明細・送付・入金・会計連携のどれをkintoneの正本にするか」です。

この記事では、kintoneで請求書管理を崩れにくい業務システムとして設計する方法を整理します。

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

先に結論：請求書作成と請求管理は別物

kintoneで請求書を作るだけなら、請求書アプリ1つでも始められます。

顧客名、請求日、品目、数量、単価、金額を入力し、帳票出力プラグインでPDFにする。

この形でも、紙やExcelよりは扱いやすくなります。

ただし、営業、管理、経理が同じ請求データを使うなら、最初から次の情報を分けます。

分けるもの	1レコードの意味	役割
顧客・請求先	1社、1請求先、1担当部署	宛名、住所、支払条件、送付先を持つ
受注・契約	1つの注文、契約、申込	請求対象になる根拠を持つ
請求ヘッダー	1回の請求単位	請求番号、請求日、締め、合計金額を持つ
請求明細	1請求の1行	品目、数量、単価、税区分、金額を持つ
締め処理	1回の確定処理	請求対象を固定し、編集制限へ進める
帳票出力	1回のPDF作成	出力日、版、控え、ファイルを残す
送付管理	1回の送付	宛先、送付方法、送付日、再送を管理する
入金予定	1回の入金予定	入金期日、予定額、回収担当を持つ
入金確認	1回の入金・消込	入金額、差額、手数料、消込状態を持つ
会計連携	1回の外部連携	freeeや会計ソフトへの登録結果を追う

このうち、すべてをkintoneの正本にする必要はありません。

むしろ、会社によっては請求書そのものはfreeeなどの会計ソフトを正本にした方がよいです。

kintoneは、受注から請求対象を作る、営業と経理で請求前チェックをする、未送付や未入金を見えるようにする、という領域に向いています。

会計ソフトは、正式な請求書発行、売掛金、入金消込、仕訳、税務確認に向いています。

領域	kintoneで持ちやすい	会計ソフトを正本にしやすい
請求前チェック	請求対象、金額、宛名、送付先	必要に応じて参照
請求番号	仮番号、社内管理番号	正式な請求書番号
請求書PDF	出力履歴、控えリンク	正式帳票、送付履歴
入金予定	入金期日、確認担当、未入金一覧	売掛残高、消込
税区分	候補値、明細の確認	会計処理上の正式区分
仕訳	連携ログ、エラー確認	正式な会計データ

請求管理で大事なのは、データを一か所に集めることではありません。

数字の意味と責任者を分けることです。

請求予定額、請求書発行額、入金予定額、入金済み額、未入金額は、それぞれ違う数字です。

ここを分けずに「請求金額」とだけ呼ぶと、営業会議と経理確認で話がずれます。

請求・明細・顧客・受注を分ける

請求書管理で最初に設計するのは、アプリの数です。

単純な運用なら、請求書アプリの中にテーブルで明細を持たせる構成でも始められます。

ただし、請求明細ごとに商品、税区分、部門、売上計上月、原価、会計連携を扱うなら、明細を別アプリにした方が管理しやすくなります。

アプリ	1レコードの意味	主なフィールド
顧客・請求先	1請求先	会社名、部署、担当者、住所、メール、支払条件
受注・契約	1注文、1契約	契約番号、開始日、終了日、請求条件、金額
請求ヘッダー	1請求書、1請求単位	請求番号、請求日、支払期限、合計、状態
請求明細	1請求の1行	品目、数量、単価、税区分、明細金額
帳票出力履歴	1回の出力	出力日時、帳票版、ファイル、実行者
送付履歴	1回の送付	送付先、送付方法、送付日、再送理由
入金予定・確認	1回の入金予定	入金期日、入金日、入金額、差額、消込状態
連携ログ	1回の外部連携	連携先、結果、エラー、再実行可否

請求ヘッダーは、請求全体の条件を持ちます。

請求明細は、請求の内訳を持ちます。

顧客・請求先は、宛名や送付先を統一する辞書です。

受注・契約は、請求してよい根拠です。

帳票出力や送付履歴は、顧客へ渡した事実を残すためのものです。

入金確認は、請求した後に回収できたかを見るためのものです。

これを1つの請求書アプリに混ぜると、請求書は出せても、請求漏れ、送付漏れ、入金漏れ、会計連携漏れを見つけにくくなります。

請求ヘッダーに持たせる項目

請求ヘッダーは、請求書1通または1回の請求単位を表します。

1つの顧客に複数の請求書を出すことがあります。

1つの受注から分割請求することもあります。

複数の受注をまとめて月末締めで請求することもあります。

そのため、請求ヘッダーには、請求全体を識別できる項目を持たせます。

フィールド	型	設計意図
請求管理番号	文字列、採番	kintone内のキーにする
正式請求番号	文字列	帳票や会計ソフトの番号と照合する
請求先	ルックアップ	顧客・請求先マスタと紐づける
関連受注	関連レコード、ルックアップ	請求対象の根拠を追う
請求日	日付	請求書に記載する日付
締め日	日付、選択肢	月末締め、20日締めなどを管理する
支払期限	日付	入金予定を作る
支払条件	ドロップダウン	月末締め翌月末払いなどを統一する
税抜合計	数値、計算	明細から集計する
消費税額	数値、計算	税区分ごとに確認する
税込合計	数値、計算	請求額として確認する
請求状態	ステータス	作成中、確認中、確定、送付済み、入金済み
会計連携状態	ドロップダウン	未連携、連携済み、エラー、再実行待ち
備考	文字列複数行	顧客向け備考と社内メモは分ける

正式請求番号をkintoneで採番するか、会計ソフト側で採番するかは、必ず先に決めます。

kintoneで番号を先に確定し、会計ソフトに渡す運用もあります。

会計ソフトで発行された番号をkintoneに戻す運用もあります。

どちらでもよいのですが、両方で勝手に番号を作る設計は避けます。

請求番号は「見た目の番号」ではなく、顧客、帳票控え、入金、会計データを照合するキーです。どのシステムで確定するかを決めてから実装します。

請求明細に持たせる項目

請求明細は、請求書に載る1行です。

明細は、後から税区分、売上分類、部門、商品別集計、会計連携に使われます。

そのため、帳票に表示する文字だけでは足りません。

フィールド	型	設計意図
関連請求	ルックアップ	請求ヘッダーと紐づける
関連受注明細	ルックアップ	何を請求しているかを追う
品目コード	ルックアップ	商品・サービスマスタを参照する
品目名	文字列	請求時点の表示名を残す
摘要	文字列複数行	顧客に見せる明細説明
数量	数値	金額計算に使う
単価	数値	請求時点の単価を残す
税区分	ドロップダウン	会計連携の候補にする
税率	数値、選択肢	10%、8%、対象外などを確認する
明細金額	計算	数量と単価から算出する
売上分類	ドロップダウン	管理会計や集計に使う
部門	ドロップダウン、組織選択	部門別集計に使う
売上計上月	日付、年月	請求日と計上月を分ける

品目名や単価は、商品マスタからコピーするだけでなく、請求時点の値を請求明細に保存します。

商品マスタの現在値だけを参照すると、後で商品名や単価が変わったときに、過去の請求内容が変わって見える可能性があります。

請求書は、出した時点の条件を残す必要があります。

商品マスタは現在の辞書。

請求明細はその時点の記録。

この違いを分けておくと、後から価格改定や品目名変更があっても、過去請求を説明しやすくなります。

締め処理と請求タイミング

請求管理では、締め処理を曖昧にしないことが重要です。

締め処理とは、請求対象を確定し、その後の勝手な変更を防ぐための区切りです。

たとえば、月末締め翌月末払いの顧客では、月末時点で請求対象を確定します。

都度請求の顧客では、納品や検収のタイミングで請求対象を確定します。

前払いの顧客では、契約開始前に請求を作ることがあります。

請求タイミング	例	設計上の注意
都度請求	納品ごと、作業完了ごと	受注・納品との紐づけが重要
月末締め	月内取引をまとめて請求	締め対象の抽出条件が重要
前払い	契約開始前、利用開始前	入金確認後に提供開始する場合がある
分割請求	着手金、中間金、完了金	受注金額と請求済み額の差分管理が必要
定期請求	月額費用、保守費用	自動作成と例外停止の設計が必要

kintoneでは、請求状態をプロセス管理で扱うことが多いです。

ただし、ステータス名だけを作っても運用は安定しません。

各ステータスで何を許可するかを決める必要があります。

状態	誰が見るか	主な操作	編集制限の考え方
作成中	営業、管理	明細を作る、金額を確認する	編集可
確認中	営業責任者、経理	宛名、金額、税区分を確認する	重要項目は制限
差し戻し	作成者	修正する	修正理由を残す
確定	経理、管理	帳票出力へ進める	原則編集不可
送付済み	経理、営業	送付日、送付先を確認する	金額変更不可
入金確認中	経理	入金データと照合する	消込項目のみ更新
入金済み	経理、管理	完了確認	原則編集不可

締め処理で大切なのは、確定後に金額や請求先を簡単に変えられないようにすることです。

間違いがあった場合は、静かに上書きするのではなく、差し替え、取消、再発行として履歴を残します。

請求書のミスは、社内だけでなく顧客にも影響します。

「修正できること」よりも「なぜ修正したかが残ること」を優先します。

帳票出力とメール送付

kintone標準機能だけで、実務で使う請求書PDFを柔軟に整形するのは限界があります。

会社ロゴ、印影、明細行の折り返し、税率別集計、振込先、控えの保管、PDFファイル名などを考えると、帳票出力プラグインや外部サービスを使うケースが多くなります。

ここで重要なのは、帳票出力プラグインを「請求管理の本体」にしないことです。

帳票出力は、確定した請求データを顧客に渡す形へ変換する役割です。

請求データの正本は、kintoneまたは会計ソフト側に置きます。

項目	kintone側で管理	帳票出力側で管理
請求番号	キー、連携番号	表示位置
請求先	宛名、担当者、住所	帳票上の整形
明細	品目、数量、単価、税区分	行の表示、改ページ
合計金額	計算結果、確認状態	表示形式
備考	顧客向け文言	印字位置
PDF控え	ファイルリンク、出力履歴	生成ファイル

帳票を出力したら、出力履歴を残します。

最低限、次の項目が必要です。

出力履歴の項目	理由
出力日時	いつ請求書を作ったかを残す
出力者	誰が作成したかを追う
帳票版	差し替え時にどの版か分かる
PDFファイル	控えを確認できる
出力時の請求状態	未確定の出力を検知する
再出力理由	修正や再送の理由を残す

メール送付も同じです。

送付先メールアドレスを顧客マスタから持ってくるだけでは足りません。

送付した事実を残します。

送付管理の項目	理由
送付方法	メール、郵送、クラウド請求書などを分ける
送付先	To、Cc、郵送先を残す
送付日	未送付一覧を作る
送付者	誰が送ったかを追う
送付結果	成功、失敗、再送待ちを管理する
再送理由	宛先誤り、金額修正、顧客依頼などを残す

kintoneのアプリアクションは、レコード内容を別アプリへ転記する用途で使えます。

公式ヘルプでも、コピー先アプリとフィールドの関連付け、利用者、利用条件を設定できることが説明されています。

kintoneヘルプ：アプリアクションを設定する

受注から請求を作る、請求から送付履歴を作る、といった軽い転記には使えます。

ただし、明細の複雑な集約、税区分の変換、会計ソフト連携、送付結果の自動反映まで必要なら、プラグインやAPI連携を前提に設計します。

入金管理と消込

請求書を送ったら、次は入金確認です。

請求管理を作るとき、入金確認を後回しにすると、未回収の把握が弱くなります。

「請求書を発行したら完了」ではありません。

「入金され、差額が説明でき、必要なら会計に反映されたら完了」です。

入金確認では、次の項目を分けます。

項目	意味
入金期日	顧客が支払う予定日
入金予定額	請求額と同じとは限らない
入金日	実際に入金された日
入金額	実際に入った金額
振込名義	顧客名と違う場合がある
振込手数料	差額の理由になる
消込状態	未消込、一部消込、消込済み、差額あり
確認担当	誰が確認するか
督促状態	未対応、確認中、督促済み

入金管理でよくある失敗は、請求ヘッダーに「入金済みチェック」だけを置くことです。

小さな会社なら、それでも回ることがあります。

しかし、請求件数が増えると、次のような例外が出ます。

• 請求額と入金額が一致しない
• 振込手数料が差し引かれている
• 2枚の請求書がまとめて入金される
• 1枚の請求書が分割で入金される
• 顧客名と振込名義が違う
• 入金はあったが、どの請求書か分からない
• 過入金や返金が発生する

これらを扱うなら、入金確認を別アプリにします。

設計	向いているケース	注意点
請求ヘッダーに入金項目を置く	件数が少なく、例外が少ない	一部入金や複数消込に弱い
入金確認アプリを分ける	入金件数が多い、差額がある	請求との紐づけが必要
会計ソフトを正本にする	売掛金、消込、残高を正式管理する	kintoneへ状態を戻す連携が必要

kintone側でやるべきことは、会計ソフトと同じ消込機能を作ることではありません。

営業や管理が見るべき未入金、入金遅延、差額、確認待ちを分かるようにすることです。

未入金一覧では、次の列を出します。

列	見る理由
請求先	誰から入金されていないか
請求番号	顧客への確認に使う
請求額	回収すべき金額
入金期日	遅延日数を計算する
経過日数	優先順位を決める
営業担当	顧客へ確認する人を明確にする
経理担当	入金確認の責任者を明確にする
督促状態	二重連絡を防ぐ

未入金管理は、経理だけの仕事に見えます。

しかし、顧客との関係性を持っているのは営業担当であることも多いです。

そのため、kintoneでは営業と経理のどちらが次に動くかを見えるようにします。

freee・会計ソフト連携の境界

請求管理をkintoneで作るとき、freeeや会計ソフトとの境界は早めに決めます。

freee for kintoneの公式ヘルプでは、kintoneレコードの情報をfreeeと連携し、見積書・請求書・取引を作成したり、freeeで管理する決済ステータスをkintoneから確認したりできると説明されています。

freeeヘルプ：freee for kintone の概要

一方で、公式ヘルプには、freeeで編集した請求書・見積書・取引の金額をkintoneへ反映できないなど、できないことも記載されています。

この制約を踏まえると、連携設計で決めるべきことは明確です。

論点	決めること
正式な請求書	kintoneで作るのか、freeeで作るのか
請求番号	どちらで採番するのか
請求明細	kintoneから送るのか、freeeで編集するのか
金額修正	修正時にどちらを直すのか
入金状態	freeeからkintoneへ戻すのか
エラー時	誰が、どの画面で直すのか
再連携	同じ請求を二重登録しない仕組みを作るか

よくある失敗は、kintoneとfreeeの両方で同じ請求書を編集できるようにすることです。

これは一見便利ですが、どちらが正しい金額なのか分からなくなります。

連携するなら、次のどちらかに寄せます。

方針	向いているケース	注意点
kintoneを請求前チェックの正本にする	営業・管理が請求内容を作る	freee連携後の修正ルールが必要
freeeを正式請求書の正本にする	経理が請求書と売掛を管理する	kintoneは状態参照に寄せる
kintoneは受注・請求予定までにする	会計側の正確性を優先する	未請求管理の戻し方を設計する

Bitlightとしては、最初からkintoneを会計ソフトの代替にする設計はおすすめしません。

kintoneは、営業・管理・経理の間にある確認作業を見えるようにするのが強いです。

freeeなどの会計ソフトは、正式な請求書、売掛金、入金消込、税区分、帳簿に強いです。

両者を無理に一本化するより、責任範囲を分けた方が運用は安定します。

インボイス・電子保存・権限設計

請求書管理では、インボイス制度や電子帳簿保存法の扱いも避けて通れません。

ただし、ここで大事なのは、kintoneに項目を置けば法令対応が完了する、という考え方をしないことです。

国税庁のインボイス制度の案内では、適格請求書は一定事項が記載された請求書などであり、適格請求書発行事業者には交付や写しの保存に関する義務があると説明されています。

国税庁：適格請求書等保存方式（インボイス制度）

また、電子取引に関する保存要件も、運用や保存方法の確認が必要です。

国税庁：電子取引関係

この記事では税務判断そのものは扱いません。

実装前に、顧問税理士、経理責任者、会計ソフトのサポート、国税庁の最新情報を確認してください。

kintone側で設計上確認すべき項目は、次のようなものです。

項目	確認する理由
登録番号	請求書に表示する必要がある場合がある
税率別合計	複数税率がある場合に必要
消費税額	端数処理や税額表示の確認が必要
請求書控え	発行した写しを追えるようにする
出力日時	いつ発行したかを残す
差し替え履歴	再発行時の理由を残す
電子送付データ	メール添付やダウンロードURLの扱いを確認する

権限設計も重要です。

請求書管理では、誰でも金額を直せる状態にしない方がよいです。

権限	対象者	許可する操作
作成	営業、管理担当	請求候補を作る
確認	経理、管理者	金額、税区分、宛名を確認する
確定	経理責任者	請求を確定する
出力	経理、管理者	PDFを作成する
送付	経理、営業担当	顧客へ送る
入金更新	経理	入金日、入金額、消込状態を更新する
取消・再発行	管理者	理由を残して処理する

権限は、ユーザーの信用を疑うためではありません。

請求書の金額や状態を、いつ、誰が、なぜ変えたかを説明できるようにするためです。

よくある失敗パターン

kintone請求書管理では、次の失敗がよく起きます。

失敗1：請求書アプリ1つにすべてを詰め込む

最初は簡単です。

しかし、請求先、明細、送付履歴、入金、会計連携まで同じレコードに入れると、一覧や権限が複雑になります。

請求書1通に対して、送付が複数回ある場合。

入金が複数回ある場合。

会計連携でエラーが出た場合。

この時点で、1レコードに詰める設計は苦しくなります。

失敗2：請求番号を手入力にする

請求番号を手入力にすると、重複、欠番、表記揺れが起きます。

見積番号や受注番号と混ざることもあります。

請求番号は、採番ルール、正式番号の発行元、再発行時の番号扱いを決めます。

失敗3：確定後も金額を編集できる

確定後に金額を直せると、出力済みPDF、送付済みメール、会計連携済みデータとの整合が崩れます。

修正が必要な場合は、修正版、取消、再発行として扱います。

「直せる」ことより「直した事実が残る」ことを優先します。

失敗4：送付履歴を残さない

請求書を送ったかどうかが分からないと、未送付と未入金の区別がつきません。

メール送付済み、郵送済み、再送済み、送付エラーを状態として残します。

失敗5：入金済みチェックだけで済ませる

入金には差額、一部入金、まとめ入金、振込名義違いがあります。

請求件数が増えるほど、チェックボックスだけでは足りなくなります。

失敗6：会計ソフトとの二重管理になる

kintoneと会計ソフトの両方で請求書を編集すると、どちらが正しいか分からなくなります。

連携するなら、正本、編集権限、修正手順、連携ログを決めます。

失敗7：法令対応をシステム項目だけで済ませる

登録番号や税率別合計の項目を作っても、それだけでインボイスや電子保存の運用が完成するわけではありません。

出力、送付、控え、保存、訂正削除、閲覧、検索、社内規程の確認が必要になる場合があります。

税務・会計の判断は、必ず専門家や公式情報で確認します。

1週間で始めるならこの順番

最初から完璧な請求管理を作ろうとすると、設計が重くなります。

まずは、請求漏れと送付漏れを防ぐ最小構成から始めます。

1日目：請求業務の流れを棚卸しする

最初に、現在の業務をそのまま書き出します。

• 何をきっかけに請求書を作るか
• 誰が請求対象を確認するか
• 誰が金額を確認するか
• 請求番号はどこで決まるか
• PDFはどこで作るか
• 請求書は誰が送るか
• 入金は誰が確認するか
• 会計ソフトへ誰が登録するか

ここで、理想のシステムを描きすぎない方がよいです。

まずは今の手順を正確に見ます。

2日目：正本を決める

次に、どのデータをどこで確定するかを決めます。

データ	正本候補
受注情報	kintone
請求前チェック	kintone
正式請求書	kintoneまたは会計ソフト
入金消込	会計ソフト
未入金共有	kintone
仕訳	会計ソフト

この表を曖昧にしたまま作り始めると、後から連携で苦しくなります。

3日目：請求ヘッダーと明細を設計する

請求ヘッダーと請求明細を分けます。

件数が少ない場合は、請求ヘッダー内のテーブルでも構いません。

ただし、明細単位で売上分類、部門、会計連携、税区分を扱う場合は、明細アプリを分けます。

4日目：状態と権限を設計する

作成中、確認中、確定、送付済み、入金確認中、入金済みの状態を決めます。

各状態で誰が何を編集できるかを決めます。

特に、確定後の金額、請求先、税区分は簡単に変えられないようにします。

5日目：帳票出力と送付履歴を作る

帳票出力プラグインや外部サービスを選び、PDFの控えを残す運用を決めます。

送付履歴アプリまたは送付履歴テーブルを作り、送付日、送付先、送付結果を残します。

6日目：入金確認の一覧を作る

入金期日、請求額、入金額、差額、状態を見られる一覧を作ります。

未入金、期限超過、差額ありをすぐ見つけられるようにします。

7日目：会計連携と例外処理を決める

freeeなどの会計ソフトへ連携する場合は、連携ログを残します。

連携成功、エラー、再実行、取消、二重登録防止のルールを決めます。

この時点で、運用に必要な最低限の請求管理が見えてきます。

実装前チェックリスト

kintoneで請求書管理を作る前に、次の項目を確認します。

チェック項目	確認内容
請求対象	受注、納品、契約、作業完了のどれを起点にするか
請求単位	受注単位、月締め、顧客単位、案件単位のどれか
請求番号	kintoneと会計ソフトのどちらで採番するか
請求先	顧客、部署、担当者、送付先をどう管理するか
明細	テーブルで持つか、別アプリで持つか
税区分	候補値、税率、端数処理を誰が確認するか
帳票出力	どのプラグインやサービスでPDFを作るか
控え	PDF控え、送付履歴、再発行履歴をどこに残すか
送付	メール、郵送、クラウド請求書のどれを使うか
入金	kintoneで確認するか、会計ソフトから状態を戻すか
消込	一部入金、まとめ入金、差額をどう扱うか
会計連携	請求書、取引、仕訳のどこまで連携するか
修正	確定後の修正、取消、再発行をどう扱うか
権限	誰が作成、確認、確定、送付、入金更新できるか
法令確認	インボイス、電子保存、社内規程を誰が確認するか

このチェックリストを埋めるだけでも、作るべきアプリはかなり明確になります。

逆に、この表が埋まらないまま帳票から作ると、後から作り直しになりやすいです。

Bitlightに相談するなら、最初に見たいもの

kintone請求書管理の相談では、最初に次の情報があると設計が早くなります。

用意してほしいもの	見る理由
現在の請求書テンプレート	帳票に必要な項目を把握する
請求作成の手順	誰が、いつ、何を確認しているかを見る
受注・契約の管理方法	請求対象の起点を確認する
会計ソフトの利用状況	正式請求書や入金消込の正本を決める
請求件数	手入力で足りるか、連携が必要かを見る
入金確認の方法	未入金や差額の扱いを確認する
よくある例外	分割請求、値引き、再発行、前払いなどを見る

最初から完成形の要件定義書は不要です。

むしろ、実際に使っているExcel、PDF、メール文面、会計ソフト画面の流れが分かる方が、業務に合う設計にできます。

Bitlightでは、請求書PDFのレイアウトだけでなく、受注、請求、入金、会計連携まで含めて設計します。

「kintoneで請求書を出したい」という相談でも、実際には次のような論点を整理します。

• kintoneを請求前チェックの場所にするか
• freeeなどの会計ソフトを正式請求書の場所にするか
• 請求番号をどこで確定するか
• 確定後の修正や再発行をどう扱うか
• 未送付、未入金、連携エラーをどう見つけるか
• 税務・会計上の確認を誰が担うか

ここまで決めると、kintoneは単なる請求書作成ツールではなく、営業と経理の間をつなぐ請求管理の画面になります。

まとめ

kintoneで請求書を作るとき、帳票の見た目から入るのは自然です。

ただし、実務で必要なのは、請求書PDFを作ることだけではありません。

受注から請求対象を作ること。

請求明細の根拠を残すこと。

締め処理で請求を確定すること。

PDF控えと送付履歴を残すこと。

入金予定と入金結果を確認すること。

freeeや会計ソフトと責任範囲を分けること。

インボイスや電子保存の確認を専門家や公式情報と照らすこと。

これらを分けて設計すると、kintoneは請求書作成だけでなく、請求漏れ、送付漏れ、入金漏れ、会計連携漏れを減らす業務システムになります。

kintone請求書管理は、請求書をきれいに出すためだけではなく、営業・管理・経理が同じ請求状態を見ながら、請求から入金までを進めるために設計します。

最初に作るべきなのは、帳票の完成形ではありません。

請求データ、明細、締め、送付、入金、会計連携の境界です。

その境界が決まれば、kintoneで作る部分、プラグインで補う部分、freeeなどの会計ソフトに任せる部分が自然に分かれます。