三分一技術士事務所

説明条項：
(3) 相互運用できない規格が多数存在するため、加盟国全体で電子請求書を使用する経済運営者にとって、過度の複雑さ、法的な不確実性、および追加の運用コストが発生します。

国境を越えた調達活動を行いたい経済運営者は、多くの場合、新しい市場にアクセスするたびに、新しい電子請求書標準に準拠する必要があります。

電子請求書は、経済運営者が国境を越えた調達活動を行うことを思いとどまらせるため、電子請求書に関するさまざまな法的および技術的要件は、国境を越えた公共調達における市場アクセスの障壁となり、貿易の障害となります。

それらは基本的な自由を妨害し、内部市場の機能に直接影響を与えます。

(4) EU域内貿易に対するこれらの障害は、相互運用性のない国家および独自の標準が開発され、公共調達における電子請求書の使用がより広範になるか加盟国で義務化されるにつれて、将来的に増加する可能性があります。

(5) 電子請求書に関するいくつかの法的要件と技術標準の共存、および相互運用性の欠如に起因する国境を越えた貿易への障害は、除去または削減されるべきです。

その目的を達成するために、電子請求書のコア要素のセマンティック データ モデル（コアインボイスモデル）に関する共通の欧州規格 (「電子請求書に関する欧州規格」) を開発する必要があります。

規格は、電子請求書が常に含まなければならないコア要素を設定および説明する必要があります。

これにより、異なる技術標準に基づくシステム間での電子請求書の送受信が容易になります。

この欧州規格と矛盾しない限り、既存の国家技術規格は、この規格によって置き換えられたり、その使用が制限されたりしてはならず、欧州規格と並行して適用し続けることが可能である必要があります。

(7) 請求書の生成、送信、送信、受信、および処理を完全に自動化できる場合、電子請求書の利点が最大化されます。

このため、電子請求に関する欧州規格に準拠していると見なされるのは、受信者が自動的かつデジタル的に処理できる機械可読請求書のみです。この指令の目的上、単なる画像ファイルを電子請求書と見なすべきではありません。

(8) 相互運用性の目標は、テクノロジ、アプリケーション、またはプラットフォームに関係なく、ビジネス システム間で一貫した方法で情報の表示と処理を可能にすることです。

完全な相互運用性には、請求書の内容 (セマンティクス)、使用される形式または言語 (構文)、および送信方法という3つの異なるレベルで相互運用する機能が含まれます。

セマンティックな相互運用性は、電子請求書に一定量の必要な情報が含まれていること、および交換された情報の正確な意味が保持され、物理的に表現または送信される方法とは関係なく、明確な方法で理解されることを意味します。

構文の相互運用性とは、電子請求書のデータ要素が、送信者と受信者の間で直接交換して自動的に処理できる形式で提示されることを意味します。

構文の相互運用性は、共通の構文を使用するか、異なる構文間のマッピングを使用するという2つの方法のいずれかで確保できます。

第6条
電子請求書のコア要素
電子請求書の主要な要素は、次のとおりです。
(a) プロセスおよび請求書の識別子
(b) 請求期間
(c) 売り手情報
(d) 買い手情報
(e) 支払先情報
(f) 売り手税務代理人情報
(g) 契約種類への参照情報
(h) 納品の詳細情報
(i) 支払い指示情報
(j) 返金または追加請求に関する情報
(k) 請求明細情報
(l) 請求合計金額
(m) 付加価値税の内訳

Required syntaxes
The information defined in the semantic data model of the eInvoicing standard, documented in the eInvoicing standard, must be carried in an electronic message that may be transferred from one computer to another. The semantic eInvoicing standard does not define the structure of the electronic message. The message structure is called syntax.

必要とする構文
「電子請求書（eInvoicing）」標準で文書化された「電子請求書（eInvoicing）」標準のセマンティック データ モデルで定義された情報は、あるコンピュータから別のコンピュータに転送できる電子メッセージで伝送する必要があります。 セマンティック 「電子請求書（eInvoicing）」標準では、電子メッセージの構造は定義されていません。 メッセージ構造は構文と呼ばれます。

第2条
定義
この指令の目的のために、次の定義が適用されるものとします。
(1)「電子請求書」とは、自動および電子処理を可能にする構造化された電子形式で発行、送信、および受信された請求書を意味します。
(2)「電子請求書のコア要素」とは、法的コンプライアンスを確保するために必要な情報を含む、国境を越えた相互運用性を可能にするために電子請求書に含める必要がある一連の重要な情報コンポーネントを意味します。
(3)「セマンティック データ モデル」とは、電子請求書のコア要素を指定する、構造化され論理的に相互に関連する一連の用語とその意味を意味します。（注：コアインボイスモデル）
(4)「構文」とは、電子請求書に含まれるデータ要素を表すために使用される機械可読言語または方言を意味します。
(5)「構文バインディング」とは、電子請求書のセマンティック データ モデルをさまざまな構文で表現する方法に関するガイドラインを意味します。

7 List of syntaxes which comply with EN 16931-1:2017
Based on the assessment, the list of the limited number of syntaxes, which comply with EN 16931-1:2017 shall include:
• UN/CEFACT Cross Industry Invoice XML message as specified in XML Schemas 16B (SCRDM – CII)
• UBL invoice and credit note messages as defined in ISO/IEC 19845:2015
It is expected that the list above

5 Cross-mapping between syntaxes
5.1 Introduction
As the semantic model is mapped to syntaxes, it is in principle possible to cross-map between syntaxes.
Cross-mapping is however only possible without information loss if the mapping is complete and if no mapping issues exist, as described in 4.7. If mapping issues exist, it still may be possible to cross-map from a syntax with an incomplete mapping to a syntax with a complete mapping without information loss, but not vice versa.
Invoices according to EN 16931-1 that are transferred using a specific syntax, use a defined profile on that syntax. The profile is identified in the message (element BT-20). This means that all elements in the invoice are defined in the semantic model. In fact the definition in the semantic model overrules the definition in the syntax specification. A receiving system therefore can be certain that no other elements need to be mapped than those existing in the semantic model.
As listed in 4.7, mapping issues may exist on the semantic level, on structural level, on cardinality level or on data type level. For each level an assessment can be made of the issues that may arise when cross-mapping between syntaxes.

セマンティック モデルは構文にマッピングされるため、原理的には構文間のクロス マッピングが可能です。
ただし、4.7 で説明されているように、マッピングが完了し、マッピングの問題が存在しない場合にのみ、クロスマッピングは情報の損失なしで可能です。マッピングの問題が存在する場合でも、不完全なマッピングを持つ構文から完全なマッピングを持つ構文に、情報を失うことなくクロス マップすることは可能ですが、その逆はできません。
特定の構文を使用して転送される EN 16931-1 に準拠した請求書は、その構文で定義されたプロファイルを使用します。プロファイルはメッセージで識別されます (エレメント BT-20)。これは、請求書のすべての要素がセマンティック モデルで定義されていることを意味します。実際、セマンティック モデルでの定義は、構文仕様での定義よりも優先されます。したがって、受信システムは、セマンティック モデルに存在する要素以外の要素をマップする必要がないことを確信できます。
4.7 に記載されているように、マッピングの問題は、セマンティック レベル、構造レベル、カーディナリティ レベル、またはデータ型レベルで存在する可能性があります。レベルごとに、構文間のクロスマッピング時に発生する可能性のある問題を評価できます。

Solution 4: Access to Data Services to verify Reliability and Data Quality

Background and purpose
背景と目的

Open Accounting is a secure way to give service providers access to an SME’s financial information from bookkeeping. Open Accounting enables the SMEs to voluntarily share their data from digital business documents with third parties of their choice. This is done through standardised content and interoperable APIs. APIs are interfaces for sharing data between digital systems, and interoperability means that different systems can communicate.
Open Accounting は、サービス プロバイダーが簿記から SME の財務情報にアクセスできるようにする安全な方法です。 オープン アカウンティングにより、SME は、デジタル ビジネス ドキュメントからのデータを任意のサード パーティと自発的に共有できます。 これは、標準化されたコンテンツと相互運用可能な API を通じて行われます。 API はデジタル システム間でデータを共有するためのインターフェイスであり、相互運用性とは異なるシステムが通信できることを意味します。

For example, a smart warehouse management app could connect to any business system and read the latest transactional data to calculate and check the current stock of products. An SME might also connect their business system to their bank during a credit assessment process, enabling direct read-only access to the bank’s system. In both cases, the SME avoids the hassle of manually exporting tables and setting up spread sheets to deliver data and stay updated.
たとえば、スマート倉庫管理アプリは、任意のビジネス システムに接続し、最新のトランザクション データを読み取って、製品の現在の在庫を計算および確認できます。 SME は、信用評価プロセス中にビジネス システムを銀行に接続し、銀行のシステムに読み取り専用で直接アクセスできるようにすることもできます。 どちらの場合も、SME はテーブルを手動でエクスポートし、データを配信して最新の状態に保つためにスプレッド シートを設定する手間を省くことができます。

The purpose of Open Accounting is to create a competitive market for innovative solutions and services to the benefit of the SMEs. Standardisation reduces the development costs and makes new services usable with together with other systems and services. With the existing, non-standardised practices for data sharing, a new service or application must virtually be built from scratch when connecting to a business system. With the interoperability provided in the future by standard APIs, this cost is greatly reduced, and the SMEs will have access to a wider selection of services utilising their data. Open Accounting also enables portability, which means that historic data can be transferred from one system into another system. It means that the SMEs can also change service provider, which is a necessity to a competitive market.
オープン アカウンティングの目的は、SME の利益となる革新的なソリューションとサービスの競争力のある市場を創出することです。 標準化により、開発コストが削減され、新しいサービスが他のシステムやサービスと一緒に使用できるようになります。 データ共有の標準化されていない既存の慣行では、ビジネス システムに接続するときに、新しいサービスまたはアプリケーションを仮想的にゼロから構築する必要があります。 将来、標準 API によって提供される相互運用性により、このコストは大幅に削減され、中小企業は自社のデータを利用してより幅広いサービスにアクセスできるようになります。 オープン アカウンティングは移植性も可能にします。つまり、履歴データをあるシステムから別のシステムに転送できます。 これは、中小企業もサービスプロバイダーを変更できることを意味します。これは、競争の激しい市場に不可欠です。

Recommendations for increasing the use of Open Accounting
オープン会計の利用を増やすための推奨事項

To the benefit of the SMEs, the business systems should enable third-party access to financial transaction data, with consent from the SME who owns the data. The data should be structured in a standardised way, with harmonised definitions of accounting data. Today, several file formats exist (e.g. SAF-T and XBRL-GL) which are useful for defining accounting data. These are already used for audit purposes and for portability (that is, for transfer of data between systems).
SME の利益のために、ビジネス システムは、データを所有する SME の同意を得て、金融取引データへのサード パーティ アクセスを有効にする必要があります。 データは、会計データの定義を調和させて、標準化された方法で構造化する必要があります。 現在、会計データの定義に役立ついくつかのファイル形式 (SAF-T や XBRL-GL など) が存在します。 これらは、監査目的および移植性 (つまり、システム間のデータ転送) のためにすでに使用されています。

Private and public actors may prefer voluntary paths for delivering standardised data sharing among businesses and third parties, finding a compromise that respects current business models of business system vendors and third parties such as banks. If necessary, interoperability and portability could be regulated.
民間および公的アクターは、ビジネス システム ベンダーや銀行などのサード パーティの現在のビジネス モデルを尊重する妥協案を見つけて、ビジネスやサード パーティの間で標準化されたデータ共有を実現するための自発的な道を好む場合があります。 必要に応じて、相互運用性と移植性を規制できます。

The sharing of data should comply with privacy and trade secret regulations, and must not compromise GDPR (the General Data Protection Regulation), which requires confidentiality and protection of sensitive personal information. However, GDPR affects only a very limited set of business data, where sensitive information should always be protected.
データの共有は、プライバシーと企業秘密の規制に準拠する必要があり、機密性と機密性の高い個人情報の保護を要求する GDPR (一般データ保護規則) を侵害してはなりません。 ただし、GDPR は、機密情報を常に保護する必要がある非常に限られた一連のビジネス データにのみ影響を与えます。

The data sharing described here is limited to standard ways of accessing and reading accounting information in business systems, but not creating or updating accounting information.
ここで説明するデータ共有は、ビジネス システムで会計情報にアクセスして読み取る標準的な方法に限定されていますが、会計情報を作成または更新することはありません。