注記情報の収集設計：開示に必要なデータを期中から取りに行く仕組み

数値は固まった。試算表は締まり、監査法人にも出した。それなのに開示の作業が進まない。止まっているのは注記だ。リース取引の内訳を出すために契約書のファイルを引っ張り出し、担保に供している資産を探すために固定資産台帳と借入契約を突き合わせ、関連当事者かどうかを判定するために取引先の資本関係を調べ直す。数人が数日、書庫と共有フォルダを掘っている。この作業は、毎期ほぼ同じ形で繰り返される。にもかかわらず「決算後の追い込み」として処理され、仕組みの問題として扱われることが少ない。

遅れているのは集計ではなく、属性の欠落

決算後に注記で詰まる会社の共通点は、必要な情報の在り処が帳簿の外にあることだ。総勘定元帳を検索しても出てこない。契約書、稟議書、取引先マスタ、担当者の記憶に散っている。

具体的に見ると分かりやすい。リースなら、金額は帳簿にあるが、契約期間・解約可能性・延長オプションの有無は契約書にしかない。金融商品なら、残高は帳簿にあるが、担保提供の有無や返済期限の年度別内訳は借入契約書にしかない。関連当事者取引なら、取引額は帳簿にあるが、その相手が関連当事者に当たるかどうかの判定情報は帳簿の外だ。セグメント情報も同じ構造で、売上と費用の数字はあるが、それをどのセグメントに紐づけるかの属性が起票時に取られていなければ、後から按分で作るしかなくなる。

つまり、決算後にやっている作業の実体は「集計」ではなく「属性の後付け」だ。後付けは、元の取引を知る人を探すところから始まるので時間がかかり、しかも精度が落ちる。ここを速くしようとして増員しても、構造は変わらない。

注記データを三つに分ける

前倒しの設計は、注記の項目を並べて「いつなら取れるか」で分類するところから始まる。

多くの会社が改善策として手を付けるのはAだ。勘定科目を細かくする、補助科目を足す。これは効くが、そもそもAは既に自動で出ている領域なので、伸びしろは大きくない。決算後の徹夜を生んでいるのはBであり、Bは会計システムの設定をいじっても出てこない。取引が発生する現場の業務フローに手を入れないと取れない。

入口で属性を取る三つの打ち手

Bを前倒しする方法は、突き詰めると「取引が動く瞬間に、注記で要る属性を必須項目として取る」という一点に集約される。実装は三つの層で行う。

三つのうち難所は三番目ではなく、二番目の「誰が入力するか」だ。経理が自部門の中だけで台帳を作ろうとすると、結局は契約書を読み込む作業が経理に残る。属性を最初から知っているのは契約を締結した事業部門や法務であり、その人たちの承認フローに一項目足すのが最も安い。逆に言えば、この一項目を足す交渉が通らない限り、注記の前倒しは実現しない。ここはCFOが横串で決める話で、経理部内の改善では届かない。

前倒しできないCは、日程で守る

期末時価、見積りの前提、後発事象。これらは期中に取ることが原理的にできない。ここを気合いで縮めようとすると、見積りの検討が浅くなり、監査での差し戻しという形で結局遅れる。

Cについては、前倒しではなく日程の確保が正解だ。締めの工程表の上で、Cの検討にかける日数をクリティカルパスとして先に確保しておく（決算スケジュール表の作り方：5日締めを支えるWBSとクリティカルパス）。BをAに寄せて工数を空け、空いた工数をCに回す。これが注記全体の設計になる。子会社を含む連結の注記なら、同じ属性を回収パッケージ側の項目として設計する必要もある（連結パッケージの設計と回収）。属性を後から集める構造は、単体でも連結でも同じ形で現れる。

関連記事

• 有価証券報告書の作成体制：開示府令対応と社内データ集約の分業設計
• 決算短信の作成プロセス：開示45日ルールから逆算する制作スケジュール
• 決算スケジュール表の作り方：5日締めを支えるWBSとクリティカルパス
• 連結パッケージの設計と回収：子会社からのデータ収集を遅らせない運用