三分一技術士事務所

Peppol に Remittance Advice が無いのはなぜか

Views: 3

Peppol Billing 3.0 では invoice の `cbc:PaymentID` が remittance information として定義され、Invoice Response では `Paid` / `Partially Paid` が扱われています。また、公開中の Peppol 文書型一覧には Invoice、Order、Despatch Advice、Receipt Advice などはありますが、独立した Remittance Advice は見当たりません。対照的に DBNAlliance は ISO 20022 `remt.001` ベースの Remittance Advice プロファイルを公開しています。

Peppol を見ていると、注文、注文応答、出荷通知、請求書、請求書応答などの仕様は整っているのに、米国 DBNAlliance のような独立した Remittance Advice 仕様が見当たらないことに気づく。では、なぜ Peppol ではそれが大きな問題にならなかったのだろうか。そして今後、標準化される可能性はあるのだろうか。

本稿では、Peppol の公開仕様と DBNAlliance の公開仕様をもとに、この点を整理する。[1], [2]

1. 結論

先に結論を書くと、Peppol に独立した Remittance Advice が見当たらないのは、少なくとも公開仕様から読む限り、Peppol が支払照合のための情報を次の二つに分散して扱ってきたからである。

  • 請求書そのものの中に含める remittance information

  • 請求書に対する応答としての Invoice Response

つまり Peppol は、DBNAlliance のように「支払通知・支払明細を独立文書として流す」考え方よりも、「請求書に支払参照情報を持たせ、必要に応じて請求書の状態を応答で返す」という設計思想を強く持っているように見える。[3], [4], [5]

一方、DBNAlliance は ISO 20022 の stand-alone remittance advice である remt.001 を前提として、支払と remittance 情報が別経路・別タイミングで流れうる市場実態に対応しようとしている。[2]

2. まず確認しておきたいこと

2.1. Peppol に「Remittance information」はある

Peppol には独立した Remittance Advice 文書が見当たらないが、remittance information そのものが無いわけではない。

Peppol BIS Billing 3.0 の UBL Invoice では、cac:PaymentMeans/cbc:PaymentID が Remittance information と定義されており、これは「支払と請求書を結び付けるための情報」であり、「債権者による重要な消込情報」と説明されている。[4]

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>432948234234234</cbc:PaymentID>
</cac:PaymentMeans>

この点は重要である。Peppol は remittance の必要性を否定しているのではなく、それを「請求書の外にある独立文書」としてではなく、「請求書の中に含める参照情報」として扱っているのである。

2.2. Peppol には「支払済み」を返す仕組みもある

さらに Peppol には Invoice Response があり、請求書に対して Paid を返すことができる。仕様では PD (Paid) が定義され、さらに clarification reason として PPD (Partially Paid) も扱われている。[5], [6]

つまり Peppol では、

  • 請求書に payment reference を載せる

  • その後の状態変化は response で返す

という二段構えで、一定範囲の請求・支払連携を成立させている。

2.3. Peppol にある Receipt Advice は別物である

なお、Peppol には logistics 領域で Receipt Advice がある。しかしこれは支払明細ではなく、物品の受領結果や欠品・破損・遅延などを通知する文書であり、Remittance Advice とは役割が異なる。[7], [8]

名称が似ていても、

  • Receipt Advice = 受領通知

  • Remittance Advice = 支払明細通知・送金明細通知

であり、混同はできない。

3. 公開仕様から見える Peppol の考え方

では、Peppol はなぜ独立した Remittance Advice を用意しなかったのか。

ここで注意すべきなのは、「OpenPeppol が公式にそう説明している文書」を私は見つけていないことである。したがって、以下は公開仕様から読める設計上の含意であり、明示的な公式見解ではない。

3.1. 理由1 請求書中心の業務設計だから

Peppol BIS Billing は EN 16931 に基づく請求書交換を中心に発展してきた。請求書の中に payment means と remittance information を置き、請求書自体を取引と支払の結節点として扱う設計になっている。[3], [4]

これは言い換えれば、「支払に必要な照合キーは、できるだけ invoice の中に入れておく」という発想である。そうであれば、支払通知専用の別文書の必要性は相対的に低くなる。

3.2. 理由2 請求書応答で状態通知を代替できるから

Peppol には Invoice Response があり、買手側が請求書を受理したか、拒否したか、支払済みか、部分支払かといった状態を返すことができる。[5]

そのため、「支払の詳細な内訳」までは送らないとしても、「その請求書が現在どういう状態か」を伝える目的については、ある程度この応答で満たせる。

3.3. 理由3 Peppol は銀行メッセージ網ではなく商取引文書網だから

Peppol は eDelivery と BIS による商取引文書ネットワークであり、ISO 20022 の銀行間・顧客間決済メッセージ網そのものではない。請求書、注文、出荷通知、応答などの商流文書を中心に標準化している。[1]

これに対し、ISO 20022 側には Stand-alone Remittance Advice というメッセージ定義が存在する。[9], [10]

つまり、

  • Peppol は「商取引文書網」

  • ISO 20022 remt.001 は「支払に随伴する remittance の銀行・決済寄りメッセージ」

という違いがある。この違いが、Peppol で Remittance Advice が主役にならなかった背景の一つだと考えられる。

4. DBNAlliance ではなぜ必要なのか

DBNAlliance の Remittance Advice プロファイルは、remt.001 を用いて、支払と remittance 情報を結び付ける方法をかなり具体的に定めている。[2]

その文書では、ACH、check、card、wire など支払手段ごとに RmtId の作り方を示し、支払参照番号や tracking number と remittance 情報を再結合する考え方を明示している。これは米国では、

  • 支払そのもの

  • 支払に対応する請求書番号や明細

  • 支払参照番号

が、必ずしも一つの文書や一つの経路でまとまって流れないことを前提にしているからである。

さらに DBNAlliance のプロファイルは、「広い市場で利用可能な complete remt.001 message を構成すること」を目的の一つとして明記している。[2]

したがって、DBNAlliance における Remittance Advice は補助的機能ではなく、むしろネットワーク価値の中核の一つである。

5. Peppol に無くても「問題になりにくかった」理由

以上を踏まえると、Peppol に独立した Remittance Advice が無くても直ちに問題化しにくかった理由は、おおむね次のように整理できる。

5.1. 1. invoice 内に最低限の消込キーを持てる

cbc:PaymentID により、支払と請求書を結び付ける参照情報を invoice に持てる。[4]

5.2. 2. invoice response で支払状態を返せる

Paid / Partially Paid を返せるため、少なくともステータス通知の一部は別メッセージで代替できる。[5]

5.3. 3. ユースケースの中心が「請求書交換の相互運用」だった

Peppol はまず公共調達や B2B 請求書交換の標準化で広がってきた。そこでは、銀行系の remittance message を別建てで流すことより、請求書の相互運用性確保が優先課題だったと見られる。[3]

5.4. 4. 詳細消込は ERP・銀行連携側で補完されやすい

Peppol は invoice-to-payment reconciliation の助けになる情報を invoice に含めるが、完全な入金消込・支払明細管理は、ERP や銀行取引データ連携側で補完することが多い。Peppol だけで全てを閉じる設計ではない、と読む方が自然である。[3]

6. では将来、Peppol で標準化されるのか

現時点で公開されている Peppol の文書型一覧、BIS 公開ページ、リリースノートを見る限り、独立した Remittance Advice を新たな標準文書として導入することを示す公開資料は見当たらない。[1], [11], [12]

したがって、現時点では「近く標準化される」とまでは言えない。

ただし、可能性が全く無いと断言するのも早い。理由は二つある。

  • eB2B の拡張により Peppol がより広い業界間取引へ踏み出していること

  • 実務上、支払と請求書の再結合ニーズは国や業界によって大きく異なること

もし今後、Peppol が invoice の状態通知だけでは足りない市場、すなわち「支払と支払明細が分離しやすい市場」を強く取り込みにいくなら、DBNAlliance のような独立した remittance advice の必要性は高まるかもしれない。しかしそれは、現時点で確認できる公開ロードマップではなく、今後のユースケース次第である。

7. 日本への示唆

日本では銀行側に ZEDI があり、振込電文や入出金通知に付帯して消込情報を流す実務がある。一方、Peppol / JP PINT は請求書交換側の枠組みである。

そのため日本では、次のような分担の方が現実的に見える。

  • Peppol / JP PINT は請求書の交換と請求書識別子の標準化を担う

  • ZEDI や銀行取引データは支払結果と消込データを担う

  • 必要に応じて両者を結ぶ参照キーを揃える

この観点から見ると、「Peppol に Remittance Advice が無い」のは単純な欠落というより、Peppol が請求書ネットワークとして設計されてきたことの帰結である。

8. おわりに

Peppol に Remittance Advice が無いのは、remittance の重要性を軽視しているからではない。そうではなく、Peppol はそれを

  • invoice の中の remittance information

  • invoice response による状態通知

として取り込んできたのである。

これに対して DBNAlliance は、ISO 20022 remt.001 を用いた stand-alone remittance advice を明示的に採用し、支払と明細の分離・再結合という米国的課題に正面から取り組んでいる。

したがって両者の違いは、「どちらが正しいか」ではなく、「どの市場課題を先に解こうとしているか」の違いとして理解するのがよいだろう。

参考文献

Share this…

投稿日

カテゴリー:

,

投稿者:

Nobuyuki

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です