ある案件の、はじまりから入金まで

前回は、ホームで入金予定を確認する操作を扱いました。今回は、1件の案件が最初から最後まで進む流れを追います。

この記事で追う案件

公開用のデモデータです。 案件名、クライアント名、金額、日付はすべて架空のものです。

• 内容: ロゴデザインとブランドガイドラインの制作
• 見積: 70万円（税抜）
• 途中で修正作業が10万円分追加
• 支払条件: 末締め翌月末払い
• 源泉徴収: あり

見積と請求の金額が違います。実務では珍しくない状況なので、その扱いも含めて追います。

一巡で自動になる3つのこと

先に結論を書きます。この流れで手作業がなくなるのは次の3つです。

1. 明細と税率が次の書類へ引き継がれる — 見積から納品書、納品書から請求書へ変換するとき、書き写しが発生しません。
2. 請求日から入金予定日が計算される — クライアントに登録した支払条件を使います。
3. 案件のステータスが書類の状態から更新される — 見込み、着手済み、入金済みといった状態を手で変える必要がありません。

手作業だと、この3つがそれぞれ転記・計算・状態変更として残ります。

① 見積を出す

案件を作り、見積書を作成します。明細は3行、合計70万円（税込77万円）です。

案件の下に、見積書・納品書・請求書がまとまって並びます。書類を種類別のフォルダで探す必要がありません。

見積が承認されると、状態が「承認済み」になります。ただし、この時点では入金予定に入りません。このシリーズの最初に扱った4つの関門でいうと、まだ①受注確定を通過しただけで、③請求に届いていないためです。

② 納品する

成果物を渡し、納品書を作ります。見積書から変換すると、明細と税率がそのまま引き継がれます。

納品確認済みになっても、入金予定には入りません（②納品を通過した状態）。ここで止まったまま忘れられる案件が、ホームの要対応に「未請求」として出ます。

③ 請求する

納品書から請求書へ変換します。ここで、追加で発生した修正作業10万円を明細に足します。

見積書と納品書が77万円（税込）、請求書が88万円（税込）です。差の11万円は、追加した修正作業10万円と、その消費税です。

見積と請求の金額が違うこと自体は問題ありません。 途中で作業が増えたなら、増えた分を明細に足して請求します。大事なのは、なぜ違うのかが書類から追えることです。見積書と請求書の両方が案件の下に残っていれば、後から明細を比べられます。

請求書を作ると、クライアントに登録した支払条件（末締め翌月末払い）から入金予定日が入ります。この時点で③請求を通過し、ホームの入金予定に金額が加わります。

④ 入金を記録する

入金を確認したら記録します。案件のステータスが「入金済み」になり、入金予定の集計からは外れます（④支払を通過）。

これで一巡です。見積から入金まで、案件の下に4つの記録が残りました。次に同じクライアントから依頼が来たとき、前回の金額と条件がそのまま参照できます。

手作業だと、何が起きていたか

同じ流れを紙と表計算でやると、次のようになります。

• 転記3回 — 見積の明細を納品書へ、納品書の明細を請求書へ、請求書の金額を予定表へ。
• 計算1回 — 請求日と支払条件から入金予定日を出す。
• 状態変更2回 — 予定表の状態を「請求済み」に、入金後に「入金済み」に。

1件ならたいした手間ではありません。月に5件、10件と増えると、この作業が案件数だけ発生します。前の記事で「表計算の更新が3か月前で止まっていた」と書いたのは、この積み重ねが原因です。

この流れが向かない場合

見積を出さない取引では、変換の利点が小さくなります。継続契約で毎月同じ金額を請求する場合や、単発の小口案件が中心の場合は、請求書だけを作る運用でも足ります。

相手指定のフォーマットで書類を作る必要がある場合、変換した書類をそのまま使えません。相手のテンプレートに転記する作業が残ります。

金額が見積から動かない取引なら、転記の手間もそもそも少なくなります。追加や変更が頻繁に起きる仕事ほど、書類が案件の下に集まっている利点が出ます。