欧州のCEF(Connected Europe Facility)が定義しているコンプライアンスは次のページに記載されています。
EN 16931 compliance

このページの内容の一部を次に翻訳紹介します。

欧州のeInvoicing標準のコンプライアンス
eInvoicing標準(EN 16931-1)のパート1のセクション4.4（本記事の最後に記載）では、詳細なコンプライアンス基準が指定されていますが、以下は簡単な紹介です。
欧州のeInvoicing標準では、コンプライアンスを遵守する関係者は、コンプライアンス要件を満たす請求書のサポートを実装する必要があります。

デジタルインボイス文書
作成および送信されるデジタルインボイスは、コアインボイスまたはそれが基づくCIUS（Core invoice usage specification）が定めるすべてのルールに準拠している必要があります。
以下の要件が含まれます。

JP PINTにおいて
上記は要約ですが、JP PINTの提供するvalidation artefacts（Schematronファイル）を使用してC1から送信されたUBL2.1メッセージを検証しても、次の2つの条件に関しては不完全なチェックしか提供されていません。

そのため、非準拠なメッセージの転送を完全に排除することはできません。

BIS Billing 3.0はEN 16931に準拠しているため、EN 16931のコンプライアンス文書が準拠/非準拠の判断の根拠とされています。しかし、PINTはEN 16931に拘束されないことを主張していますが、Compliantであるための条件を定義する文書は存在しません。

コンプライアントに関連する以下の記事も参考にしてください。

また、これまでのBIS Billing 3.0は、欧州規格CEN/TS 16931-3-1:2017（論理データ項目の構文バインディングについての規定）およびCEN/TS 16931-3-2:2020（UBL２．１の構文バインディングの規定）に基づいており、これらの文書はUBL2.1への構文バインディングを規定していますのでペポルはこれらの規定に基づいて相違点や具体例の記述で済んでいました。

しかし、新規サポートされるPINTに基づくJP PINTのBISでは、これらの欧州規格の既定文書に縛られないことを表明していますが、これらの欧州規格の規定文書との関連やPINT拡張に関する具体的な既定が文書として公開されていないにもかかわらず従来同様に不在の基礎規定からの差分の形での文書化にとどまっており、標準仕様としては不完全です。

したがって、BIS自体がコンプライアントであるための条件を判断するための文書は存在しません。

下記はChatGPTとの会話です。法的な知識がないため内容に責任が持てませんが、何を気にしているかはご理解いただけると思います。
問題が顕在化するのは、買い手（C4）が受け取った電子請求書がBISで定義されている内容とは異なっていることが原因になって取引上の問題となってしまった場合だと思われます。
提供されたSchematronファイルを適用しただけですということが免責条件にならないこともありそうなので、プロバイダの方々は法務部門も交えて検討されたほうがよろしいのではないでしょうか。

次の条項の下で、12.4 c)で提供されるvalidation artefactsが不完全であることが原因でService ProviderがBISで定義された形式とは異なるメッセージを転送したときに問題はありますか。

12.4 c)で提供されるvalidation artefactsが不完全であることが原因でService ProviderがBISで定義された形式とは異なるメッセージを転送したときに問題はありますか。

ChatGPT解説：
この条項では、Peppol Authority（Peppol機関）がPeppol Network内の非準拠事例に対する制裁とサービスの取り消しについて述べています。提供されるvalidation artefactsが不完全であり、それがService ProviderによるBISで定義された形式とは異なるメッセージの転送につながった場合、問題が生じる可能性があります。

18.1節では、Peppol Authorityが本契約の規定またはPeppol相互運用フレームワークに準拠していない状況やPeppol Networkの正常な機能を危険にさらす可能性のある他の状況に気付いた場合、調査を開始する権利を有していることが述べられています。Peppol Service Providerは、この調査を行うために必要な情報と協力を提供する義務があります。

18.2節では、非準拠の状況が確認された場合、Peppol Authorityは警告書を送付し、Peppol Service Providerにその状況を通知します。警告書には以下の内容が含まれます：
a) 非準拠の性質を明確に示すこと。
b) Peppol Authorityからの通知後、Peppol Service Providerが非準拠を修正するための現実的な計画を提供する機会を与えること。計画にはPeppol Service Providerによって予定されるタイムラインも含まれます。
c) 非準拠が修正されない場合に課される制裁を明示すること。

18.3節では、Peppol Authorityが確認されたPeppol Service Providerの非準拠サービスに対して課すことができるエスカレーションプロセスと制裁の種類が説明されています。制裁の範囲には、OpenPeppolの非公開メンバーサイトおよび関連Peppol機関が市場コミュニケーションに使用する公開ウェブサイトに非準拠状況を公表すること、一時的にPeppol Network上でのPeppolサービス提供能力を削除すること、および永久にPeppol Network上でのPeppolサービス提供能力を削除することが含まれます。

このような状況が継続する場合、Peppol Authorityは18.4節で説明されているエスカレーションプロセスの次のステップを開始することができます。各ステップでは、Peppol Authorityは状況を修正するためのタイムラインを明示する警告書を送付します。

18.5節では、非準拠状況が持続し、直ちに対応が必要な場合、Peppol AuthorityはPeppol Coordinating Authorityと協議した上で、Peppol NetworkへのリスクやPeppol Service Providerおよび関係するエンドユーザーへの潜在的な影響についてのリスク評価後、Peppol Coordinating AuthorityにPeppol Service ProviderのPeppol Network上でのPeppolサービス提供能力を一時的に削除するよう要請することができます。Peppol Authorityは、一時的なアクセス削除後すぐに18.2節で説明されている通知を送付し、状況を修正してアクセスを復旧する方法も記載されます。

18.6節では、Peppol Authorityが設定した条件に基づき、Peppolサービスの提供能力の一時的な削除を延長することができます。

18.7節では、Peppol Service Providerが設定された期限内に応答しない場合、Peppol AuthorityはPeppol Network上でのPeppolサービス提供能力を永久に削除することができます。

18.8節では、Peppol Network内の関連する他のアクターにPeppolサービス提供能力が一時的または永久に削除されたことをPeppol Authorityが直ちに通知することが義務付けられています。

18.9節では、Peppol Networkの他のアクターが使用できない問題が特定された場合、Peppol Authorityは即座に対策を実施するようPeppol Service Providerに指示することができます。

BISに非準拠なメッセージを転送しない責任は、だれが負っていますか。またそうならないようにするための仕組みはありますか。

BISに非準拠なメッセージを転送しない責任は、Peppol Service Provider（Peppolサービスプロバイダ）にあります。彼らは、Peppolネットワークのエンドユーザーが適切なPeppol BISに準拠したメッセージを送受信できるようにする責任を負っています。

Peppol Service Providerは、Peppol BISに従ってメッセージを処理し、必要な検証や形式の確認を行うことで、非準拠なメッセージを転送しないようにする必要があります。

また、Peppol Authority（Peppol機関）によって定められた監視および制裁手続きも存在します。Peppol Authorityは、Peppolネットワーク内の非準拠事例を監視し、必要に応じて調査を行います。もしPeppol Service Providerが非準拠なメッセージを転送した場合、Peppol Authorityは制裁を課す権限を持っています（例：警告書の送付、非準拠状況の公表、一時的なまたは永久的なサービスの削除など）。

これにより、Peppol Service Providerは自身の責任を認識し、Peppol BISに準拠したメッセージのみを転送するよう努めることが重要です。Peppol Authorityの監視と制裁手続きは、Peppolネットワークの品質と信頼性を維持するための仕組みとなっています。

この契約の下では、12.4 c)で提供されるvalidation artefactsが不完全であることが原因で非準拠なメッセージが転送されてしまうことを回避するために、従来はvalidation artefactsを適用してチェックするだけでよかったのですが、それにとどまらない対策を講じる義務はService Providerに課せられているのでしょうか。そうだとするとその根拠となる状況を示して解説してください。

この契約の下では、12.4 c)で提供されるvalidation artefactsが不完全であることが原因で非準拠なメッセージが転送される可能性がある場合、Service Providerには追加の対策を講じる責任が課されます。

根拠となる状況は、以下の要素に基づいて説明されます：

相互運用性の確保: Peppolネットワークは相互運用性を重視しています。すべての参加者が共通の基準とルールに従うことで、円滑なデータ交換が実現されます。そのため、提供されるvalidation artefactsが不完全な場合、メッセージの正確性と相互運用性が損なわれる可能性があります。

データ品質の維持: Peppolネットワークでは、正確で信頼性の高いデータの交換が重要です。validation artefactsは、データの整合性や形式の確認に役立つツールです。不完全なvalidation artefactsが提供された場合、正確性やデータ品質の保証が十分に行われない可能性があります。

ネットワーク全体の信頼性の維持: Peppolネットワークは多くの参加者が利用する大規模なシステムです。一つの参加者が不完全なvalidation artefactsに依存することで、他の参加者にも影響を及ぼす可能性があります。Service Providerは、ネットワーク全体の信頼性を維持するために、追加の対策を講じる責任があります。

したがって、Service Providerには提供されるvalidation artefactsの不完全さを回避するための対策を講じる責任が課されます。彼らは、自身のシステムやプロセスにおいて追加のチェックや検証を実施し、非準拠なメッセージが転送されるリスクを最小限に抑える必要があります。 Peppol Authorityの監視と制裁手続きは、この責任を強化するための仕組みであり、ネットワーク全体の信頼性を確保する役割を果たしています。

Service Providerには提供されるvalidation artefactsを適用したチェックだけで責任を果たしていると主張できないのですか。

申し訳ありませんが、先ほどの回答で誤解を招く表現を用いてしまいました。

Service Providerは、提供されるvalidation artefactsを適用したチェックを行うことは責任の一部です。それによって非準拠なメッセージを転送しないよう努めるべきです。

ただし、12.4 c)の条項では、validation artefactsが不完全である場合に発生する問題を回避するため、Service Providerには追加の対策を講じる責任も課せられます。つまり、単に提供されるvalidation artefactsを適用するだけでなく、独自のチェックや検証手順を導入し、メッセージの正確性や相互運用性を確保するための努力を行う必要があります。

これによって、Service Providerは自身のシステムやプロセスにおいて非準拠なメッセージの転送を最小限に抑える責任を果たすことが期待されます。Peppol Authorityの監視と制裁手続きは、この責任をサポートし、ネットワーク全体の信頼性を維持するための仕組みとなります。

したがって、Service Providerは提供されるvalidation artefactsを適用したチェックに加えて、追加の対策を講じる責任があると言えます。

追加検証については次を参考にしてください。
『デジタルインボイスはBIS Billing 3.0拡張で』 2022-09-04
『Open Peppol C4 で受信したインボイスの検証』 2023-03-24
『Open Peppol C4 で受信したインボイスの検証 Part 2』 2023-03-25

次は、
EN 16931-1:2017+A1:2019　電子請求書－電子請求書のコア要素のセマンティックデータモデル　Electronic Invoicing – Semantic data model of the core elements of an electronic invoice
（外部リンク）
からの翻訳です。
特に、ENで要請されている次の条件「仕様の構文バインディングは、CEN/TS 16931-3-1で定義された構文バインディング方法論に従う必要があります。」を検証するための標準仕様がPINTでは存在しないのでとても「世界標準」とはいえません。

4.4 コンプライアンス

4.4.1 一般

コア請求書モデルのコンプライアンスは、次の3つのレベルで測定できます：
– 仕様のレベルでのコンプライアンス
– 特定の送信者または受信者の実際の実装
– 個々の請求書インスタンス文書

これらのレベルについては、4.4.2から4.4.4で説明されています。

4.4.2 コア請求書使用仕様のコンプライアンス

コア請求書使用仕様は、コア請求書モデルと組み合わせて使用されるものであり、以下の基準で表現されたこのガイドラインに記載された方法論とルールに準拠する必要があります：
– 仕様は、どのようなビジネス機能または法的要件をサポートすることを意図しているかを明確に述べる必要があります。
– 仕様は、発行者および責任を持つ者を明確に述べる必要があります。
– 仕様は、CIUSの要件がコア請求書モデルとどのように異なるかを明示するか、または違いを具体的に指摘することによって、その違いを明確に述べる必要があります。
– 結果として得られる請求書文書インスタンスは、コア請求書モデルに完全に準拠している必要があります。
– 仕様および関連する場合は、そのバージョンは、参照および処理中の識別において一意に識別可能である必要があります。
– 仕様は、基になる仕様（コア請求書モデルおよびそれに基づく他の仕様）を明示する必要があります。
– 仕様の構文バインディングは、CEN/TS 16931-3-1で定義された構文バインディング方法論に従う必要があります。

4.4.3 送信または受信当事者のコンプライアンス

受信当事者は、コア請求書モデル全般に準拠する請求書または準拠CIUSで準拠する請求書のみを受け入れる場合にのみ、コア請求書モデルに準拠すると主張できます。
送信当事者は、コア請求書モデルに準拠する請求書（準拠CIUSによって発行された請求書を含む）を送信する場合にのみ、コンプライアンスを主張できます。

4.4.4 請求書文書インスタンスのコンプライアンス

請求書文書インスタンスは、コア請求書モデルのすべてのルールを遵守している場合にコア請求書モデルに準拠しています。これには、準拠CIUSに含まれる仕様も含まれる場合があります。
請求書インスタンス文書がCIUSの使用と見なされる要件をサポートしている場合でも、請求書インスタンス文書はまだコア請求書モデルに準拠しています。これらの請求書インスタンス文書は、CIUSをサポートしていない当事者によっても受け取られ、処理されることができます。