最新のレポートマニュアルのキーアップデートと今後のレポートシーズンへの影響。
欧州証券市場庁（ESMA）は最近、報告マニュアルを更新し、今後の報告シーズンに影響するいくつかの変更を導入しました。これらのアップデートの概要については、ESMA の公式ウェブサイト をご覧ください。ただし、これらの変更がお客様のレポートプロセスに具体的にどのような影響を与えるかを理解しやすくするため、ParsePort は最も関連性の高いトピックに焦点を当てることにしました。
本記事では、これらのキーとなるアップデートを分析し、現在のアプローチや実務と比較します。私たちの目標は、次回の報告シーズンにおけるレポートへの影響について、クリアで包括的な理解を提供することです。
ガイダンス1.2.2：ESEFタクソノミにまだ含まれていない、IFRSタクソノミで利用可能な要素の使用。
"ESMAは、発行者はIFRSタクソノミが発行者レポートの開示に対応する要素を含み、それがESEFタクソノミに存在しないかどうかを判断すべきであると提案しています。発行者は、IFRSタクソノミの要素の名称、ラベル、XBRL特性に対応する拡張タクソノミ要素を定義する必要があります。"
タクソノミ要素「使用権資産を含む有形固定資産」は、ESEFに関するRTSの2024年改正が2025年1月1日以降に開始する会計年度に強制適用されるまでの間、IFRSタクソノミの2023年改正の要素を自主的に利用できる例として選択されています。
ParsePort では、タクソノミーの構文と構成を遵守することをお約束します。このアプローチにより、タクソノミの更新時に拡張機能を標準要素にシームレスに置換することができ、お客様のファイルの比較可能性を維持することができます。
タグ付けのニーズにParsePortをお選びいただくことで、これらのアップデートを簡単に実装することができます。標準要素を含む新規タクソノミが更新されれば、移行は指を鳴らすようにスムーズです。
私たちの目標は、お客様のレポートプロセスを可能な限り効率的かつコンプライアンス的にし、常に最新の基準や規制に対応できるようにすることです。
ガイダンス 1.4.1： より広いスコープまたは意味を持つESEFタクソノミの要素への拡張要素のアンカー
"さらに、ESMAは、発行者の拡張要素のアンカー関係の質と使いやすさを向上させるために、発行者は拡張要素を同じデータタイプを共有するESEFコアタクソノミ要素にアンカーすべきであると考えています。例えば、発行者が monetaryItemType の拡張機能を作成した場合、その要素は対応する ESEF のコアタクソノミ要素 monetaryItemType にのみタグ付けされるべきです（stringItemType などにはタグ付けされるべきではありません）。"
ParsePort では、タクソノミ拡張機能のベストプラクティスに長年取り組んでおり、レポートの正確性とコンプライアンスを確保しています。当たり前のことのように思われるかもしれませんが、レポートで使用される拡張機能は、そのアンカー要素（より広いアンカー）の特性を「模倣」することが極めて重要です。
拡張機能はコアタクソノミが対処できない「ギャップを埋める」メカニズムとして機能します。しかし、拡張タクソノミーの基本原則は、最も近い利用可能な意味にアンカーを付けるように指示しています。つまり、拡張機能とアンカーは、特にデータ・タイプに関して整列する必要があります。
これらのベストプラクティスに従うことで、タクソノミが進化しても、レポートの整合性と比較可能性を維持することができます。ParsePort では、これらの原則を遵守することで、お客様のレポートプロセスがシームレスで最新の標準に準拠したままであることを保証します。
ガイダンス2.2.5:ダッシュ又は空欄のタグ付け
"IFRS連結プライマリ財務諸表に含まれるデータの分析と比較を容易にするため、ESMAは発行者が財務諸表に空欄やダッシュ記号をマークアップする際に、以下のガイダンスを考慮することを推奨します。"
財務諸表でゼロ、ダッシュ、空白のいずれを使用するかについては、しばしば議論があります。ParsePort では、すべての計算書（損益計算書、包括利益計算書、貸借区分表、キャッシュフロー計算書）にゼロ値をタグ付けすることを推奨しています。例えば、報告期間1が200と表示されている場合、報告期間2には空白はなく、ゼロかダッシュのどちらかが表示されるべきです。
資本変動計算書(SOCIE)については、両テーブルの項目が同じかどうかにより、例外が適用される場合があります。一般的な経験則として、ダッシュはゼロとしてタグ付けすることをお勧めします。
これらのガイドラインに従うことで、財務諸表の一貫性と明瞭性を維持し、読みやすく、解釈しやすくすることができます。
ガイダンス 2.2.7：ブロックタグの技術的な構成
「dtr-types:textBlockItemType のデータ型を持つファクトについては、XBRL International Working Group 2023年4月19日に更新されたメモに沿って、発行者はiXBRLの@escape属性を常に "true "に設定し、ファクトの値がXHTMLとして有効であるようにしなければなりません。一方、xbrli:stringItemTypeのような他のデータ型を持つファクトは、その値がXHTML を含まないことが予想されるため、代わりに@escape属性を「false」に設定しなければなりません。"
ParsePortプラットフォームは、新規ESMAガイダンス2.2.7に従って構成済みです。ESMAは、XBRLのベストプラクティスに準拠することの重要性を強調しています。
この更新により、プロセスが大幅に簡素化されます。現在、すべてのBlockItemType要素（すべてのテキストブロック）は、テキストが"<"や"&"などの特定の記号を含むかどうかに関係なく、常にエスケープされます。これにより、すべてのレポートにおける一貫性とコンプライアンスが確保され、よりスムーズで信頼性の高いレポート機能が実現します。
ParsePortでは、最新の規制基準やベストプラクティスとの整列に継続的に努めており、当社のプラットフォームがXBRLレポートの最前線であり続けることを保証しています。
ガイダンス2.6.1:インラインXBRLドキュメントをレポートに含める場合
「ESMAは、発行者がXBRL Internationalが更新したレポートパッケージ1.0仕様に従ってESEFの提出書類を作成することを推奨します。この仕様では、インラインXBRLドキュメントをどのようにレポートパッケージに含めるかが示されています。さらにESMAは、ソフトウェア会社が上記仕様に準拠しない場合、公式仕様エラーコードを発行者にプレゼンテーションすることを保証することを推奨します。"
上記の推奨事項の実施とレポートパッケージ1.0仕様の採用に伴い、抽出されるファイルの書式設定が変更されます。今後のレポートシーズンでは、前へ.zip形式を置換し、新規.xbri形式でParsePortプラットフォームからレポートパッケージを抽出することができるようになります。
この移行はシステム内で自動的に行われますので、ご安心ください。次レポートシーズンへのスムーズな準備のため、入力ファイルを最新バージョンに更新してください。更新が完了したら、ファイルをシームレスに変換する準備が整います！
ガイダンス 2.6.3:レポートパッケージおよびレポートファイルの名称規定
マニュアル 「ファイル名の{version} コンポーネントは、関連当局に提出されたESEFレポートパッケージのバージョンを示す必要があります。具体的には、{date} (ハイフン-マイナス文字で区切られています) の後に別の数字が追加されます。この桁は、ハイフン-マイナス文字の後に 1 文字の数字に限定され、提出物のバージョンを表します（つまり、初回提出の場合は常に 0 とし、次へ同じパッケージを再提出するたびに 1 ずつ増やす必要があります）。"
例：12345NOTVALID1234503-2023-12-31-0-en（初回提出）。
覚えておいてください：OAMまたは国内所轄庁が、国レベルで必要とされる異なる名称規則を提示する場合、発行者はそのような国内名称規則に従わなければなりません。
ESMAは、拡張タクソノミーの計算リンクベースの評価に起因する計算の不整合は、タグ付けの問題を示唆する可能性があるため、慎重に検討することを推奨します。エンジンは、既に提出されたバージョンの数を予測できないことを考慮し、入力ファイル（Excelテンプレート）には、異なるバージョンの場合に上書きされるカウンタを調整するオプションが用意されます。
ガイダンス 3.4.1：計算リンクベースにおける計算関係の説明書
「ESMAは、拡張タクソノミの計算リンクベースの評価から生じる計算の不整合は、タグの問題を指摘する可能性があるため、注意深くレビューすることを推奨します。計算の矛盾の中には、計算 1.1 を適用しても回避できないものがあります。特に、計算 1.1 は、ファクト設定が不完全な場合に、依然として誤検出を引き起こす可能性があります。これは、計算のトリガーとなるファクトは十分にあるが、それを完全にチェックするには十分でない場合に発生します。このような、ファクト設定が不完全であるために生じうる計算上の不整合の一例を、以下にプレゼンテーションします：架空の発行者の拡張機能タクソノミには、包括利益計算書に以下の計算が含まれています：包括利益＝利益（損失）＋その他の包括利益 同じ発行者の拡張タクソノミにおいて、発行者は持分変動計算書に「包括利益」と「利益（損失）」という要素を使用しています。発行者は、「その他の包括利益」という要素の代わりに、2つの新規要素（「損益に振り替えられるその他の包括利益」及び「損益に振り替えられないその他の包括利益」）を使用することを選択します。この場合、包括利益計算書で定義された計算は、株主資本等変動計算書でも評価されますが、「包括利益」と「利益（損失）」の要素の値しか含むことができず、省略された「その他の包括利益」の要素の値は0になります。計算の不一致にフラグが立てられても、ESEFインラインXBRLレポートが正しくないという意味ではありません。包括利益計算書で定義された計算が持分変動計算書にも適用され、計算のトリガーとなるファクト（「包括利益」及び「利益（損失）」）は十分に存在しますが、「その他の包括利益」というファクトが欠落しているため、完全にチェックするには不十分です。
ESMAマニュアルの最新版では、計算の不整合に関する情報を拡充し、これまでに観察された最も一般的な問題について詳しく説明しています。具体的には、計算1.1を参照し、このような不整合は、誤った計算からではなく、異なる計算書で使用される要素の選択から生じることが多いことを強調しています。
提供された例では、持分変動計算書（SOCIE）で使用されているその他の包括利益（OCI）の構成要素はどちらもOCI全体を正確に表しているため、会計処理は正しい。しかし、XBRLの観点からは、プレゼンテーションの不一致があっても、ノンブロッキングとみなされます。
今回のガイダンスの拡充により、これらの不整合の性質が明確になり、会計精度とXBRLコンプライアンスの両方を確保するための慎重な要素選択の重要性が強調されました。ParsePortでは、このような複雑な問題を解決し、正確でコンプライアンスに準拠したレポートを作成するためのヘルプを提供しています。
詳しくはをご覧ください。
Guidance 4.1.5:スタンドアロン XHTML ドキュメントの名称規定
Guidance 2.6.3 の調整に沿った新規ガイダンス。ファイルの名称に関する推奨は、xHTML ファイル（スタンドアロン、個人）にも適用され、 ParsePort Platform からダウンロードしたファイルの名称を変更する必要があることを意味します。
ガイダンス3.4.8（新規）：プレゼンテーション・リンクベースにおける算術関係のドキュメント
「プライマリ財務諸表の中には、計算リンクベースに反映させることができない、期間をまたがる算術関係を多く含むものがあります。期間をまたがる算術関係の例としては、キャッシュ・フロー計算書があり、この計算書では、期間中の流入と流出の貸借区分が、期首から期末までの現金残高の増減に対応します。もう一つの例は、資本の各構成要素について、期首と期末の帳簿価額の調整を含む資本変動計算書です。計算リンクベースは、このような期間横断的な関係についてのデータ品質チェックを効果的に定義するために使用することはできないため、プレゼンテーションリンクベースは、少なくとも半自動化された検証の実行を可能にする、このような期間横断的、ディメンション横断的な算術的従属性をドキュメント化するために使用されなければなりません。"
ESMAマニュアルの新規バージョンでは、ガイダンス3.4.1から派生したガイダンスが更新され、特定の時間をカバーするレポートのセクションに計算期間を定義するアブストラクトを含めることが推奨されています（強制ではありません）。これは特に、期間の開始と終了にまたがり、計算リンクベースで表現できない資本変動計算書に関連します。この勧告を実施することで、特に監査人から依頼された場合、関連する問題を解決するヘルプとなります。
ESMAレポーティングマニュアルのその他のガイドラインのうち、軽微な変更に伴い更新・調整されたもののリストを以下に掲載しています。
ガイダンス 1.1.2：複数の言語による AFR のプレゼンテーション
ガイダンス 2.1.2：インライン XBRL 文書における期間要素の書式設定
ガイダンス 2.2.6：ブロックタグから抽出された情報の可読性
ガイダンス 2.6.2：レポートパッケージに複数 html インライン XBRL ドキュメントおよび複数インライン XBRL ドキュメント設定を含む場合。
ガイダンス 3.1.3：タクソノミパッケージ
ガイダンス 3.2.2：拡張コンセプトに使用するデータタイプ
ガイダンス 3.3.1：拡張タクソノミ要素のアンカーと ESEF タクソノミの要素との関係
ガイダンス 2.2.8 (新規)：ファクトでのID属性の使用