エストニアでは、日々の電子取引データを会計データとして標準化し、そのまま統計報告や税務報告に再利用する方向で、かなり先進的な取組が進められてきた。

その中核として 2021 年の公開資料で説明されているのが MyCompanyData Service（MCDS）であり、会計仕訳データの共通表現として XBRL GL 2015 ベースの標準が採用されている[4] [5] [8]。

一方で、「中小企業の日々の電子取引から記帳までを支援し、リアルタイムで監督官庁にデータが報告され、自動申告まで進んでいるのか」という点は、少し慎重に整理する必要がある。

2021 年の MCDS 文書はかなり大きな将来像を描いているが、2026 年時点の行政機関の公開ページから確認できる実運用は、主として Statistics Estonia（統計庁）向けの一部報告の自動送信であり、税務当局向けの transaction-based reporting はなお導入途上である[9] [10]。

本稿では、エストニアの公開資料に基づいて、MCDS と XBRL GL が何を目指したのか、どこまで実装されていたのか、そして現在どの程度まで実稼働しているのかを整理する[1] [2] [3]。

MCDS は、会計サービス事業者と政府当局のあいだで、経済取引データと報告データを交換するためのサーバソフトウェアとして定義されている。MCDS の仕様書には、会計仕訳データの受信、XBRL GL 構造検証、業務ルール検証、データベース格納、検証結果の返却、電子インボイス連携、報告ファイル生成、Statistics Estonia への送信、権限管理、分類表管理、イベントログ管理などが整理されている[4]。

つまり MCDS は、単なるファイル保管庫ではない。ERP や会計ソフトが送ってきた標準化済み会計データを受け取り、妥当性を確認し、必要に応じて公的報告ファイルを生成し、権限にもとづいて外部機関へ送信したり、外部機関に参照させたりする「中継・検証・配信」の層として設計されていた。

2021 年の仕様では、入力は XBRL GL XML であり、MCDS 側で XML 構造検証と業務ルール検証の二段階チェックを行う。さらに Statistics Estonia 向けには X-Road の estat.submitdata を用いた送信フローまで定義されていた[4] [7]。

エストニアの取組で重要なのは、電子インボイスと会計仕訳を別の世界として扱わなかった点である。

公開資料では、EN UBL 2.1 の電子インボイス項目を XBRL GL ベースの会計仕訳標準へ対応付けるマッピングが用意されており、電子取引データを会計記帳と報告に接続することが意図されていた[6] [8]。

会計仕訳データ標準そのものも、XBRL GL 2015 に準拠し、エストニアの会計システムと当局の双方で利用することを前提としている。文書ヘッダ、組織識別、元システム、対象システム、通貨、仕訳ヘッダ、仕訳明細、勘定科目、補助分類、金額、借貸区分、記帳日、取引相手識別などを持つ構成であり、分類子の追加によって統計報告や税務報告に必要な詳細を持たせる設計である[5]。

ここでの XBRL GL は、単なる総勘定元帳残高の交換形式ではない。むしろ、元文書、相手先、分類、補助属性まで含めた「標準化された取引・仕訳データ」の共通層として使われている。

2021 年の資料を素直に読むと、業務フローは次のように整理できる。

利用者ガイドでは、MCDS からの報告受信方式として pull と push の両方が説明され、Statistics Estonia については X-Road サービス estat.submitdata を使った push が記載されている[7] [4]。

また、電子インボイスについても、gl-bus:targetApplication に e-invoicing_operator を設定した会計仕訳として MCDS に送る構成が示されている。つまり、インボイスだけを別ルートで処理するのではなく、会計データの共通表現の中で扱おうとしていたことが分かる[7] [5]。

ここは期待をそのまま受け取らず、文書の書きぶりをそのまま読むのが重要である。

MCDS User Guide には、MCDS 1.0 で Statistics Estonia の salary and labour force report の transmission interface を開発済みとある一方で、「remaining public sector reports cannot yet be transmitted via the MCDS」と明記されている。つまり、2021 年時点で全面的な公的報告自動送信が完成していたわけではない[7]。

同じ 2021 年の Guidance and rules documentation では、5 社の会計ソフト事業者が XBRL GL の送受信に対応する更新を行い、新しい MCDS を構築したことが説明されている。そこでは BCS Itera、SimplBooks、Skriining、Account Studio、Columbus Eesti が挙げられている[8]。

ただし、この文書の表現は「developed」「updated」「allowed to build」であり、全国の中小企業が日常業務で全面利用しているという意味ではない。むしろ、かなり具体的な実装と実証が行われたが、対象は限定され、エコシステム全体としてはまだ発展途上だったと理解するのが妥当である。

結論から言えば、方向としてはかなり明確に実装されているが、全面完成ではない。

MCDS と XBRL GL の公開資料から確認できるのは、次の点である。

したがって、「エストニアでは既にすべての中小企業の取引データがリアルタイムで監督官庁に流れ、自動申告まで全面稼働している」と理解するのは言い過ぎである。

しかし、「取引データを XBRL GL ベースで標準化し、それを会計・統計・税務へ再利用する方向で、具体的な実装と一部本番運用が成立している先進事例」とみるのは十分妥当である[8] [9] [10]。

この事例の本質は、「提出用 CSV」や「個別様式の電子化」ではなく、日々の取引データそのものを標準化し、そのまま会計・報告・申告へ再利用する設計にある。

このとき重要なのは、単なる合計値ではなく、取引先、元文書、分類、勘定、補助属性まで持った詳細データを扱えることだが、その共通表現として XBRL GL を採用したことに、エストニアの特徴がある[5] [8]。

また、MCDS の構想は、技術標準だけでは自動報告は実現しないことも示している。必要なのは、分類表の統一、権限管理、送信先管理、行政機関側の受信基盤、ベンダー改修、エラー返却、確認フロー、法制度の整備である。MCDS は、これらをつなぐ middleware として設計されていた。

日本で同様の世界を考えるのであれば、電子インボイスだけでなく、受発注・出荷・支払を含む日々の取引データと会計データをどう標準化し、どのレイヤで行政報告に接続するのかが問われる。そのとき、XBRL GL を単なる帳簿交換フォーマットではなく、「標準化された granular data の共通層」として捉え直す視点が重要になる。

エストニアの MCDS と XBRL GL は、机上の構想だけではない。2021 年時点で、仕様、マッピング、利用者ガイド、分類表、統計庁向け送信方式まで整備され、一部の送信機能は実装されていた。さらに 2026 年時点では、Statistics Estonia 向けには一部報告の自動提出が実際に動いている[4] [7] [9]。

ただし、税務当局向けの transaction-based reporting と自動申告の全面展開は、なお進行中である。したがって、現状を一言で言えば次のようになる。