連結会計システムから取り込んだ数値が開示書類の該当箇所へ反映されない
連結会計システムとの連携設定や勘定科目のマッピングに不備があると、取り込んだ数値が開示書類の該当箇所へ反映されず、目視でしか検知できません。
GENZ, Inc.
第三者検証サービス
開示管理システムを
第三者検証サービス
開示管理システムを第三者の視点で検証します
開示書類の記載項目を起点にテスト設計を行ない、検証範囲を文書で明示します。決算日程に合わせ、リリース判断の材料となる報告まで伴走します。
支援事例
支援実績5,000件以上
開示管理システムでよくある不具合
開示管理システムの不具合は、連携からの取り込み、帳票への反映、本文と注記の整合、承認履歴と提出データの不整合という形で表面化します。ここでは、リリース前の検証で確認すべき不具合のパターンを整理します。
連結会
同じ項目の数値が本文と注記で不整合のまま出力される
本文と注記が別々のロジックで数値を生成している場合、片方だけが更新され、同じ項目の数値が不整合のまま出力されるおそれがあります。
勘定科目のマッピング変更後に前期比較の列の数値が入れ替わる
勘定科目のマッピングを変更したあと、前期比較の列が参照する期間の定義に不整合があると、当期と前期の数値が入れ替わったまま帳票へ出力されます。
承認前の版が提出データとして生成される
承認ワークフローと提出データの生成処理が連動していないと、承認前の版が提出データとして生成され、開示統制の説明にも支障が残ります。
単位の換算と端数処理で合計値が内訳の合計と一致しない
百万円・千円といった単位の換算や端数処理の基準が帳票ごとに統一されていないと、合計値が内訳の合計と一致せず、差異の切り分けに工数を取られます。
残存した不具合により生じる問題
検証の仕組みがないまま更改や制度改定を重ねると、残った不具合は提出期限の直前や提出後に表面化します。ここでは代表的な問題を整理します。
静的テスト（レビュー）でおさえるべき観点
実行前のレビューで検出できる誤りは、実行後に修正するより戻りが小さく済みます。開示管理システムでは、マッピング・帳票・参照関係・ワークフロー・連携の各領域を、仕様書同士と実績資料に照合して確認します。
マッピングの漏れを見逃すと、取込時に科目が欠落したまま計算へ進み、受け入れ段階まで検知できません。判明が遅れるほど修正がマッピング表・計算ロジック・帳票へ戻り、テスト設計への反映前に実装が進みます。
勘定科目と開示項目のマッピング定義をDB設計書の項目定義と照合する
連結会計システムの勘定科目と開示項目の対応表を、DB設計書の項目定義と照合します。科目の追加や集計範囲の変更が設計書へ反映されていないと、取込段階で値が欠落したまま帳票へ回ります。
確認する資料
- マッピング表
- DB設計書
- 勘定科目一覧
表示項目の漏れを見逃すと、前期の開示書類との突き合わせで個別の指摘として処理され、同種の誤りが他の箇所に残ります。担当者が同じレビューを版ごとに繰り返す形となり、経理の繁忙期と重なると判定そのものが後回しになります。
帳票テンプレートの表示項目を開示書類の記載要領と照合する
帳票テンプレートの表示項目・表示形式を、制度開示の記載要領と照合します。前期比較の列や注記番号の振り方に漏れがあると、受け入れ段階で担当者の目視に依存する修正が版ごとに繰り返されます。
確認する資料
- 帳票テンプレート
- 記載要領
- 前期開示書類
参照関係の不整合を見逃すと、本文と注記で同じ内容を指す数値が食い違ったまま提出されます。提出後に誤りが判明した場合は訂正報告書の提出が必要となり、訂正作業と監査対応が同じ担当者に重なります。
本文と注記の参照関係の定義を前期の開示書類の記載箇所と照合する
本文の数値と注記の内訳の参照関係の定義を、前期の開示書類の記載箇所と照合します。参照先の紐づけが実際の記載構造と異なると、本文と注記で同じ内容を指す数値が不整合のまま残る経路ができます。
確認する資料
- 参照関係定義書
- 前期開示書類
- 注記一覧
ワークフロー定義の不備を見逃すと、承認履歴が統制の要件を満たさず、内部統制監査で開示統制の運用状況を説明できません。リリース判断の根拠を部門として示す資料にもならず、判断が担当者の心証に依存します。
ワークフロー定義書を権限一覧と承認段階の要件と照合する
ワークフロー定義書の承認ルートと差し戻し条件を、権限一覧と承認段階の要件と照合します。承認履歴が統制の要件を満たす形で残るかを書面で確認しないと、内部統制監査で運用状況を説明できません。
確認する資料
- ワークフロー定義書
- 権限一覧
- 承認要件書
連携定義の齟齬を見逃すと、実データでの取込を回す初回決算で差異が表面化します。提出期限が動かせないため原因の切り分けを待たずに手作業での対応となり、システム化で見込んだ工数削減が初年度から実現しません。
連携仕様書をAPI定義と取込ファイルの項目定義と照合する
連携仕様書の項目・形式・受け渡しの条件を、API定義と取込ファイルの項目定義と照合します。定義間の齟齬は実行しないと検出できない不具合として残り、初回決算での差異の原因になります。
確認する資料
- 連携仕様書
- API定義
- 取込ファイル項目定義
- テスト用サンプルデータ
動的テストの設計・実行のポイント
動的テストは開示書類の記載単位と決算日程に沿って設計し、前期と同じ入力から同じ出力が得られるかを記録が残る形で検証します。
STEP 01
テスト設計記載要領に基づく観点を経理側と合意します。
どう確かめるか
開示書類の記載単位でテスト項目書を作成し、単位換算と期間の境界値を洗い出す
本文と注記の記載項目ごとにテスト項目書を作成し、千円・百万円の単位換算や期末日と期首残高の境界値を洗い出します。前期比較の列と注記の参照関係も項目に含めます。
- 01開示書類の記載単位でテスト項目書を作成する
- 02単位換算と期間の境界値を洗い出す
- 03前期比較と注記の参照関係を観点に含める
OUTPUTテスト項目書
STEP 02
ユニットテスト計算ロジックとマッピングを単位ごとに検証します。
どう確かめるか
取込処理と計算ロジックを検証し、例外時の挙動を確認する
連結会計システムからの取込データと勘定科目のマッピングを検証し、欠損や形式の不整合があるデータで例外時の挙動を確認します。原因が取込側か計算側かを切り分けられる記録を残します。
- 01取込データと勘定科目のマッピングを検証する
- 02計算ロジックの正しさを単位ごとに検証する
- 03欠損データを発生させて例外時の挙動を確認する
OUTPUT不具合票
STEP 03
統合テスト連携から承認までの流れを通しで検証します。
どう確かめるか
連携と承認フローを統合テストで検証する
他システムとの連携から帳票テンプレートへの反映、承認フローまでを統合テストで通し、権限ごとの操作と承認履歴の記録を検証します。差し戻し時の修正経路も確認します。
- 01連携から帳票反映までの流れを検証する
- 02権限ごとの操作と承認履歴を確認する
- 03差し戻し時の修正経路を確認する
OUTPUT検証結果報告書
STEP 04
システムテストと受け入れテスト前期と同じ入力での出力一致を確認します。
どう確かめるか
決算日程に沿ったテストと回帰確認
提出期限から逆算して検証期間を確保し、決算日程の中で実データによる出力を確認します。バージョン更新や帳票の小改定のたびに、回帰テストの範囲を根拠付きで決め直せる記録を残します。
- 01前期と同じ入力で同じ出力になるか確認する
- 02本文と注記の数値整合を点検する
- 03検証範囲の記録をリリース判断の根拠にする
OUTPUT回帰テスト範囲の記録
GENZが代行する開示管理システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 本文・注記・前期比較の記載単位でテスト項目書を作成します
- 委託範囲と社内担当範囲を切り分けて提示します
- 決算日程に合わせたテスト計画で進行します
- 検証範囲を記録として残し、回帰テストの基準にできます
開示日程を止めない第三者検証
開示日程は提出期限が動かせない前提で組まれます。検証範囲をどう設計し、どこまでを社内で担うかを決められなければ、リリース判断の材料が揃いません。GENZは開示書類の記載項目を起点にテストを設計します。
開示書類の記載項目からテスト設計へ
本文と注記の整合、前期比較、注記間の参照という記載の単位でテスト項目書を作成します。開示書類として何が正しいかを基準に設計します。
収集から提出データ生成まで検証
財務データの取込から帳票への反映、提出データの生成までを検証範囲に含めます。非財務情報の収集と承認履歴も同じ枠組みで検証します。
既存の体制に合わせて伴走します
ベンダーのテスト範囲と受け入れテストの範囲を切り分け、委託する工程と社内に残す工程の線引きを提示します。体制に合わせて伴走します。
検証範囲と不具合を報告書で納品します
テスト項目書、不具合票、検証範囲を示す報告書を納品します。検証した範囲と未検証の範囲を文書で示すため、稟議や監査の説明に使えます。
ご相談から納品までの流れ
委託範囲が未確定な段階からご相談いただけます。検証範囲の線引きから納品まで、次の流れで進めます。
開示業務と検証範囲のヒアリング
開示書類の作成手順と、社内で確認済みの範囲・未確認の範囲を伺います。
テスト設計と見積もりの提示
開示書類の記載項目を起点にテスト項目を設計し、委託範囲と見積もりを示します。
テストの実施と進捗の共有
テストを実施し、進捗と不具合票の消化状況を共有します。
報告書の納品と再テストの確認
検証範囲と未検証の範囲を報告書にまとめ、修正箇所の再テストを行ないます。
検証範囲のご相談を承ります
開示管理システムの検証範囲と優先順位をGENZへご相談ください
開示書類の記載項目を起点にテスト設計を行ない、委託する範囲と社内で担う範囲を整理します。検証範囲と優先順位、必要工数の考え方を、稟議やリリース判断に使える形でお示しします。