数値は固まった。試算表は締まり、監査法人にも出した。それなのに開示の作業が進まない。止まっているのは注記だ。リース取引の内訳を出すために契約書のファイルを引っ張り出し、担保に供している資産を探すために固定資産台帳と借入契約を突き合わせ、関連当事者かどうかを判定するために取引先の資本関係を調べ直す。数人が数日、書庫と共有フォルダを掘っている。この作業は、毎期ほぼ同じ形で繰り返される。にもかかわらず「決算後の追い込み」として処理され、仕組みの問題として扱われることが少ない。
遅れているのは集計ではなく、属性の欠落
決算後に注記で詰まる会社の共通点は、必要な情報の在り処が帳簿の外にあることだ。総勘定元帳を検索しても出てこない。契約書、稟議書、取引先マスタ、担当者の記憶に散っている。
具体的に見ると分かりやすい。リースなら、金額は帳簿にあるが、契約期間・解約可能性・延長オプションの有無は契約書にしかない。金融商品なら、残高は帳簿にあるが、担保提供の有無や返済期限の年度別内訳は借入契約書にしかない。関連当事者取引なら、取引額は帳簿にあるが、その相手が関連当事者に当たるかどうかの判定情報は帳簿の外だ。セグメント情報も同じ構造で、売上と費用の数字はあるが、それをどのセグメントに紐づけるかの属性が起票時に取られていなければ、後から按分で作るしかなくなる。
つまり、決算後にやっている作業の実体は「属性の後付け」である。後付けは、元の取引を知る人を探すところから始まるので時間がかかり、しかも精度が落ちる。ここを速くしようとして増員しても、構造は変わらない。
注記データを三つに分ける
前倒しの設計は、注記の項目を並べて「いつなら取れるか」で分類するところから始まる。
多くの会社が改善策として手を付けるのはAだ。勘定科目を細かくする、補助科目を足す。これは効くが、そもそもAは既に自動で出ている領域なので、伸びしろは大きくない。決算後の長時間作業を生んでいるのはBであり、Bは会計システムの設定を変えても出てこない。取引が発生する現場の業務フローに手を入れないと取れない。
入口で属性を取る三つの打ち手
Bを前倒しする方法は、突き詰めると「取引が動く瞬間に、注記で要る属性を必須項目として取る」という一点に集約される。実装は三つの層で行う。
三つのうち難所は三番目ではなく、二番目の「誰が入力するか」だ。経理が自部門の中だけで台帳を作ろうとすると、結局は契約書を読み込む作業が経理に残る。属性を最初から知っているのは契約を締結した事業部門や法務であり、その人たちの承認フローに一項目足すのが最も安い。逆に言えば、この一項目を足す交渉が通らなければ、注記の前倒しは進みにくい。ここはCFOが部門横断で判断する話で、経理部内の改善だけでは届かない。
ある上場会社では、有価証券報告書の注記作成に決算後の三週間が張り付いていた。工数の内訳を取ると、半分近くが「契約書の確認」に費やされていた。対策として、契約稟議のワークフローに三項目——契約期間、中途解約の可否、担保・保証の有無——を必須入力として追加した。経理側の作業は増えず、追加されたのは起案者の入力三行だ。次の期の注記作業では、契約書に当たる件数が持ち越し分だけに絞られた。仕組みを変えたというより、聞く相手とタイミングを変えただけだった。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
前倒しできないCは、日程で守る
期末時価、見積りの前提、後発事象。これらは期中に取ることが原理的にできない。ここを気合いで縮めようとすると、見積りの検討が浅くなり、監査での差し戻しという形で結局遅れる。
Cは前倒しできないので、日程の確保で対応する。締めの工程表の上で、Cの検討にかける日数をクリティカルパスとして先に確保しておく（決算スケジュール表の作り方、5日締めを支えるWBSとクリティカルパス）。BをAに寄せて工数を空け、空いた工数をCに充てる。これが注記全体の設計になる。子会社を含む連結の注記なら、同じ属性を回収パッケージ側の項目として設計する必要もある（連結パッケージの設計と回収）。属性を後から集める構造は、単体でも連結でも同じ形で現れる。
注記が決算後に詰まるのは、契約期間、担保の有無、相手先の資本関係といった属性が帳簿に載っておらず、後から探しているからだ。注記データを、帳簿から出る分、取引の入口でしか取れない分、期末にしか確定しない分に分け、二つ目を入口で取る形に変える。
手を付けやすいのは、契約稟議のフォームに契約期間・解約条件・担保の有無を必須項目として足すことだ。入力するのは経理ではなく、契約を結んだ部門である。期末にしか確定しない分は、工程表の上で日数を先に確保する。
