XBRL... 単なるコンプライアンス遵守にとどまらない、多岐にわたる可能性を秘めた技術

先日、パリで開催された第19回XBRL国際会議から帰ってきたばかりなのですが、多くの組織がXBRLの重要性を理解していないように感じ、その原因の一部は、アメリカ証券取引委員会（SEC）の関連規定にあるのかもしれません。世界最大の経済大国であるアメリカがXBRLの報告要件を導入してから1年後であれば、この会議には、自社の財務データをXBRLでどのように、そして何よりも_なぜ_XBRLでマークアップすべきかについて学びたいと熱心な企業の担当者がたくさん集まるだろうと私は思っていました（少なくとも、そう思っていました）。しかし、残念ながら、そのような状況ではありませんでした。

参加者数が少ないこと、特にアメリカからの参加者が少ないのは、おそらく、多くの組織がXBRLを依然としてコンプライアンスの問題として捉えており、財務諸表の「タグ付け」作業を依然として金融印刷会社やその他のEDGARへの提出代行業者に外部委託していることが原因だと推測されます。

つまり、XBRLはコンプライアンス（法令遵守）の問題なのでしょうか？もちろん、それは重要な要素ですが、それだけではありません。私はアルトバで働いており、弊社は単にコンプライアンス関連のソフトウェアに焦点を当てていません。弊社は、企業が業務効率を最大限に高めるためのツールを開発しています 内部の データ管理のプロセス全体にかかる時間とコストを削減することを念頭に置いています。そして、XBRLを利用している企業であれば、これは十分に実現可能です。しかし、そのためには、自社のデータ管理方法を積極的に見直す必要があります。

「タグ付け」とは、財務諸表を従来のようにスプレッドシートや会計ソフトで作成し、その後、XBRLのタグを遡って詳細に付与することで、法令遵守を実現するプロセスを指します。うーん… だからこそ、法令遵守という言葉がこんなにも耳障りな響きを持つのでしょう。私たちはもう十分な仕事に追われているのに、さらに手作業が増えるなんて… 人為的なミスが起こる可能性が二倍になるのではないでしょうか？この「タグ付け」という言葉が、XBRLの導入を説明する際にこれほどまでに普及したのはいつなのかは正確には分かりませんが、結果として、複雑さの少ないものを過度に単純化してしまっただけだと感じます（もちろん、この言葉はマーケティング部門の誰かによって作られた可能性が高いです。私自身もその一員です）。

いずれにせよ、今回は「タグ付け」というアイデアは一旦置いておき、もう少し大胆な方法を考えてみましょう。もし、御社のすべての財務データが、何らかのバックエンドのデータベース、会計/ERPシステム、XMLファイル、あるいはこれらの組み合わせといった形で保存されているとします。もし、それらを簡単にデータをXBRL形式にマッピングする外部のコンサルタントにレポートを詳細に分析させ、各項目にタグを付ける代わりに、社内でそれを行うことはできないでしょうか？さらに、もし次に同様の財務報告書を作成する際に、このマッピングを再利用できるとしたらどうでしょうか？そして、もし情報技術部門にそれらの作業を任せることもできるとしたら XBRL形式での提出プロセスを自動化します?

XBRLマッピング Altova MapForceは、企業レベルで使用できるデータ統合ツールであり、まさにその機能を実現します。開発者やアプリケーションの設計者は高度なレベルで利用しますが、使いやすいグラフィカルインターフェースにより、マッピングする必要があるデータに関する知識があれば、誰でもMapForceを利用できます。具体的な例を見て、どれほど簡単にできるかを示しましょう。最初のステップは、ソースデータコンポーネント（この場合はデータベース）をMapForceのデザイン領域に読み込むことです。

注意点として、マッピングコンポーネントはデータベース内のテーブルや列の表現であり、その基となるデータはいつでも変更される可能性があります。しかし、マッピング自体は影響を受けません。これは、MapForceで使用するあらゆるマッピング構造（XML、データベース、フラットファイル、EDI、Excel、XBRL、またはWebサービス）についても同様です。次に、今回のターゲットとなるマッピングコンポーネント、つまり、米国会計基準（GAAP） - 商業および工業を基にした基本的なXBRL拡張分類を追加します。

さて、ここからは、単純に項目同士を結びつけることでマッピングを開始できます。ただし、いくつかのケースでは、追加の処理が必要になる場合がありますデータ処理規則フォーマットをわずかに変更したり、データをフィルタリングしたり、データベースに存在しないXBRLレポートの要件に対応するための定数値を追加したりすることも可能です。これらの操作は、サイドバーにあるMapForceライブラリから必要な関数をドラッグ＆ドロップするだけで、非常に簡単に行えます。

例えば、データベースが会計期間を記録する際に、自動的に日時形式を要求するとします。XBRLレポートでは日付のみが必要なため、マッピング処理において時刻情報を取り除く必要があります。そのため、ライブラリから「日付を日時から抽出する」関数をドラッグし、データベースとXBRLコンポーネント間の接続線を結ぶだけで完了します。

もちろん、データに対しては、さまざまな種類の数学関数、論理関数、またはその他の関数を追加する必要があるでしょう。これらの関数は、すでに多くのものが関数ライブラリに用意されています。

必要に応じて、グラフィカルな関数エディタを使用して、カスタム関数を簡単に追加することもできます。最終的に、マッピングは以下のようになります

さあ、あとは「出力」タブをクリックして、XBRLデータがどのような形式で表示されるかを確認してください。これで完了です。この再利用可能で拡張可能なデータマッピングは、XBRLデータを送信する必要があるたびに利用できます。さらに、このマッピングインターフェースを別のアプリケーションに統合したり、IT部門にXBRLファイルの自動生成を行うコードを作成してもらうことも可能です。MapForceにおけるXBRLマッピングの詳細については、AltovaのXBRLチュートリアルをご覧ください。

さて、ここで非常に簡単な例として、会計システムから直接XBRLデータを生成する方法をご紹介します。情報の再入力は不要ですし、従来の財務諸表を作成する必要もありません。もちろん、「タグ付け」も不要です。そして何よりも素晴らしいのは、これらの作業を自社で行うことができ、そのコストは大幅に抑えられるということです。ただし、誤解しないでください。外部委託が貴社のXBRL導入において一定の役割を果たす可能性はあります。例えば、XBRL拡張分類体系の構築は、XBRLの構文やその他の複雑な要素に関する長年の経験を持つ専門家に任せる方が、より安心かもしれません。しかし、貴社の財務データをXBRL形式に変換する作業…それは、データそのものを最もよく理解している人たちに任せるべきではないでしょうか？

Altova MissionKitに関する詳細については、こちらをご覧ください XBRL関連のツール - これには、以下の機能が含まれます XBRLマッピングと自動化, XBRLによるデータ検証と分類体系の作成, そして XBRL形式のデータ表示 - ぜひご覧ください https://www.altova.com/solutions/xbrl-tools.html …または Altova MissionKitをダウンロードしてください本日！