前回のVol.3 ツールを増やすほど遅くなる会社、速くなる会社 では、固定フローを支えるツールの選び方を整理しました。今回はその続きとして、実際に月初業務をどう止めなくするかを具体で見ます。

月が変わるたびに、社内の空気が変わる会社があります。

請求書の発行、届いた請求書の確認、証憑の保存、入金予定の確認、支払予定の共有。月初になるとそれらが一気に押し寄せて、営業も制作も、経営の判断まで少しずつ鈍くなる。気づけば毎月の最初の数日が「本業が進まない時間」になっている。

一方で、月初でもほとんど止まらない会社もあります。違いは人数ではありません。月初に発生する仕事を、どこまで“その場で終わる構造”に変えられているかです。

私たちFluxxでも、以前は月初まわりの確認作業に細かい手数がかかっていました。ですが今は、請求書の発行、受取請求書の保存、振込確認、入金予定の可視化まで、かなりの部分を自動で回しています。今回は、その具体的な流れをもとに、なぜ最初に月初業務を見るべきなのかを書いてみます。

最初に自動化すべきなのが月初業務である理由

結局のところ、月初業務を先に見るべき理由はシンプルです。

毎月必ず発生するから。
改善効果が一度きりで終わらず、毎月積み上がります。

関係者が多いから。
経理だけでなく、営業、制作、代表まで巻き込んで止まりやすい領域です。

ミスコストが高いから。
請求、入金、証憑、支払は、抜け漏れの代償が大きい仕事です。

本業を止めやすいから。
確認待ちや一覧作成に時間を取られると、価値を生む仕事が後ろ倒しになります。

言い換えると、月初業務は「頻度が高く、関係者が多く、ミスコストが高く、本業を止める」という、最初の改善対象として非常に優秀な領域なのです。

月初が重くなる会社は、「まとめて処理する構造」になっている

月初がつらい会社では、たいてい同じことが起きています。

届いた請求書を一度ためる。後でまとめて保存する。別の担当者が内容を確認する。支払予定を一覧にする。発行請求書も別で作る。入金予定はfreeeを見ながら確認する。こうして、月が変わった瞬間にいくつもの作業が“待機列”に並びます。

この構造の問題は、作業量そのものより、待ちと転記が増えることです。どれが処理済みなのか、誰が見たのか、どこに保存したのか、支払期日はいつか。ひとつの書類をもとに、複数の確認が連鎖していきます。

だから月初を軽くしたいなら、担当者を増やすより先に、「月初にまとめてやっていることを、受け取った時点・作った時点で終わる構造に変えられないか」を見るべきです。

Fluxxでは、受取請求書を“月初の仕事”にしていない

たとえば受取請求書。多くの会社では、メールやチャットで届いたPDFを後で開き、保存し、内容を確認し、支払一覧に転記していると思います。

Fluxxでは、この部分を `invoice-receive.mjs` というスクリプトで処理しています。やっていることは大きく5つです。

1. Slackのbot宛DMに届いた新着ファイルを拾う
`slakky` 経由で新着のPDFや画像を取得します。つまり、請求書の受け取り窓口をSlackに寄せています。

2. ClaudeでOCRして、必要情報をJSONで抜く
会社名、金額、請求日、支払期日、請求書番号を抽出します。人が目で見て転記する工程をここで外しています。

3. Google Driveに電帳法を意識したファイル名で保存する
`etd-utils.mjs` を使って、日付・会社名・金額を含む名前に整えて保存します。あとで探せること、監査や確認に耐えることを優先しています。

4. 索引簿に追記する
保存して終わりではなく、支払期日付きで索引に残します。これが後続の振込リスト作成につながります。

5. #payment に通知し、送付者にも完了を返す
処理が終わるとSlackに通知が飛び、送った本人にも「受け付けました」「処理完了しました」と返ります。

ここで重要なのは、月初に請求書を“まとめて処理”していないことです。届いた時点で、保存・通知・索引登録まで終わっている。だから月初に残るのは確認だけになります。

発行請求書も、「月初に一件ずつ作る」運用にしていない

発行側も同じです。請求書を月初にfreeeで一件ずつ作っていると、担当者依存の重い仕事になります。

Fluxxでは `freee-create-invoices.mjs` で、Googleスプレッドシートの請求データからfreee請求書を一括作成しています。

このスクリプトでは、請求対象のタブを読み込み、クライアントごとの明細を抽出し、`freee` CLI で取引先を検索し、そのまま請求書を作成します。作成後はSlackに一覧通知まで投げるので、「誰の何月分をいくらで作ったか」がすぐ共有されます。

つまり、発行請求書の作成も、月初にfreee画面を見ながら手で繰り返す仕事ではなく、元データを整えた上でまとめて実行する仕事に変わっています。

ここでもポイントは、請求書作成だけを自動化して終わっていないことです。スプレッドシート、freee、Slack をつないで、確認まで含めてひとつの流れにしていることが効いています。

月初に必要なのは「判断」のみ、という状態を作る

受取請求書が届いたら自動で保存と索引登録まで終わる。発行請求書は元データからまとめて作成される。そうすると、月初に人がやるべきことはかなり変わります。

人がやるのは、抜け漏れがないかを見ること、例外を判断すること、最終確認をすることです。逆に言えば、受信、転記、保存、一覧化といった定型作業は、人が月初に抱え込む必要がなくなります。

実際、Fluxxでは月初の経理関連で次のような補助スクリプトも回しています。

`invoice-payment-list.mjs`
索引簿の支払期日をもとに、当月が支払期日の受取請求書を抽出して #payment に振込リストを出します。

`invoice-receivable-list.mjs`
freee上の未入金請求書を取得し、入金予定一覧として #sales に出します。

つまり、月初に必要な「見るべき一覧」もその場で作られる。担当者がExcelを開き直してまとめる必要がありません。

まとめ：月初を軽くすると、会社全体が軽くなる

DXというと、派手なことをイメージしがちです。ですが、会社が最初にラクになるのは、毎月必ず発生している重い仕事を潰したときです。

受取請求書の保存、発行請求書の作成、振込一覧、入金予定の共有。こうした月初業務は、きちんと分解するとかなりの部分を仕組みに移せます。そして、その結果として月初に残るのは「人が判断すべきこと」だけになります。

もし月初になるたびに本業が止まっているなら、そこはかなり改善余地があるサインです。私たちFluxxでは、こうした月初業務の整理から、使用ツールの設計、AIを使った分解、自動処理の構築まで一気通貫で組んでいます。

続けて読むなら、次は Vol.5 人を雇う前に、会社の仕事を分解してみる です。月初のような定型業務を外したあと、なお人が持つべき仕事をどう見分けるかを考えます。