決算業務の進捗管理とは、動かせない申告期限から逆算して中間地点を設け、その地点を守れているかを見る管理です。期日から逆算したステージとアラートを組めば、遅れは担当者の記憶ではなく仕組みが知らせる状態になります。
- 「今どの関与先の決算が止まっているのか、朝礼で聞かないと分からない」
- 「資料をお願いしたはずが、締切間際に届いていないと気づく」
——決算期の進捗管理について、会計事務所の方からよくうかがう課題です。
決算業務の進捗管理が営業案件の管理と決定的に違うのは、期日が最初から決まっているという点です。
- 営業案件 ── 「いつ決まるか分からないものを前に進める」管理です
- 決算業務 ── 「動かせない期限に向けて、逆算した中間地点を守れているかを見る」管理になります
この違いを踏まえずに一般的な案件管理をそのまま当てはめると、ステージは並んでいるのに遅延が検知できない、という状態になります。
この記事では、HubSpotを例に決算・申告の進捗管理をどうパイプラインで組むかを、具体的なステージ案とともに解説します。手作業でのリスト作成をなくし、遅れを自動で浮かび上がらせるところまでを設計の対象にします。
この記事でわかること
決算期の進行を担当者任せにせず、仕組みで可視化したい会計事務所・税理士法人の方向けに、期日逆算の考え方から自動化の組み方までを整理しました。次の4点がわかります。
- 期日から逆算するステージ設計 — 申告期限を起点に、社内締切と中間地点をどこに置くかを整理します
- そのまま使えるステージ案 — 資料依頼から申告・納付までの7ステージを、進む条件付きで提示します
- 毎期の案件を自動生成する仕組み — 事業年度ごとに手で作り直す作業をなくします
- 資料未着の滞留を検知する方法 — 遅れを「気づいた人が言う」から「仕組みが知らせる」に変えます
所内の進捗管理を任されている方、毎期の決算を属人化させたくない方に向けて書いています。最後まで読むと、自所の決算業務をどのステージで区切り、どこにアラートを置くかのたたき台が作れるようになります。
税理士事務所の決算進捗管理が難しい3つの理由
まず、なぜ決算の進捗管理が属人化しやすいのかを整理します。Excelやスプレッドシートで案件一覧を作る方法自体は手軽ですが、更新が担当者の手作業に依存するため、繁忙期ほど実態とずれていきます。難しさの背景には、決算業務特有の3つの事情があります。
理由1:期日が関与先ごとにバラバラで、しかも動かせない
法人の申告期限は事業年度によって決まるため、関与先ごとに違います。3月決算が多いとはいえ、実際には毎月どこかの申告期限が来ます。しかもこの期日は交渉で動かせません。営業案件のように「来月に持ち越す」ことができない性質のため、遅延の検知は早ければ早いほど価値があります。
理由2:進捗が止まる原因の多くが「自社の外」にある
決算業務が止まる典型的な原因は、関与先からの資料が届かないことです。つまり進捗管理の対象は、自所のスタッフの作業状況だけではなく、関与先への依頼がどこまで進んでいるかを含みます。ここを管理対象に入れないと、「担当者は動いているのに案件は止まっている」状態が見えません。
理由3:ステージが「作業」で切られていて、判定できない
「決算作業中」「チェック中」といったステージにすると、いつ次に進むのかが担当者の感覚になります。数週間「決算作業中」のままでも、遅れているのか順調なのかが第三者には判別できません。
ステージは作業名ではなく、完了した事実で区切る必要があります。
期日から逆算してステージを置く
決算進捗管理の設計は、申告期限から逆算するところから始めます。どこに中間地点を置くかが決まれば、そこからステージの切り方とアラートの位置が導けます。次の図は、申告期限を起点に各中間地点を逆算して配置したイメージです。

逆算で置くべき中間地点
| 逆算の地点 |
意味 |
遅れたときに起きること |
| 申告期限 |
法定の期限。動かせない起点 |
期限後申告となり、関与先に不利益が生じます |
| 所内の申告締切 |
申告期限より前に置く社内の締切 |
期限直前に作業が集中し、確認の質が落ちます |
| 所長・税理士レビュー完了 |
有資格者による内容確認が終わった時点 |
修正が発生した場合の手戻り時間がなくなります |
| 決算案の完成 |
数値が固まり、説明できる状態 |
関与先への説明・意思決定の時間が取れなくなります |
| 試算表の確定 |
会計データの入力・照合が完了 |
決算作業に入れません |
| 資料の受領完了 |
関与先からの必要資料が揃った |
すべての後工程が止まります |
| 資料の依頼 |
依頼を送付した時点 |
依頼が遅いと、受領も遅れます |
日数の置き方は事務所の体制や関与先の規模によって変わるため、まずは自所の実績から平均日数を出すことをおすすめします。理想の日数を先に決めると、守れないスケジュールが並ぶだけになります。
「社内締切」を判定の基準にする
申告期限だけを管理していると、全案件が期限直前に集中します。申告期限より一定日数前に社内締切を置き、進捗の判定はこの社内締切を基準に行う設計にすると、余裕のある状態で異常を検知できます。
期日はプロパティで持ち、計算で出す
決算月を関与先(会社レコード)に持たせておけば、申告期限は計算で求められます。案件ごとに手入力すると、入力のたびにずれが生じやすくなります。手入力する項目を減らすことが、そのまま精度につながる部分です。
決算パイプラインのステージ案
ここからは具体案です。特定の事務所の実装ではなく、決算業務でよく出てくる進行を一般化した設計例で、そのまま検討のたたき台として使える粒度で示しています。次の図は、資料依頼から申告・納付完了までを7つのステージで並べたパイプラインボードの構成例です。

決算の取引レコードは関与先の会社レコードに紐づくため、過去のやり取りや顧問契約の情報と同じ画面で進捗を確認できます。進捗管理だけが別システムに孤立していると生まれない、一元管理ならではの効果です。
ステージ案(7ステージ)
| # |
ステージ |
次に進む条件(客観的な事実) |
このステージで持つ情報 |
| 1 |
資料依頼 |
依頼リストを送付した |
依頼日、依頼方法、必要資料の一覧 |
| 2 |
資料受領待ち |
必要資料がすべて届いた |
受領日、未着資料、督促回数 |
| 3 |
記帳・試算表確定 |
試算表が確定した |
確定日、修正仕訳の有無 |
| 4 |
決算案作成 |
決算書・申告書の案が完成した |
完成日、税額の見込み、論点メモ |
| 5 |
所内レビュー |
有資格者のレビューが完了した |
レビュー日、レビュー者、指摘事項 |
| 6 |
関与先説明・承認 |
関与先から内容の承認を得た |
説明日、承認方法 |
| 7 |
申告・納付完了 |
電子申告の送信と納付案内が完了した |
申告日、納付期限、受信通知の保管 |
営業のパイプラインではステージごとに受注確度を設定し、加重した金額でフォーキャストを作ります。決算業務で軸になるのは確度ではなく「期日までの残日数」ですが、ステージ・進む条件・各ステージで持つ情報を先に決めるという設計の考え方は共通です。
ステージ2を独立させる意味
「資料受領待ち」を独立したステージにする理由は、止まっている原因が自所側か関与先側かを切り分けるためです。ここが分かれていれば、「今このステージに何件溜まっているか」が督促すべき件数そのものになります。所内の作業ステージと混ぜてしまうと、この数字が出せません。
「関与先説明」を省略しない
決算内容の説明と承認を独立したステージにしておくと、「申告書はできているが社長の承認が取れていない」という状態が見えます。この状態が期限間際まで残ると、直前で修正要望が出たときに対応できません。
業務ごとにパイプラインを分けるかどうか
| 業務 |
推奨 |
理由 |
| 法人の決算・申告 |
専用パイプライン |
件数が多く、ステージが安定しています |
| 個人の確定申告 |
決算と同じパイプライン、または専用 |
期限が一律のため、ステージは近い形で使えます |
| 年末調整 |
専用パイプライン |
進行の形がまったく違うためです |
| 月次監査 |
パイプラインではなくタスクや繰り返しの仕組み |
件数が多すぎ、ステージ管理の粒度に合いません |
| 新規開拓 |
別パイプライン(必須) |
混ぜると受注見込みのレポートが正しく集計できなくなります |
営業側のパイプラインと分ける理由は会計事務所のCRM活用ガイドで整理しています。パイプラインを分ける考え方そのものは、業種が違っても共通で、工事案件のパイプライン設計でも同じ論点を扱っています。
毎期の案件を自動生成する
決算パイプラインで最も手間になるのが、毎年の案件レコードを作る作業です。関与先ごとに決算月が違うため、対象時期の抽出から入力までを手で行うと、その都度ミスの余地が生まれます。次の図は、関与先の決算月を基準に決算取引を自動作成する流れのイメージです。

手作業でリストを作らない
多くの事務所では、期首や年度初めに担当者がExcelで案件リストを作っています。この作業自体は数時間で終わるとしても、その後の更新が続かないことが問題です。リストとCRMが二重に存在すると、いずれどちらかが実態からずれます。
日付プロパティを基準にした自動化
HubSpotのワークフローでは、日付または日時プロパティを基準にして処理を遅延させるアクションが用意されています(HubSpotナレッジベース「ワークフローアクションを選択する」、2026年8月時点で確認)。関与先レコードの決算月から算出した「次回決算日」を基準に、その一定日数前に決算取引を自動作成し、担当者を割り当てる形が組めます。
これにより、担当者が意識しなくても、資料依頼のタイミングで案件が一覧に現れる状態になります。人の記憶をトリガーにしないことが、繁忙期に効いてきます。
ただし、自動化するのはレコードの作成と割り当てまでに留め、依頼文面の調整や関与先とのやり取りは人が行う設計をおすすめします。
前期の情報を引き継ぐ
自動生成のときに、次の情報を前期から引き継ぐと、担当が変わっても同じ品質で進められます。
- 前期の論点メモ
- 必要資料の一覧
- 関与先固有の注意事項
個人の経験や記憶に頼るのではなく仕組みで引き継ぐ形にすると、新人の立ち上がりも早くなります。ここまで作ると、進捗管理の仕組みが引き継ぎの仕組みを兼ねます。ワークフローの基本的な作り方はHubSpotワークフローの設定ガイドをご覧ください。
遅延と滞留を検知する
進捗管理の価値は、順調な案件ではなく、止まっている案件を見つけることにあります。ステージを並べただけでは遅れは見えないため、「どんな状態を異常とみなすか」「誰に知らせるか」を先に決めておきます。
検知したい3つの状態
| 検知したい状態 |
判定の条件 |
通知先 |
| 資料が届かない |
資料依頼から一定日数が経過し、まだ受領待ち |
担当者、必要に応じてマネージャー |
| 社内締切に間に合わない |
社内締切まで残り日数が少なく、レビュー未完了 |
担当者とマネージャー |
| ステージが動いていない |
同じステージに一定日数以上滞留 |
マネージャー |
通知は「担当者の次に、マネージャー」
いきなり全件がマネージャーに通知されると、通知が多すぎて見なくなります。まず担当者に通知し、それでも動かない場合に上位へエスカレーションする二段構えにすると、通知の意味が保たれます。
ダッシュボードは3つで足りる
決算期に見るレポートは、多くても3つで足ります。
- 決算月別の案件件数と進捗状況
- 資料受領待ちの一覧(依頼からの経過日数順)
- 社内締切まで7日以内で未完了の案件
この3つがあれば、朝礼の資料は作らずに済みます。
なかでも効果が分かりやすいのは、2つ目の「資料受領待ちの一覧」です。依頼日からの経過日数で並べておけば、上から順に督促すればよい状態になります。誰が何日待たされているかを毎回思い出す必要がなくなり、督促という作業そのものが手順化されます。
翌期の改善に使う数字も残す
進捗管理を1期回すと、「資料の受領に平均何日かかったか」「どの関与先が毎年遅れるか」という実績が残ります。この数字があれば、翌期は依頼のタイミングを前倒しする、資料の形式を変える、といった具体的な打ち手が検討できます。進捗管理は、当期を乗り切るためだけの仕組みではありません。翌期の設計を良くするための記録でもあります。
レポートを増やすほど見なくなるという傾向は、業種を問わず共通です。実際に会議で使われたものだけ残す進め方をおすすめします。レポートの設計はHubSpotレポート・ダッシュボード設計で扱っています。
年末調整・確定申告への展開
決算パイプラインが回り始めたら、他の年次業務にも同じ考え方が使えます。ただし、期限の性質や工数を左右する要素が業務ごとに違うため、そのまま流用すると噛み合わない部分があります。
年末調整は「社数」ではなく「人数」で重さが変わる
決算業務は関与先1社=1件で重さがある程度そろいますが、年末調整は対象人数によって工数が大きく変わります。取引に「対象人数」をプロパティとして持たせておくと、件数ではなく想定工数で負荷を見られるようになります。
個人の確定申告は期限が一律
法人決算と違い、個人の確定申告は期限が同一です。全案件の締切が同じになるため、逆算の中間地点は「資料受領完了」を最重視する形になります。すべてが同時に動く業務では、入口の詰まりが全体の遅延に直結するためです。
業務ごとの違いを整理する
| 業務 |
期限の性質 |
工数を左右する要素 |
逆算で重視する地点 |
| 法人の決算・申告 |
関与先ごとに分散 |
関与先の規模、記帳代行の有無 |
試算表の確定 |
| 個人の確定申告 |
全件が同一期限 |
所得の種類、資料の量 |
資料受領完了 |
| 年末調整 |
全件が同一期限 |
対象人数 |
従業員からの書類回収 |
| 月次監査 |
毎月繰り返し |
仕訳件数 |
パイプラインでは扱わない |
ステージは共通化しすぎない
「資料依頼→受領→作成→レビュー→説明→提出」という骨格は共通ですが、年末調整には「所内レビュー」に相当する工程が薄く、代わりに「従業員からの書類回収」という別の待ちが入ります。骨格が似ているからと1つのパイプラインにまとめると、どちらにも合わないステージが残ります。業務ごとにパイプラインを分け、ステージ名は業務の言葉で書くほうが運用が揃います。
運用に乗せるための注意点
設計ができたら、次は続けるための工夫です。仕組みは作っただけでは定着せず、入力の負担と開始のタイミングをどう抑えるかが、運用が続くかどうかを分けます。
必須項目を増やしすぎない
ステージ移動時の必須項目を増やすと、担当者はステージを動かさなくなります。動かさなければパイプラインは実態を映しません。必須にするのは、そのステージの判定に不可欠な1〜2項目に留めることをおすすめします。
繁忙期に新しい運用を始めない
決算の集中期に新しい仕組みを導入しても、定着しないケースがほとんどです。関与先の決算月が分散している事務所であれば、まず件数の少ない月の決算だけをパイプラインに載せて試し、手応えを確認してから全体に広げる進め方が現実的です。
最初から全業務を載せない
決算・申告だけで運用を開始し、月次監査・年末調整は後から検討する。この順序で進めるのが現実的です。一度にすべてを載せると、入力量が増えて繁忙期に破綻するためです。
事務所ごとに最適な形は変わる
ここまで示したステージ案は検討のたたき台です。関与先の規模、記帳代行の有無、担当制かチーム制かによって、必要なステージは変わります。3か月から半年運用して、使われていないステージを1つ統合するくらいの見直しを前提に始めるほうが、結果的に自所に合った形になります。
よくある質問
決算業務の進捗管理について、ご相談の場でよくいただく質問をまとめました。
- 業務管理システムとの関係 ── 進捗管理だけが目的であれば、業界特化のシステムのほうが機能が揃っています
- 「取引」という名称 ── オブジェクトの表示名を変更できます
- 督促の自動化 ── 自動送信は可能ですが、関係性を損なうおそれがあるため、担当者への通知までを自動化し、関与先への連絡は人が行う設計をおすすめします
- 負荷の平準化 ── 平準化そのものはできませんが、判断の材料は作れます
- 過去データの移行 ── 全期分は必要ないことがほとんどで、運用に必要な最小限から始めます
Q1. 士業向けの業務管理システムを使っています。CRMで進捗管理をする意味はありますか。
業務の進捗管理だけが目的であれば、業界特化のシステムのほうが機能が揃っていることは正直にお伝えします。CRMで管理する価値が出るのは、次の情報と業務の進捗を同じ場所でつなげたい場合です。
- 新規開拓
- 顧問料の管理
- 関与先とのコミュニケーション履歴
「この関与先は決算が毎年遅れがちで、顧問料の改定交渉も止まっている」といった状態が、1つの画面で見えることに意味があります。逆に、業務管理が既存システムで問題なく回っているのであれば、無理に移す必要はありません。
Q2. 決算業務を「取引」で管理することに違和感があります。
名称の問題であれば、オブジェクトの表示名を変更できます。取引パイプラインの仕組みを使う理由は、期日・担当者・ステージ・金額を標準で持ち、レポートとワークフローがそのまま使えるためです。管理したい構造が同じであれば、名前が「取引」であることは実務上の障害になりません。
Q3. 資料が届かない関与先への督促まで自動化できますか。
督促メールの自動送信は技術的には可能です。ただし、機械的な督促は関係性を損なうことがあるため、担当者への通知までを自動化し、関与先への連絡は人が行う設計をおすすめします。1回目の案内は自動、2回目以降は担当者から、という切り分けであれば、負担を減らしつつ関係性も保てます。
Q4. 決算月ごとに担当者の負荷が偏ります。CRMで平準化できますか。
平準化そのものはCRMではできませんが、判断の材料は作れます。関与先の決算月と担当者を持っていれば、月別・担当者別の件数と規模が集計できます。この数字があれば、担当の入れ替えや外部委託の判断ができます。数字がないまま「忙しい」という感覚だけで議論しても、配置は変わりません。
Q5. 過去の決算案件のデータは移行すべきですか。
全期分の移行は必要ないことがほとんどです。過去の詳細は既存システムや紙の資料に残っているため、CRMには直近1期分の「論点メモ」「必要資料の一覧」「関与先固有の注意事項」だけを移せば、翌期の運用は始められます。移行の範囲を広げるほど立ち上げが遅くなるため、運用に必要な最小限から始めることをおすすめします。
まとめ
決算業務の進捗管理は、期日から逆算する設計にすることで初めて機能します。要点を整理します。
- 営業案件とは逆に、期日が先に決まっている。動かせない申告期限から逆算し、社内締切を持たせます
- 「資料受領待ち」を独立したステージにする。止まっている原因が自所側か関与先側かを切り分けられます
- ステージは作業名ではなく完了した事実で区切る。「決算作業中」では遅れているかどうかを判定できません
- 毎期の案件は自動生成する。決算月を基準に日付ベースで作成すれば、手作業のリストが不要になります
- 繁忙期に新しい運用を始めない。件数の少ない決算月から試し、手応えを確認してから広げます
最初の一歩としておすすめしたいのは、「直近で申告が期限間際になった案件を3件挙げ、どこで何日止まっていたかを書き出す」ことです。資料の受領で止まっていたのか、所内レビューで止まっていたのか。3件並べるだけで、自所に必要なステージとアラートの位置が具体的に見えてきます。
そのうえで、次の順に進めると現場に残りやすくなります。
- まず決算・申告だけをパイプラインに載せ、資料受領待ちの件数が見える状態を作る
- 滞留のアラートとダッシュボード3枚を足し、朝礼でそのまま使えるかを試す
- 1期回して残った実績(受領までの日数・遅れがちな関与先)を見て、翌期の依頼タイミングとステージを調整する
自社の決算進捗管理をどう設計するか具体的に検討したい場合は、StartLinkの無料相談もご活用ください。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい