2025年に取り組みたいこと　EDINETのXBRL解析の進捗について　その1

はじめに

「2025年はEDINETのXBRLから欲しいデータを収集するプログラムを作ります」と以下の記事で書いたので時間を見つけてはプログラムを作っています。

www.quwechan.com

少し形になってきたので現状を書いていきたいと思います。

出来るようになったこと

全ての会社ではないですがEDINETのXBRLから財務諸表データ等を取得できるようになりました。大体どんな感じでデータを収集できているかは以下にサンプルを掲載しています。

証券コード9810のデータ取得結果

やっていることは単純で財務諸表の木構造データから、売上はどれなのか、営業利益はどれなのかを探してまとめているだけです。

以下はXBRLから取得できる木構造データの一例ですが、名称から検索すればどれが売上なのか営業利益なのかはおおよそわかります。

(number)(営業利益又は営業損失（△）),20961000000
    (number)(売上総利益又は売上総損失（△）),94287000000
        (number)(売上高),1443843000000
        (number)(売上原価),1349555000000
    (number)(販売費及び一般管理費)[-1.0],73326000000

今のところ、勉強会でデータ収集の対象となっている会社についてXBRLのデータ収集をしているのですが、大体7割くらいの会社についてデータ取得できています。ただし

IFRSのデータ、研究開発費、設備投資費、株主属性ごとの株式保有状況は2019年以降しか取得できない
US GAAPのデータは取得できない
銀行の財務諸表は手が回っておらず対応できていない

などそもそも出来ないこと、対応できていないこともたくさんあります。

なのでこの出来ていない3割を埋めることが当面の課題だと認識しています。他にもいろいろあるのですが少しづつやっていこうかと思っています。

名寄の問題について

少し厄介なのが売上を表す名前がいっぱいあり、どれを売上として取得したらよいかわからなかったりすることです。最近読んだ記事でも同様の指摘がありました。この記事では営業利益近傍を適当な条件で探索するなど工夫されていました。

私の結論は「各会社のケースごとに個別対応する」となります。まぁ、皆さんの求めている結論ではないと思いますが、EDINETのXBRLは非常に自由度が高く、会社によって異なる構造(些末ではありますが)で財務諸表を提出できてしまいますのでどうしようもないのかなと思っています。

私は各項目ごとの計算関係に着目して(計算リンクベースのことではないです)、計算関係に矛盾がなければ正しく項目を取得できているという前提のもと処理を行っています。要するに取得した売上・原価・粗利益・販管費・営業利益はその計算関係をチェックして、矛盾がなければ正しいデータだと判定すればよいということです。

具体的に言うと、取得した売上・原価・粗利益に対して「売上 - 原価 = 粗利益」がなりなっていれば、この3つの項目は正しく取得できていると判断できます。ただ、これには続きがあり、追加で取得した販管費・営業利益に対して「粗利益 - 販管費 = 営業利益」がなりなっていなければ、取得したデータのどこかに誤りがあるということになります。売上や原価、粗利益は一つのPLに複数の項目が存在しているケースが多々あるので、粗利益までの計算結果で問題ないと誤判定してしまうことが良くあります(製品売上、製造原価、製造粗利益、建設売上、建設原価、建設粗利益といったケースが一例)。この計算チェックを当期純利益まで繰り返しても矛盾がないなら、さすがに正しく取得できているよねということです。

計算リンクベースのweight値について

上記の計算関係によってデータの健全性チェックを行う場合、weightの値はあらかじめ正の値に統一しておいた方が処理が楽です。

販管費や原価はほぼ間違いなく、weightが負で値が正になっています(weight -1.0、値が900のような形)。原価が粗利益の直下にある場合は粗利益の計算過程において値900をweightの-1.0をかけて使いなさいよという意味になります。また、原価という要素の子要素として期末在庫という要素があります。これもweightが負で値が正になっていますが、粗利益を計算する場合は直接の親である原価のweightも負であるため、負×負=正であるのでweight正で計算しなければなりません。つまり何が言いたいかといえば、計算対象となるベース要素までさかのぼってweightを積算しないと要素自体の値を正として使ったらよいのか負として使ったらよいのかわからないということです。

このweightについての処理をデータの健全性確認の際に行うと非常に厄介です。なのでデータ取得前に木構造のweight値が全て正になるようにしてしまったほうが良いです。後の処理が楽になります。

計算リンクベースを使ってデータ取得を行っていない人からしたら意味不明な話ですが、自分はこれで結構時間を無駄にしたのでここに書いておきました。
　