ペポル によるデジタルインボイスでは，UBL Invoice又はCreditNoteの本文だけでなく，外側に付与されるSBDH（Standard Business Document Header）の扱いが重要である。

特に，マーケットプレイス，業界EDI，流通EDI，購買プラットフォーム，受発注プラットフォーム，卸売市場，農協等，流通業における仕入明細書等をペポル と接続する場合，次の問題が生じる。

本稿では，SBDHの文書構造，BIS Billing 3.0及びJP PINTにおけるenveloping compliance，JP BIS Self Billing Invoice，海外のマーケットプレイス事例，日本の適格請求書制度における代理交付及び媒介者交付特例，卸売市場特例，農協等特例，流通業における仕入明細書等の取扱い，業界EDIとペポル を接続する場合の運用形態を整理する。

焦点は，SBDH Senderの扱いである。

ペポル で送信される業務文書は，UBL Invoice又はCreditNoteのpayloadだけで構成されるわけではない。Peppol AS4で交換されるメッセージでは，payloadの外側にPeppol Business Message Envelope，すなわちSBDHが付与される [1]。

SBDHは，Access Pointがpayload本文を読まずにメッセージをルーティングし，sender，receiver，document type，processを一貫した方法で識別するための封筒である。

Peppol Business Message Envelope仕様では，SBDHの基本構造は次のように定義されている。

Peppol Business Message Envelope仕様の文書構造図では，`Sender/Identifier`及び`Receiver/Identifier`は必須要素であり，値は次の形式で表現される。

ここで，`XXXX`は識別子スキームを表し，例えばGS1 GLNであれば`0088`を用いる。`AAAAAAAA`は実際の識別子である。また，`Identifier`要素の`Authority`属性には，固定値として次を用いる。

したがって，SBDHのSender/Identifier及びReceiver/Identifierには，業界EDIの内部利用者ID，取引先コード，仕入先コード，出品者ID，生産者コード等をそのまま記載することはできない。Peppol Participant IDとして表現できる識別子でなければならない。

図に示されるとおり，SBDHでは，Sender，Receiver，DocumentIdentification，`BusinessScope`がpayloadの外側に置かれる。そして，実際の業務文書は，最後の`xs:any`の位置に格納される。

この構造が重要である理由は，SBDH Senderが単なる通信システム名ではないからである。SBDH Sender/Identifierは，ペポル ネットワーク上で送信者を識別するための値であり，payload本文のsender partyと整合していなければならない。

一方で，SBDH仕様は，SBDHの文書構造と識別子形式を定義するものであり，SBDH Sender/Receiverとpayload側Party/EndpointIDの一致要求そのものは，BIS Billing 3.0 compliance，JP PINT compliance及びJP BIS Self Billing Invoice complianceのEnveloping complianceで規定されている。

SBDH Senderとpayload側のEndpointIDの関係については，Peppol BIS Billing 3.0のcompliance pageに，直接的な規定がある [2]。

同ページの`Enveloping compliance`では，BIS messageをPeppol Business Message Envelope，すなわちSBDHで包む場合，次の二つが求められている。

JP PINT complianceにおいても，同様に，SBDHで包まれたBIS messageについて，SBDH Sender/Receiver Identifierとpayload側Party/EndpointIDの一致が求められている [3]。

これは，SBDH Sender/Identifierとpayload側のsender partyのEndpointIDが，単に同じ事業者を意味していればよいという程度の要求ではない。`schemeID`を含めて一致することが求められている。

例えば，payload側が次のように記載されている場合，

SBDH側では，次のように表現される。

したがって，通常のInvoiceの場合には，原則として次の対応関係を満たす必要がある。

この規定は，マーケットプレイス，業界EDI，卸売市場，農協等，仕入明細書等の検討において特に重要である。

例えば，SBDH Senderにマーケットプレイス X 社又はEDIプロバイダー Y 社のPeppol IDを記載する場合，通常のInvoiceであれば，payload側のSeller EndpointIDも X 社又は Y 社として整合させる必要がある。

逆に，payload上のSellerが売り手企業 S 社であるなら，SBDH Senderも S 社を識別するPeppol IDでなければならない。

このため，次のような使い分けはできない。

また，S 社がPeppol IDを持たないからといって，X 社又は Y 社のPeppol IDを S 社の代替としてSeller EndpointIDに記載することも，payload上のSellerの意味を曖昧にする。

ペポル上で X 社又は Y 社のPeppol IDをSBDH Sender及びpayload Seller EndpointIDに使用できるのは，X 社又は Y 社をpayload上のSeller又はinvoice issuerとして整合的に表現できる場合に限られる，と考えるべきである。

なお，BIS Billing 3.0 compliance pageでは，senderはBISに適合しないmessageを送ってはならず，receiverはBISに適合しないmessageの受信を拒否できるとも説明されている [2]。したがって，SBDH Sender/Receiverとpayload Party/EndpointIDの不一致は，単なる実装上の注意事項ではなく，送受信の適合性に関わる問題として扱うべきである。

流通業の仕入明細書等をペポル で扱う場合，最初に確認すべきことは，それを通常のJP PINT Invoiceとして扱うのではなく，JP BIS Self Billing Invoiceとして扱えるかである。

JP BIS Self Billing Invoiceでは，self-billingは，売手ではなく買手が売手の請求書を作成し，売手に確認を求めて送信する取引として説明されている [4]。

この場合，通常のInvoiceとは送信方向が異なる。

したがって，Self Billing Invoiceでは，SBDHとpayloadの対応関係も通常のInvoiceと逆になる。

これは，仕入明細書等を扱ううえで極めて重要である。

通常のJP PINT Invoiceでは，SBDH Senderは売手，SBDH Receiverは買手である。これに対して，JP BIS Self Billing Invoiceでは，SBDH Senderは買手，SBDH Receiverは仕入先である。

したがって，買手 B 社が仕入明細書等を作成し，仕入先 S 社に確認を求める取引であれば，通常のJP PINT Invoiceに無理に当てはめるのではなく，まずJP BIS Self Billing Invoiceの適用を検討すべきである。

ただし，JP BIS Self Billing Invoiceを用いる場合でも，仕入先 S 社がPeppol Participant IDを持たない場合には課題が残る。Self Billing Invoiceでは，SBDH Receiverは仕入先 S 社を識別する必要があるためである。買手 B 社，マーケットプレイス X 社又はEDIプロバイダー Y 社のPeppol IDを，仕入先 S 社の代替としてSBDH Receiver又はSupplier EndpointIDに用いることは，原則として避けるべきである。

本稿では，マーケットプレイス，業界EDI，卸売市場，流通業の仕入明細書等をペポル に接続する場合の典型例として，次のような取引構成を想定する。

この場合，単純に「代行送信だからマーケットプレイス X 社又は Y 社のPeppol IDでよい」とは言えない。

通常のInvoiceであれば，SBDH Senderはpayload上のSellerと整合する必要がある。Self Billing Invoiceであれば，SBDH Senderはpayload上のBuyerと整合する必要がある。

したがって，どのPeppol IDをSBDH Senderに記載するかは，その文書が通常のInvoiceなのか，Self Billing Invoiceなのか，またpayload上のsender partyが誰なのかによって決まる。

海外の公開事例として，ベルギーにおけるAmazon VCSのVAT e-invoice対応が参考になる。

この事例では，Amazonがsellerの代わりにペポル ネットワークで電子インボイスを作成・送信するためには，seller自身のPEPPOL IDをAmazonへ提供する必要がある，という説明がされている [13]。

この事例は重要である。

Amazonがペポル 送信を代行する場合であっても，請求書上のsellerがseller企業であるなら，Amazon自身のPeppol IDをsellerのPeppol IDとして代用するのではなく，seller自身をPeppol Participantとして識別する考え方を示している。

この整理では，通常のInvoiceの場合，次のようになる。

この方式は，ペポル の原則に素直である。しかし，売り手企業 S 社がPeppol IDを持っていない場合には，そのままでは運用できない。

日本では，適格請求書制度において，代理交付及び媒介者交付特例が認められている [8]。

ここで注意すべき点がある。

国税庁が特定のプラットフォーム事業者を「代理の適格請求書発行事業者」として個別に認定する，という整理ではない。制度上は，適格請求書発行事業者として登録された事業者が存在し，そのうえで，代理交付又は媒介者交付特例の要件を満たす場合に，一定の交付方法が認められる，という構造である。

委託販売の場合，購入者に対して課税資産の譲渡等を行っているのは本来，委託者であり，委託者が適格請求書を交付するのが原則である。そのうえで，受託者が委託者を代理して，委託者の氏名又は名称及び登録番号を記載した委託者の適格請求書を交付することが認められる。これが代理交付である。

さらに，一定の要件を満たす場合には，媒介又は取次ぎを行う受託者が，自己の氏名又は名称及び登録番号を記載した適格請求書又は電磁的記録を，委託者に代わって購入者に交付又は提供できる。これが媒介者交付特例である。

このため，マーケットプレイス X 社のような事業者については，次の二つを分けて考える必要がある。

なお，英語圏では，プラットフォーム事業者が売主又は請求書発行者として責任を負う構成を，merchant of record と説明することがある。しかし，日本の法令上，merchant of record という用語が一般的に規定されているわけではない。

日本で関連する制度としては，媒介者交付特例及び消費税のプラットフォーム課税がある。ただし，媒介者交付特例は適格請求書の交付方法の特例であり，受託者を当然に商流上の売主とする制度ではない。

したがって，ペポル上でプラットフォーム事業者のPeppol IDをSBDH Sender及びpayload Seller EndpointIDに使用できるのは，そのプラットフォーム事業者をpayload上のSeller又はinvoice issuerとして表現することが，契約上，税務上，及びPeppol semantic model上，整合的である場合に限る，と整理すべきである。

一次産業の取引では，通常のマーケットプレイス又は業界EDIとは異なる論点がある。

例えば，青果，水産物，花き，畜産物などを取り扱う卸売市場 Z 社が，複数の生産者又は出荷者から委託を受け，買い手に対して請求書又はこれに準ずる取引書類を交付する場合である。

このような取引は，実務上「市場が売り手の請求書を代理発行している」と説明されることがある。しかし，適格請求書制度上は，少なくとも次の三つを区別する必要がある [8] [9] [10]。

この三つは，ペポル上のSBDH Senderを決める際にも区別しなければならない。

流通業では，買手である小売業者，卸売業者，チェーン本部，購買プラットフォームが，仕入先に対して仕入明細書，支払通知書，検収明細，月次仕入明細などを作成し，仕入先の確認を受ける実務が広く存在する。

適格請求書等保存方式でも，買手が作成した一定事項の記載のある仕入明細書等について，相手方の確認を受けたものは，仕入税額控除のために保存すべき請求書等に該当し得る [11] [12]。

このような買手作成文書については，通常のJP PINT Invoiceではなく，JP BIS Self Billing Invoiceの適用をまず検討すべきである。

S 社がPeppol IDを持たない場合，考えられる運用形態は次のとおりである。

業界EDIとペポル を接続する場合，業界EDI側には，Peppol IDとは異なる参加者識別子が存在することが多い。

例えば，次のような識別子である。

これらは，Peppol Participant IDではない。したがって，SBDH Sender/Identifier又はReceiver/Identifierにそのまま記載すべきではない。

ペポル に接続する場合は，少なくとも次のマッピングが必要である。

業界EDIプロバイダーがペポル へ変換送信する場合でも，そのプロバイダーIDをSBDH Sender又はSBDH Receiverに記載できるのは，そのプロバイダーがpayload上のSeller，Buyer，Supplier又は当該文書のbusiness sender/receiverとして位置付けられる場合に限られる。

欧州では，ViDAにより，電子インボイス及びデジタル報告要求の重要性が高まっている。Openペポル は，EN 16931ベースのPeppol eInvoice仕様及びペポル ネットワークが，ViDA下のeInvoicing及びDRRに対応できることを実証するため，Peppol ViDA Pilotを進めている [14]。

ViDA対応では，請求書のデータが税務報告にも関係するため，送信者・受信者・売り手・買い手の識別はより重要になる。

業界EDIとペポル を接続する場合も，単なるファイル変換では足りない。SBDH Sender/Receiver，payload上のSeller/Buyer，Self Billing Invoiceにおけるsender/receiver，税務上の発行者，プラットフォーム事業者，技術的送信者，買手作成文書の作成者を明確に区別する必要がある。

特に，次のような整理が必要である。

これらが一致する場合は問題が少ない。しかし，マーケットプレイス，代理販売，委託販売，市場取引，業界EDI連携，仕入明細書等では，一致しない場合がある。その場合にSBDHへ誰のPeppol IDを記載するかを明確にしなければならない。

PAへの確認前の作業仮説として，次の基本方針を提案する。

この問題は，個別プロバイダの実装判断に任せるべきではない。EIPAとして事実を整理したうえで，PAに次の点を確認することが望ましい。

SBDH Senderは，単なる通信経路上の送信システム名ではない。ペポル上のbusiness senderを示し，payload側のParty/EndpointIDと一致しなければならない。

通常のJP PINT Invoiceでは，SBDH Senderは通常，Sellerである`AccountingSupplierParty`に対応する。一方，JP BIS Self Billing Invoiceでは，買手が売手に代わって売手の請求書を作成し，売手に確認を求めて送信するため，SBDH SenderはBuyerである`AccountingCustomerParty`に対応し，SBDH ReceiverはSupplierである`AccountingSupplierParty`に対応する。

マーケットプレイス，業界EDI，購買プラットフォーム，卸売市場，農協等，流通業の仕入明細書等をペポル へ接続する場合，最も重要なのは，技術的送信者，商流上の売り手，税務上の請求書発行者，Self Billing Invoiceの作成者，ペポル上のbusiness sender及びreceiverを混同しないことである。

海外のマーケットプレイス事例では，sellerの代わりにペポル 送信を行う場合でも，seller自身のPEPPOL IDを使う考え方が示されている。一方，日本の媒介者交付特例では，受託者が自己の名称及び登録番号を記載した適格請求書を委託者に代わって交付できる場合がある。

さらに，一次産業の卸売市場特例や農協等特例では，出荷者又は生産者の適格請求書交付義務そのものが免除される場合がある。この場合，市場又は農協等が作成する書類をペポル上でどの文書種別として扱うべきかが問題となる。

また，流通業における仕入明細書等では，文書の作成者は買手であり，課税仕入れの相手方は仕入先である。この構成は，通常のJP PINT Invoiceではなく，JP BIS Self Billing Invoiceの対象候補として整理すべきである。

ただし，JP BIS Self Billing Invoiceを用いる場合でも，仕入先 S 社がPeppol IDを持たない場合には，SBDH Receiver及びpayload Supplier EndpointIDをどのように扱うかという問題が残る。買手 B 社，マーケットプレイス X 社又はEDIプロバイダー Y 社のPeppol IDを，仕入先 S 社の代替として用いることは，payload上の当事者識別を曖昧にするため避けるべきである。

この論点は，日本固有の問題にとどまらない。欧州ViDAのように電子インボイスとデジタル報告が結び付く環境では，SBDHとpayloadの当事者識別の一貫性は，ますます重要になる。