第3営業日の朝九時、経理部の締め会議が始まる。画面に映っているのは、共有フォルダに置かれた工程表のExcelで、行数は200を超える。 各担当が自分の行の状況欄に「済」「作業中」「未着手」を打ち込む運用である。会議の四十分のうち三十分は、「済」になっている行が実際に済んでいるのかの確認に使われる。 固定資産の償却は「済」だが、減損の判定に使う資料はまだ届いていない。原価差額の配賦は「作業中」だが、担当者はもう終わっていて、状況欄を直し忘れていた。翌週、情報システム部から提案が来る。締めのタスク管理をSAPの仕組みに載せれば、依存関係も進捗も自動で見える、と。 経理部長は、それで会議がなくなるなら入れたいと思う。だが入れた結果、Excelとツールの両方を更新する運用になった会社を、何社か知っている。
締めを遅くしているのは、表ではなく「待ち」の見えなさ
Excelの工程表が締めを遅くしている、という言い方は正確ではない。遅くしているのは、前の工程が実際に終わったかどうかを、次の工程の担当者が自分で確かめに行かなければならない構造である。
工程表の状況欄は、自己申告である。「済」と打ったのが何時何分で、何をもって済としたのかは記録されない。 次の工程の担当者は、前工程の担当者にチャットで聞くか、SAPの画面で転記済みの伝票を探しに行く。依存関係は表の中に書かれていないので、「自分が何を待っているのか」は担当者の頭の中にしかない。 その結果、全員が集まる会議で、全員の頭の中を順番に口に出してもらうことになる。締め会議が長いのは、会議の進め方が悪いからではない。依存関係の情報が、会議以外に存在しないからである。
締めのタスク管理を仕組みに載せる意味は、ここにある。依存関係を定義として持ち、前工程が完了したら後工程が処理可能になり、システムで流せる処理はその場で流す。 待ちの状態が、人に聞かなくても画面で見える。
締め管理の仕組みが持っているもの
SAPがこの領域で戦略製品として位置づけているのが、SAP Advanced Financial Closing（以下AFC）である。以前は「SAP S/4HANA Cloud for advanced financial closing」という名称で出ていた、クラウドのアプリケーションである。 SAPの担当者が公開している解説を並べると、仕組みの骨格は次のようになる。
第一に、テンプレートと毎期のタスクリストの分離。 タスクリストのテンプレートが、特定の締めサイクルごとのタスクリストの基礎になる。月次の締めを始めるときに、テンプレートからその期のタスクリストを作る。
第二に、タスクの種類。 手作業の指示を書いておく「Note」、画面を開かせる「Web Application」、そして接続先のシステムでプログラムを実行する「Job」がある。Jobのタスクは、償却や外貨評価のようなバックグラウンド処理を、前工程の完了を待ってから流す使い方ができる。
第三に、依存関係。 タスクに先行と後続を設定する。締めの構造は会社コード・管理領域・プラントといったフォルダで組み、フォルダ単位で標準のタスク群を割り当てる。
第四に、接続先。 AFCはSAP ERP（ECC）にもS/4HANAにも接続でき、一つのテンプレートに複数の接続先システムを入れて、システムをまたいだ前後関係を持たせることもできる。S/4HANA Cloud Public Editionでは、AFCとの連携がスコープアイテム4HG「Advanced Financial Closing Integration」として用意されている。そして全体の進み具合は、完了率・エラー・遅延を示す概況のアプリで見る。
オンプレミスの側には、以前からSAP Financial Closing cockpitがある。SAPが公開している互換性スコープの一覧（SAP Note 2269324の添付資料）には、SAP Financial Closing cockpitが互換性パッケージの項目として載っており、スケジュールマネージャの項目にはAFCが代替として利用可能だと書かれている。 一覧の有効期限は2025年12月31日と表記されていたが、SAPは2025年12月31日付の発表で、オンプレミス版の互換性パッケージの大半について、使用権を最後の5か月の移行期間として2026年5月末まで延長した。その延長後の期限も、すでに過ぎている。 自社で使っている項目が延長の対象だったかどうかは、個別に確認するしかない（S/4HANAで月次決算はどこまで早くなるか、締め作業の縮む部分と残る部分）。
ここまでを読むと、入れない理由はないように見える。問題は、この仕組みの価値のほとんどが「定義された依存関係」と「定義されたジョブ」から生まれていることである。 定義は、誰かが作り、誰かが保守する。
効くのは、依存関係が毎期同じ会社だけ
締め管理の仕組みに載せる費用は、導入時に一回かかるものと、工程が変わるたびにかかるものに分かれる。前者は見積りに載るが、後者は載らない。 そして締めが速くなるかどうかを決めているのは、後者のほうである。
保守の感覚をつかむには、SAPの担当者自身の説明が参考になる。2026年2月に追加されたタスクグループの機能について、同社の解説は、タスクリストモデルへの更新は新しいタスクにしか反映されないのに対し、タスクグループのテンプレートへの更新は依存関係を含めてタスクグループの変更として反映される、という比較表を載せている。 どこを直せば、どの範囲まで変更が届くのか。これを理解している担当者がいないと、テンプレートは少しずつ実態からずれていく。
工程が毎期ほぼ同じ会社では、このずれはほとんど起きない。単体の月次締めは、たいてい定型である。 仕訳の自動転記、償却、外貨評価、原価差額の配賦、未払の計上、照合、試算表の確認。順番も担当も毎月同じで、変わるのは年に数回の制度改正と組織変更くらいである。 この種の工程は、一度定義すれば、Jobのタスクと依存関係がそのまま効き続ける。
逆に、毎期やることが変わる会社がある。買収が続いて連結の範囲が四半期ごとに動く。プロジェクト単位の見積り計上が多く、対象案件が毎月入れ替わる。監査法人から個別の論点が来るたびに、確認手順が一つ増える。 こうした会社で工程表の行が入れ替わるのは、管理が悪いからではなく、事業がそう動いているからである。そしてこの入れ替わりを、締めの最中にテンプレートへ反映する時間は、経理のどこにもない。
二重管理はこうして始まる
変動の大きい会社で締め管理の仕組みを入れると、似た順番で二重管理が始まることが多い。
稼働初月は、Excelの工程表をそのままテンプレートに移す。 最初の二か月は、仕組みの上で締めが進む。三か月目に、新しい連結子会社の取り込み作業が追加になる。 テンプレートを直す権限を持つのは導入を担当した一人だけで、その人は取り込み作業そのものに追われている。そこで誰かが、とりあえず追加分だけを手元のExcelで管理しはじめる。
半年後の状態はこうなる。仕組みの上のタスクは、監査で証跡を見せるために「済」にされ続けている。実際の段取りは、Excelとチャットで進んでいる。 担当者は同じ作業の状況を二か所に書く。部長はどちらの表示も信用しなくなり、締め会議が復活する。道具を入れる前より、更新の手間が一つ増えている。
これは、現場が勝手に作ったツールが決算の一部になっていく構造と同じ形をしている（現場が作った経理の自動化ツールは誰が保守するか、シャドーITへの依存を防ぐ）。違うのは、今回は会社が正式に入れた仕組みの外側に、非公式の表が生まれていることである。 正式な仕組みの側に証跡が残っているように見えるぶん、発見はむしろ遅れる。
移す前に測るのは、工程表の入れ替わり率
では、自社がどちら側なのかをどう見分けるか。感覚で決めずに、過去の工程表で測る。
月次の工程表を上書きしていなければ、過去12か月分のExcelが残っているはずである。隣り合う二か月を比べて、行の追加・削除、担当者の変更、前後関係の変更を数える。 それを前月の行数で割ったものが、その月の入れ替わり率になる。上書きしていて残っていない場合は、締め会議の議事録やチャットの記録から、臨時に発生した作業を拾う。
測るときは、工程を三つに分けて数える。
一つ目は、システムの中で完結する処理。 償却、外貨評価、配賦、自動転記。Jobのタスクとして定義でき、前工程の完了を待って流せる。ここは入れ替わりがほぼゼロで、仕組みに載せた効果が最も大きい。
二つ目は、システムの画面で行う手作業。 未払の手入力、照合、残高の確認。Web ApplicationやNoteとして定義できる。入れ替わりは小さいが、ゼロではない。
三つ目は、システムの外にある待ち。 子会社からの数字、事業部からの見積りの根拠、監査人への回答、経営会議での判断。仕組みに載せても、待ちの時間そのものは縮まない。 入れ替わりが最も大きいのも、ここである。
入れ替わり率を三つに分けて並べると、線はたいてい自然に引ける。一つ目と二つ目で入れ替わりが小さい範囲だけを仕組みに載せ、三つ目は載せない。 あるいは、三つ目については「待っている」という状態だけを一つのタスクとして持たせ、中身の段取りは担当者に任せる。全部を載せようとしたときに、二重管理が始まる。
統制の証跡としての価値は、別に計算する
締め管理の仕組みには、速さとは別の価値がある。証跡である。
前掲の実施基準のとおり、決算・財務報告プロセスは実施頻度が低く評価できる実例が少ないため、慎重に運用状況の評価を行う必要がある。Excelの工程表では、誰がいつ何を確認して「済」にしたのかが残らない。 仕組みの上では、完了の時刻と実行者が記録される。
一方で、Excelに置き続ける場合の統制の宿題も、すでに書かれている。システム管理基準 追補版は、スプレッドシート等の統制として、作成者と利用者の分離または第三者によるチェック、文書化、バックアップ、データの変更権限の制限、再計算による検証といった対策を挙げている。 工程表そのものは計算式の少ない管理表だが、締めの中で使う集計表まで含めれば、この宿題は相当な量になる（決算データを散らさない集計設計、Excel手作業から段階的に移行する順序）。
だから、証跡の価値は速さの価値と分けて計算する。 速さでは元が取れなくても、Excelで統制を維持する手間と比べれば元が取れる範囲がある。ただし前提は一つで、仕組みの上の記録が実態と一致していることである。 二重管理が始まった瞬間に、仕組みの上の「済」は証跡ではなくなる。監査で見せている記録と、実際に締めを進めた記録が別物であることは、証跡がないことより悪い。
道具の前に直すもの
入れ替わり率を測ると、しばしば別のことが見えてくる。入れ替わっている行の多くが、実は毎期同じ作業の書き方の揺れだった、ということである。 同じ照合作業が、担当者によって「残高確認」「BS照合」「勘定明細チェック」と別の行で書かれている。これは事業の変動ではなく、工程表の粒度の問題である。
粒度を揃えると、入れ替わり率は下がる。一項目を一つの判断に割り、依存関係どおりに並べる（決算チェックリストの設計は網羅より順序と粒度、形骸化させない原則）。そのうえでクリティカルパスを引けば、仕組みに載せる前に、どこを並行化すれば締めが縮むかも分かる（決算スケジュール表の作り方、5日締めを支えるWBSとクリティカルパス）。
Jobのタスクとして流したい処理についても、先に確認がいる。 夜間バッチが失敗した朝に再実行できる処理とできない処理は、処理の種類ごとに違う。依存関係を仕組みに持たせても、失敗時の判断が決まっていなければ、後続は止まったまま待つだけになる（決算の夜間バッチが失敗した朝の対応手順、SAPのジョブ運用を経理が把握する）。
売上高860億円の化学品メーカー。国内3社・海外5社のグループで、月次の連結は第8営業日、親会社単体は第4営業日に締まっていた。 締めの工程表はExcelで、行数は親会社単体が132行、連結・開示が79行。情報システム部が締め管理の仕組みの導入を提案し、経理部長は判断を保留したうえで、過去12か月分の工程表の比較を課長に指示した。工程表は月ごとに別ファイルで保存されていたので、比較は二日で終わっている。 結果は、はっきり分かれた。親会社単体の工程表は、12か月の入れ替わり率の月平均が3パーセントで、入れ替わりの大半は年2回の人事異動に伴う担当者の変更だった。 連結・開示の工程表は、月平均で18パーセント。期中に子会社を1社取得し、別の1社を清算した年で、取り込みと除外の作業、監査法人から来た個別の確認事項が、ほぼ毎月追加されていた。 単体の132行をさらに三つに分けると、システム内で完結する処理が38行、画面での手作業が71行、システム外の待ちが23行だった。待ちの23行のうち17行は、事業部からの見積りの根拠資料だった。 経理部長が決めたのは三つである。一つ目は、親会社単体の締めだけを仕組みに載せること。 システム内の38行はJobのタスクとして定義し、前工程の完了を待って流す形にした。画面での手作業71行は、粒度を揃えた結果58行になった。二つ目は、連結・開示を載せないこと。 Excelの工程表に残し、担当の主任を工程表の保守責任者として業務分掌に書いた。三つ目は、単体のテンプレートの保守を課長代理の業務分掌に入れ、工程を追加するときは締めの開始前日までにテンプレートへ反映するという期限を置いたことである。 事業部からの見積り待ちの17行は、仕組みに載せず、見積りの提出期限を第2営業日に前倒しする社内ルールの改定で対応した。稼働から半年、親会社単体の締めは第4営業日から第3営業日になった。 締め会議は、単体については廃止し、連結・開示だけが週一回残っている。一日縮んだ内訳を課長が分解したところ、仕組みの効果よりも、見積り提出期限の前倒しの効果のほうが大きかった。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
締めのタスク管理で決めておく三つのこと
第一に、移すかどうかを、過去12か月の工程表の入れ替わり率で決める。 締め管理の仕組みの価値は、定義された依存関係と定義されたジョブから生まれ、その定義は工程が変わるたびに保守が要る。SAPの担当者の解説でも、タスクリストモデルへの更新は新しいタスクにしか反映されない一方、タスクグループのテンプレートへの更新は依存関係を含めて反映されると比較されており、どこを直せばどこまで届くかを理解した保守者が前提になる。 隣り合う月の工程表を比べ、行の追加・削除、担当者の変更、前後関係の変更を数える。入れ替わりの小さい工程を持つ会社には効き、事業の動きで工程が毎期変わる会社では、テンプレートの保守が追いつかずに二重管理が始まる。
第二に、工程を三つに分け、載せる範囲を切る。 システム内で完結する処理、システム画面での手作業、システム外の待ち。前の二つで入れ替わりの小さい範囲だけを載せ、システム外の待ちは中身を載せずに状態だけを持たせる。 待ちの時間は仕組みでは縮まず、提出期限の前倒しのような社内ルールでしか縮まない。全部を載せようとした瞬間に、非公式のExcelが仕組みの外に生まれる。
第三に、証跡の価値を速さとは別に計算し、テンプレートの保守者を定員で置く。 実施基準は決算・財務報告プロセスを慎重に運用状況の評価を行う対象とし、システム管理基準 追補版はスプレッドシート等の統制も評価対象とする。Excelで統制を維持する手間と比べれば元が取れる範囲がある。 ただし仕組みの上の記録が実態と一致していることが条件で、二重管理になった時点で証跡は証跡でなくなる。だから保守を導入担当者の個人作業にせず、業務分掌に担当と反映期限を書く。 オンプレミスのSAP Financial Closing cockpitを使っている会社は、互換性スコープの使用権の状態を先に確認する。一覧の表記は2025年12月31日だったが、SAPはオンプレミス版の互換性パッケージの大半について2026年5月末まで延長すると発表しており、その期限も過ぎている。 使用権が残っていない前提で判断の時期を置く。
