税理士事務所の決算進捗管理｜期日から逆算するパイプライン設計の作り方

「今どの関与先の決算が止まっているのか、朝礼で聞かないと分からない」「資料をお願いしたはずが、締切間際に届いていないと気づく」——決算期の進捗管理について、会計事務所の方からよくうかがう課題です。

決算業務の進捗管理が営業案件の管理と決定的に違うのは、期日が最初から決まっているという点です。営業案件は「いつ決まるか分からないものを前に進める」管理ですが、決算業務は「動かせない期限に向けて、逆算した中間地点を守れているかを見る」管理になります。この違いを踏まえずに一般的な案件管理をそのまま当てはめると、ステージは並んでいるのに遅延が検知できない、という状態になります。

この記事では、HubSpotを例に決算・申告の進捗管理をどうパイプラインで組むかを、具体的なステージ案とともに解説します。手作業でのリスト作成をなくし、遅れを自動で浮かび上がらせるところまでを設計の対象にします。

会計事務所・税理士法人で所内の進捗管理を担当されている方、決算期の進行を担当者任せにせず可視化したい方に向けた内容です。次の4点がわかります。

• 期日から逆算するステージ設計 ── 申告期限を起点に、社内締切と中間地点をどこに置くかを整理します
• そのまま使えるステージ案 ── 資料依頼から申告・納付までの7ステージを、進む条件付きで提示します
• 毎期の案件を自動生成する仕組み ── 事業年度ごとに手で作り直す作業をなくします
• 資料未着の滞留を検知する方法 ── 遅れを「気づいた人が言う」から「仕組みが知らせる」に変えます

読み終える頃には、自社の決算業務をどのステージで区切り、どこにアラートを置くかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

決算業務の進捗管理が難しい3つの理由

まず、なぜ決算の進捗管理が属人化しやすいのかを整理します。

理由1：期日が関与先ごとにバラバラで、しかも動かせない

法人の申告期限は事業年度によって決まるため、関与先ごとに違います。3月決算が多いとはいえ、実際には毎月どこかの申告期限が来ます。しかもこの期日は交渉で動かせません。営業案件のように「来月に持ち越す」ことができない性質のため、遅延の検知は早ければ早いほど価値があります。

理由2：進捗が止まる原因の多くが「自社の外」にある

決算業務が止まる典型的な原因は、関与先からの資料が届かないことです。つまり進捗管理の対象は、自所のスタッフの作業状況だけではなく、関与先への依頼がどこまで進んでいるかを含みます。ここを管理対象に入れないと、「担当者は動いているのに案件は止まっている」状態が見えません。

理由3：ステージが「作業」で切られていて、判定できない

「決算作業中」「チェック中」といったステージにすると、いつ次に進むのかが担当者の感覚になります。3週間「決算作業中」のままでも、遅れているのか順調なのかが第三者には判別できません。ステージは作業名ではなく、完了した事実で区切る必要があります。

期日から逆算してステージを置く

決算進捗管理の設計は、申告期限から逆算するところから始めます。

逆算で置くべき中間地点

日数の置き方は事務所の体制や関与先の規模によって変わるため、まずは自所の実績から平均日数を出すことをおすすめします。理想の日数を先に決めると、守れないスケジュールが並ぶだけになります。

「社内締切」を必ず持つ

申告期限だけを管理していると、全案件が期限直前に集中します。申告期限より一定日数前に社内締切を置き、進捗の判定はこの社内締切を基準に行う設計にすると、余裕のある状態で異常を検知できます。

期日はプロパティーで持ち、計算で出す

決算月を関与先（会社レコード）に持たせておけば、申告期限は計算で求められます。案件ごとに手入力すると、必ずずれます。手入力する項目を減らすことが、そのまま精度につながる部分です。

決算パイプラインのステージ案

ここからは具体案です。

これは特定の事務所の実装ではなく、決算業務でよく出てくる進行を一般化した設計例です。そのまま検討のたたき台として使える粒度で示しています。

ステージ案（7ステージ）

ステージ2を独立させる意味

「資料受領待ち」を独立したステージにする理由は、止まっている原因が自所側か関与先側かを切り分けるためです。ここが分かれていれば、「今このステージに何件溜まっているか」が督促すべき件数そのものになります。所内の作業ステージと混ぜてしまうと、この数字が出せません。

「関与先説明」を省略しない

決算内容の説明と承認を独立したステージにしておくと、「申告書はできているが社長の承認が取れていない」という状態が見えます。この状態が期限間際まで残ると、直前で修正要望が出たときに対応できません。

業務ごとにパイプラインを分けるかどうか

営業側のパイプラインと分ける理由は会計事務所のCRM活用ガイドで整理しています。パイプラインを分ける考え方そのものは、業種が違っても共通で、工事案件のパイプライン設計でも同じ論点を扱っています。

毎期の案件を自動生成する

決算パイプラインで最も手間になるのが、毎年の案件レコードを作る作業です。

手作業でリストを作らない

多くの事務所では、期首や年度初めに担当者がExcelで案件リストを作っています。この作業自体は数時間で終わるとしても、その後の更新が続かないことが問題です。リストとCRMが二重に存在すると、必ずどちらかが実態からずれます。

日付プロパティーを基準にした自動化

HubSpotのワークフローでは、日付または日時プロパティーを基準にして処理を遅延させるアクションが用意されています（HubSpotナレッジベース「ワークフローアクションを選択する」 2026年8月1日確認）。関与先レコードの決算月から算出した「次回決算日」を基準に、その一定日数前に決算取引を自動作成し、担当者を割り当てる形が組めます。

これにより、担当者が意識しなくても、資料依頼のタイミングで案件が一覧に現れる状態になります。人の記憶をトリガーにしないことが、繁忙期に効いてきます。

前期の情報を引き継ぐ

自動生成のときに、前期の論点メモ、必要資料の一覧、関与先固有の注意事項を引き継ぐと、担当が変わっても同じ品質で進められます。ここまで作ると、進捗管理の仕組みが引き継ぎの仕組みを兼ねます。ワークフローの基本的な作り方はHubSpotワークフローの設定ガイドをご覧ください。

遅延と滞留を検知する

進捗管理の価値は、順調な案件ではなく、止まっている案件を見つけることにあります。

検知したい3つの状態

通知は「担当者の次に、マネージャー」

いきなり全件がマネージャーに通知されると、通知が多すぎて見なくなります。まず担当者に通知し、それでも動かない場合に上位へエスカレーションする二段構えにすると、通知の意味が保たれます。

ダッシュボードは3つで足りる

決算期に見るレポートは、多くても3つで足ります。「決算月別の案件件数と進捗状況」「資料受領待ちの一覧（依頼からの経過日数順）」「社内締切まで7日以内で未完了の案件」。この3つがあれば、朝礼の資料は作らずに済みます。

なかでも効果が分かりやすいのは、2つ目の「資料受領待ちの一覧」です。依頼日からの経過日数で並べておけば、上から順に督促すればよい状態になります。誰が何日待たされているかを毎回思い出す必要がなくなり、督促という作業そのものが手順化されます。

翌期の改善に使う数字も残す

進捗管理を1期回すと、「資料の受領に平均何日かかったか」「どの関与先が毎年遅れるか」という実績が残ります。この数字があれば、翌期は依頼のタイミングを前倒しする、資料の形式を変える、といった具体的な打ち手が検討できます。進捗管理は、当期を乗り切るためだけの仕組みではありません。翌期の設計を良くするための記録でもあります。

レポートを増やすほど見なくなるという傾向は、業種を問わず共通です。実際に会議で使われたものだけ残す進め方をおすすめします。レポートの設計はHubSpotレポート・ダッシュボード設計で扱っています。

年末調整・確定申告への展開

決算パイプラインが回り始めたら、他の年次業務にも同じ考え方が使えます。ただし、そのまま流用すると噛み合わない部分があります。

年末調整は「社数」ではなく「人数」で重さが変わる

決算業務は関与先1社＝1件で重さがある程度そろいますが、年末調整は対象人数によって工数が10倍以上変わります。取引に「対象人数」をプロパティーとして持たせておくと、件数ではなく想定工数で負荷を見られるようになります。

個人の確定申告は期限が一律

法人決算と違い、個人の確定申告は期限が同一です。全案件の締切が同じになるため、逆算の中間地点は「資料受領完了」を最重視する形になります。すべてが同時に動く業務では、入口の詰まりが致命的になるためです。

業務ごとの違いを整理する

ステージは共通化しすぎない

「資料依頼→受領→作成→レビュー→説明→提出」という骨格は共通ですが、年末調整には「所内レビュー」に相当する工程が薄く、代わりに「従業員からの書類回収」という別の待ちが入ります。骨格が似ているからと1つのパイプラインにまとめると、どちらにも合わないステージが残ります。業務ごとにパイプラインを分け、ステージ名は業務の言葉で書くほうが運用が揃います。

運用に乗せるための注意点

設計ができたら、次は続けるための工夫です。

必須項目を増やしすぎない

ステージ移動時の必須項目を増やすと、担当者はステージを動かさなくなります。動かさなければパイプラインは実態を映しません。必須にするのは、そのステージの判定に不可欠な1〜2項目に留めることをおすすめします。

繁忙期に新しい運用を始めない

決算の集中期に新しい仕組みを導入すると、ほぼ確実に定着しません。関与先の決算月が分散している事務所であれば、まず件数の少ない月の決算だけをパイプラインに載せて試し、手応えを確認してから全体に広げる進め方が現実的です。

最初から全業務を載せない

決算・申告だけで運用を開始し、月次監査・年末調整は後から検討する。この順序が続きます。一度にすべてを載せると、入力量が増えて繁忙期に破綻するためです。

事務所ごとに最適な形は変わる

ここまで示したステージ案は検討のたたき台です。関与先の規模、記帳代行の有無、担当制かチーム制かによって、必要なステージは変わります。3か月から半年運用して、使われていないステージを1つ統合するくらいの見直しを前提に始めるほうが、結果的に自所に合った形になります。

よくある質問

決算業務の進捗管理について、ご相談の場でよくいただく質問をまとめました。

Q1. 士業向けの業務管理システムを使っています。CRMで進捗管理をする意味はありますか。

業務の進捗管理だけが目的であれば、業界特化のシステムのほうが機能が揃っていることは正直にお伝えします。CRMで管理する価値が出るのは、新規開拓・顧問料の管理・関与先とのコミュニケーション履歴と、業務の進捗を同じ場所でつなげたい場合です。「この関与先は決算が毎年遅れがちで、顧問料の改定交渉も止まっている」といった状態が、1つの画面で見えることに意味があります。逆に、業務管理が既存システムで問題なく回っているのであれば、無理に移す必要はありません。

Q2. 決算業務を「取引」で管理することに違和感があります。

名称の問題であれば、オブジェクトの表示名を変更できます。取引パイプラインの仕組みを使う理由は、期日・担当者・ステージ・金額を標準で持ち、レポートとワークフローがそのまま使えるためです。管理したい構造が同じであれば、名前が「取引」であることは実務上の障害になりません。

Q3. 資料が届かない関与先への督促まで自動化できますか。

督促メールの自動送信は技術的には可能です。ただし、機械的な督促は関係性を損なうことがあるため、担当者への通知までを自動化し、関与先への連絡は人が行う設計をおすすめします。1回目の案内は自動、2回目以降は担当者から、という切り分けであれば、負担を減らしつつ関係性も保てます。

Q4. 決算月ごとに担当者の負荷が偏ります。CRMで平準化できますか。

平準化そのものはCRMではできませんが、判断の材料は作れます。関与先の決算月と担当者を持っていれば、月別・担当者別の件数と規模が集計できます。この数字があれば、担当の入れ替えや外部委託の判断ができます。数字がないまま「忙しい」という感覚だけで議論しても、配置は変わりません。

Q5. 過去の決算案件のデータは移行すべきですか。

全期分の移行は必要ないことがほとんどです。過去の詳細は既存システムや紙の資料に残っているため、CRMには直近1期分の「論点メモ」「必要資料の一覧」「関与先固有の注意事項」だけを移せば、翌期の運用は始められます。移行の範囲を広げるほど立ち上げが遅くなるため、運用に必要な最小限から始めることをおすすめします。

まとめ

決算業務の進捗管理は、期日から逆算する設計にすることで初めて機能します。要点を整理します。

• 営業案件とは逆に、期日が先に決まっている。動かせない申告期限から逆算し、社内締切を必ず持たせます
• 「資料受領待ち」を独立したステージにする。止まっている原因が自所側か関与先側かを切り分けられます
• ステージは作業名ではなく完了した事実で区切る。「決算作業中」では遅れているかどうかを判定できません
• 毎期の案件は自動生成する。決算月を基準に日付ベースで作成すれば、手作業のリストが不要になります
• 繁忙期に新しい運用を始めない。件数の少ない決算月から試し、手応えを確認してから広げます

最初の一歩としておすすめしたいのは、「直近で申告が期限間際になった案件を3件挙げ、どこで何日止まっていたかを書き出す」ことです。資料の受領で止まっていたのか、所内レビューで止まっていたのか。3件並べるだけで、自所に必要なステージとアラートの位置が具体的に見えてきます。

そのうえで、まずは決算・申告だけをパイプラインに載せ、資料受領待ちの件数が見えるようになってから、自動生成と通知を足していく。この順序が現場に残ります。

自社の決算進捗管理をどう設計するか具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の進め方をうかがったうえで、設計の方向性をご提案します。