2019年3月期の有価証券報告書の開示から税効果の注記内容が拡大されている。
そこで、開示の実態を知るべく、上場会社の有価証券報告書を分析してみた。
内容については、週刊経営財務3426号（9月30日）に特集として掲載された。
ここではその記事の中に書けなかったことで、特に今後の開示の発展を目指す上で重要なXBRLに関する気づきを残しておきたい。
XBRLとは
XBRLは財務データをコンピュータ上で統一的に扱えるように規格された言語で、簡単に言えば、金額などの財務情報にタグをつけることによって、その項目が「会社、年度、財務表の種類、科目、金額単位」などを定義できるようにしたものだ。
XYZ株式会社
令和元年XX月末日
貸借対照表
（単位:百万円）
現金及び預金 105
という開示があったとしても、それ自体コンピュータにとっては文字の羅列であり、羅列から意味ある区切りをつけるのは人間の役割になる。みなが統一的に文字を並べてくれれば、プログラムを書いたら変換は簡単だが、規格がなければ様式にはばらつきが出てしまうことになり、最悪の場合、人が目で見ながら再入力することを強いられる。それをタグ付けによって
＜タグ＞105＜/タグ＞
という形で表現してタグ単位で数字を取り出せるようにしてある。
数値を時系列や会社間の横並びで比較するには、便利にはなった。
XBRLの課題
しかし、有報の開示情報を利用する立場になって考えれば、まだまだ改善の余地がある。
今回の分析作業は、会計士3名とデータサイエンティストなど数名が一緒に作業をしたが、これを通じて、
- APIが必要最低限の機能しか備えていない
- データの完全性が担保できない
- タクソノミの体系がわかりづらい
- テキストデータが扱いづらい
- 全ての財務情報がカバーされていない
などの課題を認識した。以下順に書いていく。
1. APIが必要最低限の機能しか備えていない
EDINETは、2019年3月にAPIが整備されたことによってデータを一括でダウンロードできるようになった。
従来は、会社名や項目などの条件を入力して検索して該当項目をダウンロードするか、対象会社のXBRLデータを画面で指定してダウンロードする仕様だったため、人が介在せざるを得なかった。新仕様は、文書番号を指定することで一括して該当文書を入手できる。
但し、あくまでも「文書」を入手するという考え方に立っているため、提出文書番号一覧を一旦取得してから必要な文書の番号を選択してAPIに渡すという作業は残る。EDINETには数多ある提出書類の中から有価証券報告書を選択して、ファンドを除く上場会社分、訂正分、会計基準などを区分けしながらデータを特定していく作業はそれなりに大変である。
それ以上に、ダウンロードが文書単位でしかできないのが不便この上なく、今回のように税効果の項目が欲しい場合であっても全文書を一旦は手元に落とすしかない。例えば、該当する項目が含まれる有報を取り出したくとも、それは現API仕様では不可能だ。
2. データの完全性が担保できない
APIの考え方は、提出された文書の中からユーザが任意に選択したものをダウンロードするというものなので、ユーザが真に欲しいデータが揃っているかどうか確認するすべがない。つまり、有価証券報告書を提出すべき会社は法定されているが、実際に何社あってどの会社がまだ提出していないかということは、提出期限の延長申請などの情報を別途見なければならない。今回は東証の上場企業一覧と照合することにしたが、これは開示すべき会社を予め法で決めることはできないということなのかもしれないが、何とかならないものだろうか。
3. タクソノミの体系がわかりづらい
EDINETのタクソノミは、数値データが中心の財務諸表部分とテキストデータが中心の開示府令の部分に大きく分かれている。
財務諸表は、連結と単体とが統一的に扱われているものの、業種別にもタクソノミがあり、通常は業種固有の会計基準は個別財務諸表であるが連結でもそれを援用することから余計に混乱するのである。
今回、税効果の科目には同じ繰延税金資産でも、銀行業は別のタクソノミが割り当てられていることを知った。
さらには、会計基準のタクソノミも、日本基準以外に国際的基準とがあるが、IFRS以外はタクソノミが存在しないこともわかった。つまり比較的大規模な米国市場の上場会社は有報ではなくSECのEDGARからタグ付き情報を入手するしか方法がないのである。
4. テキストデータが扱いづらい
コーポレートガバナンスの強化に関する一連の施策を受けて、いわゆるMD&Aに関する有報の開示項目も変更ないし拡大されている。
当然にテキストによる説明が中心で、その中に財務情報や図表が含まれることになるが、財務情報は文字情報でしかなくまた図表はパターンでしかないので、本来一番重要な部分がコンピュータで扱いにくいのである。せめて財務情報部分は関連するタグにリンクをつけるとか、図表についてはテーブルデータを提供するとかSVGで記載するなどの取扱をしてもらいたい。
税効果の注記に関して言えば、「税効果会計に係る事項」という開示項目が一つのタクソノミで全て括られているため、内容は全てテキスト情報である。税効果会計は他の開示に比べるとテキストよりも表が中心であり、「繰延税金資産の主な内訳」（評価性引当額の内容を含む）「法定実効税率と税負担率の乖離」「繰越欠損金の期限別解消計画」などの重要な情報が、各社が（見た目は似ているが）HTMLの様式もバラバラに作られているため、これを取り扱えるデータに変換することに最大の時間を要した。
5. 全ての財務情報がカバーされていない
上記4とも関わるが、繰越欠損金の額は税効果会計のみならず財政状態を分析する上でも重要な情報であり、（ゆえに今回開示項目として追加されたわけだが）、XBRLタクソノミが定義されていないのは、片手落ちと言わざるを得ない。投資家は特定の会社を採り上げて有価証券報告書から目で数字を追いかけるのは数社が限界であろう。ましてポートフォリオを組んでいる会社になれば無理と言わざるを得ないため、結局は有報をダウンロードして人が目で数字を広い別のデータを作成するという作業が強いられる。
XBRL利用者の立場から
現在、コーポレートガバナンスの強化策の中で株主との対話という点が強調され、株主総会前に有価証券報告書を閲覧できるようにするということが議論されている。そのため、株主総会の日程を後ろ倒しにして株主がじっくりと有報を見る時間を確保しつつ、総会前に有報を提出するということらしい。作成者側にとっては、事業報告書・計算書類の作成送付という作業と有価証券報告書作成とが一回で済むので負担が軽減されるという言い方もされているが、今ひとつ盛り上がりを欠いている。
それは、利用者が本当に有報を利用できるようにするためには、人が一冊の有価証券報告書を目で見るという既成概念を捨て去り、もともとデータとして分析等がなされ、その後に個々に必要なところを人が見るという発想を取るべき時が来ている。その際に、どこまでがデータとして分析され、どこからが人によるのかは、定めるのではなく技術の進歩によって検討し続けられるという柔軟な考えも必要である。
新しい有価証券報告の形へ
さらには、「一冊の書類」という発想から抜ければ、有報の開示内容も「同時に」出さなければならないものは少ないことが分かる。
つまりそれぞれ法定の開示項目を随時開示していきながら、市場に出される情報を最新なものにしていくという考えに立てばよい。
有報は開示情報のポータルとして位置づけ、ポータルを見ればどの情報がどういうステータスにあるのかや、どれが新たに加わったり変更されたりした情報なのかがリアルタイムに分かるようになる。このような考え方に立てば、現下の有価証券報告書は投資家との対話のボトルネックになっているわけであり、単に総会の日付や提出日付を議論するだけでは対話の促進は期待したほど成果を上げないだろう。すなわち、「有価証券報告書」から統合報告などと共に新しく「有価証券報告方式」へと脱皮するタイミングなのである。
