EIPA発足時点で想定していた「Peppolで実現を目指す領域」は、見積〜受発注〜納品/検収といった上流（O2P）よりも、
まずは 請求（eInvoice）から入金・支払（全銀EDI）までを含む S2C を中心に、会計・税務システムへ自動連携させる、という整理であった。

DBNAlliance は “connect once” を掲げ、
既存の多様なプラットフォームやネットワークを「一つに吸収」するというより、

という “共通フレームワーク” で統合を進めている。

DBNAlliance のオンボーディング資料では、4-corner（C1〜C4）とともに、
共通標準として UBL 2.3、伝送プロトコルとして AS4 を採用し、SML/SMP 等のポリシーと技術に従うことを明示している。

DBNAlliance のSML解説では、SML を “動的なサービス位置解決（dynamic service location）” の中核と位置づけ、
SML→SMP→AS4 の技術トリオとして説明している。

また、識別子（例：DUNS/EIN/SSN 等）の “scheme” を前提に、
(1) 変換（不可逆ハッシュ）→ (2) Base32 → (3) NAPTR で SMP URL に誘導する流れを具体例付きで記載している。

加えて、SMLドメインを Production と Test に分け、Test を「AP開発・テスト」と同時に
「新しい文書タイプを本番投入前に拡張する場」として位置づけている。

米欧の共同声明（TTC文脈）では、成功するeInvoicingの原則として

を明示している。

さらに同声明は、EUと米国のeInvoicing枠組みが「類似の技術標準・インフラ・ビジネス慣行を活用している」こと、
米国のeInvoiceの基盤となる構文が UBL であること、サービスプロバイダーによる “roaming establishment” の重要性に言及している。

このため、DBNAllianceが 4-corner／AS4／UBL を採用していることは、
Peppolの普及モデルを北米市場に適合させた “意識的な整合” と捉えられる。

Peppolは PINT（Peppol International）を、各国の税制・法制度・商慣習の差を吸収しつつ相互運用する枠組みとして展開している。
日本（Japan PA）も PINT の方法論に基づき JP PINT 等を整備している。

DBNAllianceは UBL 2.3 を共通標準に採るため、PINT（UBL構文バインディング）と “構文面” で共通基盤を持ちやすい。
結論として、両者の相互運用は「別物をつなぐ」というより「近い構造同士を合わせる」問題に寄せられる。

相互運用の実務は、当事者が複数ネットワークに個別接続するのではなく、
サービスプロバイダー（AP相当）が “ゲートウェイ／ローミング” として肩代わりする形が現実的である。

実際、DBNAlliance側は Certified Service Providers を公開しており、
日本側でも「日本のPeppol Certified Service Provider一覧（デジタル庁）」が公開されている。

この2つのリストに共通して現れる事業者（例：Basware／EDICOM／Storecove／Sovos／Avalara 等）が存在することは、
「一つの窓口で複数ネットワークを扱う」運用が成立し得る（少なくとも成立“しやすい”）ことを示唆する。

「国内のPeppolプロバイダーに契約していれば、米国（DBNAlliance）にも送れるのでは？」という直感は、方向として正しい。
ただし実務上は、次の3点が揃う必要がある。

国内専業APの場合、DBNに出られる“出口”として、DBN側認定事業者との相互接続が必要になる。

AS4で送れても、文書内容（必須項目、コード、税、参照、添付、エラー応答等）が通らなければ業務にならない。
ここで PINT（国際）を“共通基準点”として、JP PINT↔UBL 2.3 の差分を吸収する（変換＋検証＋版管理）が重要になる。

日本のSMLだけで相手（米国側）を探索できるとは限らないため、SML/SMPの相互参照やゲートウェイが必要になる。

日本企業が“いま”米国へ確実に送りたい場合の現実解は次のいずれかである。

前者の候補確認には、
* デジタル庁：日本のPeppol Certified Service Provider一覧
* DBNAlliance：Certified Providers
の突合せが有効である。

中国・韓国は、Peppol型ネットワークの前に、税務当局の制度（CTC／報告／クリアランス等）対応が中心課題になりがちである。

したがって国内プロバイダーは、

を同じ箱で語らず、別SKU（または提携パッケージ）として提示する方が現実的である。

米国（DBNAlliance）:
* DBN宛ては「自社内で完結」か「提携先ゲートウェイ」か？
* 宛先探索はどうするか（相手SML参照／ゲートウェイ解決／手動登録 等）？
* JP PINT→UBL 2.3 の変換・検証・例外処理（失敗時フィードバック）は提供範囲か？
* 追加費用（ローミング／越境オプション）、SLA、監査ログは？

中国/韓国:
* 当局提出（CTC/報告）まで含めるか？（B2B交換のみでは足りないことが多い）
* 現地の電子署名／保管／監査要件は誰が担保するか？

Peppol の Post-Award 領域では、O2P を構成する複数文書（Order / Order response / Catalogue / Despatch advice 等）が BIS として整備されている。
また Billing（Invoice & Credit Note）は、S2C の中心となる請求交換を標準化する。

Peppol は「決済そのもの」はネットワーク外だが、入金・消込を支える参照情報（送金参照等）を扱える設計になっているため、
S2C を“会計連携”まで伸ばしやすい。

DBNAlliance の共通対象は、現時点では UBL 2.3 の invoices and credit notes（＝請求中心）である。
すなわち、統合の主戦場は S2C（特に Invoice-to-Cash）であり、O2P の上流（カタログ／注文／出荷など）は、既存の業界EDI・調達SaaS・ネットワークの多様性を前提に残している。

S2C の統合で、最も業務インパクトが大きいのは「請求（Invoice）」よりも、
請求と入金を結びつける「消込（Reconciliation）」である場合が多い。

日本では、たとえば次のような運用が消込コストを押し上げやすい。

米国側では e-remittance（入金消込情報）を DBNAlliance の交換フレームワーク上で検証し、pilot を進める流れが示されている。
日本版SMLでも、請求（Invoice）だけでなく 支払通知（Remittance Advice）を同じ枠組み（4-corner＋SML/SMP＋AS4）で流す ことを統合のゴールに据えるべきである。

4-corner 型ネットワークでは、探索（SML/SMP）と Directory は運用上の“源泉”になる。
利用が自動化・ポーリング・リトライ・バースト化して負荷が増えると、探索基盤がボトルネック（単一故障点）になり得る。

日本でも、標準SMLを“統合の中心”に据えるなら、最初から
「可用性」「スケール」「濫用耐性」「監査」「責任分界」を設計要件に入れる必要がある。

探索基盤は「到達性」を担保する一方、データ品質が悪いと配送トラフィックを直接阻害する。
誤登録・不整合・古い情報をどう検知し、誰がいつ是正するか（ガバナンス・運用）が、統合の成否を左右する。

国内の探索基盤（標準SML）まで特定の国外インフラに全面依存することは、通商安全・レジリエンスの観点でリスクになり得る。

重要なのは、単に「日本独自」を目指すのではなく、

を Peppol/DBNAlliance と可能な限り共通化（準拠）しつつ、
インフラの運営権（ルート信頼、SMLサーバ運用、監督・是正権限）を国内に置く こと。

すなわち 「準拠かつ自立」 のモデルが、グローバル連携と国内防衛を両立させる現実解になり得る。

SML がダウンすると探索が止まり、結果としてネットワーク全体の配送が止まるリスクがある。
日本版では BCP（事業継続計画）の観点から、次のような「ハイブリッド設計」を検討に加える価値がある。

「SMLが単一故障点になり得る」という一般論に加え、2025〜2026年は“基盤仕様が実際に動いている”点が重要である。

国内プロバイダーにとっては、これは「将来の話」ではなく
運用・更改・障害対応・監査 を含む“現行サービス品質”に直結するため、ロードマップとして明示すべき論点である。

Peppol（JP PINT）や中小企業共通EDI、業界EDI、電子レシート、デジタルバンキング等の外部情報を、
XBRL GL Next（構造化CSV）という 正規化ハブ に集約し、販売・調達・在庫・入出金などの業務システムと、
電子帳簿・経理・外部報告（決算/納税）を同一の基盤で繋ぐ。

各業界標準（ZEDI、流通BMS等）から直接 UBL に個別変換すると、
相手や制度改正が増えるたびに変換点が増え、保守が破綻しやすい。

一度 XBRL GL Next という「正規化されたデータ形式（共通論理ハブ）」を通すことで、
将来的な「法改正による項目追加」や「新ドメイン（例：環境スコープ3データ等）の追加」に対しても、
ハブ側の定義更新（モデル／辞書／バインディング更新）を中心に全接続先へ波及させやすくなる。

本節の狙いは、O2P と S2C を「別世界のデータ」として扱うのではなく、XBRL GL Next ハブ上で

を 同一の台帳モデル（共通キー＋参照関係） に繋ぎ、後工程（監査・照合・自動消込・税務）を一気に軽くすることにある。

2026年は、政府が成長戦略・輸出競争力などを政策テーマとして掲げ、企業の越境取引（取引先・国の増加）が起きやすい環境にある。^[1]

この局面では、少なくとも次が起きやすい。

国内Peppolプロバイダーにとっては、JP PINTを“国内DX”だけでなく、越境の「輸出インフラ」として位置づけ直すチャンスになる。

国内プロバイダーが検討すべき戦略は、乱暴に言えば次の二段である。

この「第二波」を成立させるための設計要素が、以下の 4 つ（到達性・仕様整合・ディスカバリ・運用）である。