日本版 Peppol 実現に向けた業務要件
2021 年 6 月 28 日
電子インボイス推進協議会

1. これまでの検討状況
電子インボイス推進協議会(EIPA)では、2021 年 1 月に標準仕様策定部会を組成し、Peppol をベースとした日本標準仕様(日本版 Peppol)の策定を内閣官房および OpenPeppol の協力を得て進めてきた。
具体的に策定作業を進めるにあたっては、標準仕様策定部会の中で、検討作業に一定の時間を費やすことができる会員をボランティアとして募集し、コアチームを組成した。コアチーム内部では概ね週一回の定例打合せ、また OpenPeppol とは概ね二週間に一度の定例打合せを実施している。
標準仕様の策定にあたっては、最初から詳細仕様の検討を行うのではなく、まずは日本の商慣習を確実にサポートするために、日本で必要とされる業務プロセスの整理から着手した。現時点では、整理された業務プロセスを踏まえ、それをカバーできるデータモデルの確立に取り組んでいる。
また、同時に、日本版 Peppol において利用されるコード体系の整理、また、ネットワーク基盤の要件の整理などにも取り組んでいる。

2. 日本版 Peppol でサポートすべき業務プロセス
Peppol の土台となっている欧州標準 EN16931-1 で定義されている 12 の Business process を検証し、日本の商慣習との Fit/Gap を分析した。結論としては、事前の想定通り、月締請求書など、合算型のインボイス(Summarized Invoice)がギャップであることを確認した。欧州等でも複数の納品書をもとに合算された合算型の請求書は存在するが、一般的とは言えない。このため、欧州で現状利用されているPeppol(以降、日本版といった接頭節なしに Peppol と表記する場合には、こちらを意味する)では、合算型の請求書はサポートされていない。
デジタルを前提として考えると、業務効率の向上と早期の業績把握を通じた経営のリアルタイム化の観点から、日本においても請求業務は合算型から都度型に変わっていくべきであると考える。しかしながら、
2023 年 10 月の時点において電子インボイスが一般的に利用される状態を目指すためには、一旦は概ね現状の業務プロセスのままでも電子インボイスを利用できるようにすべきである。このため、日本版
Peppol においては、合算型のインボイスをサポートすべきである。
日本の適格請求書としては、合算型インボイスとして、1) 合算請求書にその元となる納品書の明細を改めて書き出すパターン(以下パターン 1)、2) 合算請求書にはその元となる納品書の明細を記載せず、合算請求書とその元になる納品書の組み合わせで適格請求書を構成するパターン(以下パターン 2)の二つのパターンが認められている。日本版 Peppol においては、この二つのパターン(パターン 1、パターン 2)の双方をサポートすべきである。

© 2021 電子インボイス推進協議会

Page 1

3. 日本版 Peppol においてサポートすべき電子ドキュメント
日本で必要とされる業務プロセスを踏まえ、日本版 Peppol においてサポートすべき電子ドキュメントは少なくとも以下の通りである。以下に記載されていない電子ドキュメントについても、Peppol で利用可能なものについては、日本版 Peppol でも利用できるようにすることを目指す。例えば、買手における電子インボイスの処理状況を買手から売手に通知する Invoice Response の仕組みなどは、基本的にそのまま日本版 Peppol でも利用できることを目指す。
しかしながら、日本版 Peppol の稼働に向けては、まず以下の電子ドキュメントを整備することが最優先である。

3-1. 請求書
3-1-1. 都度請求書
適格請求書として基本となるものである。都度請求書は一つの納品書をもとに生成される(実務では納品書そのものは存在しないこともあるが、その場合には、納品書に相当するデータをもとに生成される)。
買手が都度請求書に基づいて支払いを処理する際には、その請求対象が納品済みであるかを確認することが必要であり、そのためには、都度請求書と納品書との紐付きが確立されている必要がある。
概ね Peppol で定義される Standard commercial invoice と同等であるが、一部の拡張は必要になるものと考える。
一例として、Peppol では、支払先の金融機関情報として金融機関コード(SWIFT コードや IBAN)および金融機関の所在地情報を持つ。一方で、日本においては、支払先の金融機関情報としては、一般的に銀行名・支店名・預金種別・口座番号を利用する。
日本版 Peppol においては、1) 支店名・預金種別といった項目を新設する、2) 所在地情報の項目に支店名や預金種別を埋め込むことを日本版のルールとして定める、3) 金融機関コード(例: 0005)、支店コード(例: 064)、預金種別コード(例: 1)、口座番号(例: 1234567)を 1 つのデータとしてパックし(例:000506411234567)、金融機関コードとして利用することを日本版のルールとして定めるといったいくつかの選択肢が存在する。どの対応方法が望ましいかは、OpenPeppol との協議によって、OpenPeppolの推奨を踏まえるべきであると考える。

3-1-2. 合算請求書
複数の納品書をもとに、20 日締め、月末締めなど所定のタイミングで合算されて生成されるものである(実務では納品書そのものは存在しないこともあるが、その場合には、納品書に相当するデータをもとに生成される)。
合算請求書にその元となる納品書の明細を改めて書き出すパターン(パターン 1)、合算請求書にはその元となる納品書の明細を記載せず、合算請求書とその元になる納品書の組み合わせで適格請求書を構成するパターン(パターン 2)の両方をサポートすべきである。
パターン 1 においては、納品書の明細を改めて書き出す際に、その明細がどの納品書に由来するかを追跡できるように、明細レベルで納品書との紐付きが確立されていることが必要である。これは買手が合算請求書に基づいて支払いを処理する際には、その請求対象が納品済みであるかを確認することが必© 2021 電子インボイス推進協議会

Page 2

要であり、明細レベルで納品書との紐づきが確立されていることによって、この作業を自動化することが可能になるからである。
基本的にはパターン 1 が中心になるものと考えるが、受発注業務等に業界 EDI を利用している事業者において、納品書は業界 EDI で受け渡す一方で、請求書は日本版 Peppol を利用するという場合を中心に、パターン 2 の利用も見込まれる。逆に言えば、パターン 2 を許容することによって、日本版
Peppol において複雑な納品書に対応することを避けることができる。
なお、いずれの場合においても、合算請求書のもととなる納品書と、合算請求書で消費税額にずれが発生しないよう、端数処理が必要となるが、その際には、法令で認められている端数処理としなければならない。
合算請求書のデータモデルは、都度請求書のデータモデルをベースとして策定されることを想定するが、どのように拡張するのかについては、Peppol の全体的な設計思想に基づくべきであり、OpenPeppolとの協議によって、OpenPeppol の推奨を踏まえるべきであると考える。

3-2. 納品書
日本版 Peppol においては、都度請求書と同一のデータモデルに絞って対象とする。これは紙で言えば、納品書と請求書がカーボンコピーになっているイメージである。
日本版 Peppol において納品書をサポートするのは、合算請求書(パターン 2)のように、納品書が適格請求書の一部を構成する場合、また、納品書に適格請求書として必要な事項が記載されていることを前提に、よりタイムリーな会計管理の観点から、納品書そのものを適格請求書として扱う場合があるためである。さらに、日本版 Peppol で納品書を扱えることによって、買手側で、日本版 Peppol だけで納品書と請求書の照合ができ、結果的に支払いの自動処理が可能になるためである。
なお、請求書と大きく異なるデータモデルは、業界 EDI によってカバーされることを想定する(つまり、日本版 Peppol におけるサポート対象としない)。この場合、納品書は業界 EDI で受け渡す一方で、請求書は日本版 Peppol の都度請求書もしくは合算請求書(パターン 2)を利用することが想定される。
納品書としての使用目的から、価格/金額がブランクになることを許容する。ただし、この場合は、適格請求書としての取扱いはできない。

3-3. 仕入明細書
日本版 Peppol においては、請求書(都度請求書および合算請求書)と同一のデータモデルのみ対象とする。内容としては基本的に請求書と同一だが、発行者と受領者が逆になることをサポートする。
日本版 Peppol における請求書と大きく異なるデータモデルは、業界 EDI によってカバーされることを想定する(つまり、日本版 Peppol におけるサポート対象としない)。

3-4. 口座残高情報(仮の名称)
日本の合算請求書では、前回請求時点での売掛残、前回請求以降の入金額、今回請求額、そしてこれらを通算した結果として今回請求時点での売掛残を表記することが一般的に行われている。
これは売手と買手が売掛残・買掛残の認識を共有するという意味で有益な情報ではあるが、商取引の© 2021 電子インボイス推進協議会

Page 3

売手が買手に対して、正確な適用税率や税額等を伝えると同時に、買手が仕入税額控除を得るために必要な証憑とするという適格請求書の位置付けにはそぐわない。
このため、日本版 Peppol では、口座残高情報(仮の名称)については、請求書からは分離した、独立した電子ドキュメントとして扱うことを想定する。用途から考えると、Peppol に存在する”Statement”をベースとすることが望ましいと考えられる。一方で、Statement には、期間中の移動情報はあるが、期初時点での残高情報(Beginning balance)がない、また、売手から買手への一方通行になっているなどの制約があり(売手から買手というのが一般的な方向だが、仕入明細書を利用している事業者のように、買手側が実務上の管理主体となっている場合には、買手から売手に提示されることもある)、一定の拡張は必要になるものと考えられる。
なお、電子インボイスは基本的にはデジタルデータとしてシステムで自動処理することを想定するが、人間が見る場合には、複数の電子ドキュメントとして受け渡される請求書と口座残高情報を合成して、従来型の合算請求書のように表示することも可能である。

4. その他の要件
4-1. 税抜表記/税込表記
現状の Peppol では税抜の表記のみサポートしている。日本版 Peppol では、当初は主に B2B 取引が中心となる適格請求書を扱うことを目指すことから、日本版 Peppol の稼働時点においては、税抜の表記のみをサポートすることを許容する。
しかしながら、事業者が消費者のように店頭で資材を購入し、適格簡易請求書(レシート)を受領することも一般的にありうる(従業員が店頭でレシートを受領したものを立替経費として処理することを含む)。将来的には適格簡易請求書を電子レシートとして日本版 Peppol を経由して受領できるようになれば、事業者としては適格請求書等のデジタルでの一元管理を実現できることになり、さらなる業務効率化が見込まれる。
なお、適格簡易請求書は、交付先が特定された段階で、適格請求書になりうるので、電子インボイスとして取り扱える(=交付先が特定されている)段階で簡易ではなくなると考えられる。その際、レシートについては、小売取引において総額表示が義務付けられていることもあり、買手の価格の認識が税込が一般的となっていることが想定され、そのため適格(簡易)請求書であり、それを扱う日本版 Peppol についても、将来的には税込表記もサポートできるようにすることが望まれる。

4-2. 修正インボイス
日本版 Peppol においては、インボイスの修正をサポートする必要がある。Peppol では、1) 修正対象となるインボイスを無効化した上で、新たに修正されたインボイスを発行する方式、2) 修正対象となるインボイスの特定の項目を修正する方式、の大きく二つの方式がサポートされている。
日本版 Peppol においては、仕組みの簡素化の観点から、1) 修正対象となるインボイスを無効化した上で、新たに修正されたインボイスを発行する方式を基本とすべきと考える。
この方式においては、既に発行されたインボイスを無効化すること、その上で、無効化された当初のインボイスへの紐づき情報を保持し、修正されたインボイスを発行することになる。既に発行されたインボイ© 2021 電子インボイス推進協議会

Page 4

スを無効化する仕組み、また、無効化された当初のインボイスへの紐づき情報の保持の仕組みについては、今後検証が必要である。

4-3. 適格返還請求書
日本版 Peppol においては、適格返還請求書をサポートする必要がある。Peppol では、Credit Noteという電子ドキュメントが存在するため、これを活用することが考えられる。
ただし、どのような場合には、請求書における値引きとして処理をすることが認められるのか、どのような場合には、Credit Note という別の電子ドキュメントとして処理することが必要になるのかなど、業務上の扱いについて今後検討が必要である。

4-4. 免税事業者の扱い
日本版 Peppol は、インボイス制度という法令改正に対応するためだけに構築するのではない。日本版Peppol は、請求書を電子インボイスとして受け渡すことによる業務効率化というメリットの実現を目指す。
業務効率化というメリットは、課税事業者だけでなく、免税事業者にも見込めることから、日本版 Peppol は、課税事業者だけでなく、免税事業者も利用できる仕組みとすべきである。
つまり日本版 Peppol は、適格請求書だけでなく、免税事業者によって発行される区分記載請求書もサポートできる必要がある(なお、課税事業者であっても、登録事業者とならない場合には、やはり区分記載請求書を発行することとなる)。
区分記載請求書は、登録事業者によって発行されない、よって登録番号が記載されない。また、仕入税額控除の経過措置(6 年間、80%もしくは 50%控除)があるために、実際には存在しない仕入税額をどのように扱うかは慎重な検討が必要である。
対応方法としては、区分記載請求書を適格請求書とは別種の電子ドキュメントとして定義し、登録番号の記載を必須としない、もしくは、登録番号の項目そのものを削除するという方式も考えられる。しかしこれは、全体の仕組みを極力シンプルなものにするためには、必ずしも最適な解ではないと考える。
十分な議論は必要であるが、登録事業者以外にも何らかの番号を発番することも検討すべきである。
例えば、”X123456789123”のように、頭の文字を”T”以外にすることで、登録事業者かどうかを容易に識別できるようにすることも可能である。代替案としては、”T0000000000000”は、免税事業者を示す特殊な登録番号とするということも可能であると考える。なお、後述の事業者を識別する仕組みの観点からは、”T0000000000000”のように複数の事業者で共有されたコードではなく、”X123456789123”のように事業者固有のコードの方が望ましい。
実際には存在しない仕入税額をどのように表記するかについては、将来的にどのようになるかを出発点として考えるべきではないか。将来的には免税事業者からの仕入税額控除は認められないということを考えると、日本版 Peppol においては、税額はあくまでも”0”という表記とすべきではないか。この場合でも、当該電子インボイスが免税事業者によるものであることがシステム上判別できれば(判別できるようにすることは前述の通り)、受領側のシステムにおいて、1) 取引の仕訳に際し、本体価格の 10/110 もしくは8/108 を計算し、その 80%ないし 50%を仮払消費税として計上する、もしくは 2) 消費税申告書を作成する段階で、本体価格の 10/110 もしくは 8/108 を計算し、その 80%ないし 50%を仕入税額として加算する© 2021 電子インボイス推進協議会

Page 5

処理を行うことが考えられる。
この方式を採用した場合には、日本版 Peppol で扱われる免税事業者による電子インボイスは、当初から一貫した表記となる。経過措置の適用時期にあわせて、受領側のシステムにおいて、経過措置の適用を制御するだけである。

4-5. その他
現状の標準仕様策定部会コアチームで業務要件を定義するだけの知見がないため、卸売市場、農協、輸出入等に関する業務要件は現段階で検討していない。今後タイミングをみて、業務要件を定義できる関係者を巻き込んで検討すべきである。

5. コード体系
Peppol で利用されるコード体系について検証を実施しているが、Peppol の利用を妨げるほどの大きなギャップはないものと考える。一方で、Peppol で利用されるコード体系は CEFACT に準拠するものが多く、追加が必要な場合には、CEFACT への働きかけが必要になる。
受発注業務でも利用されるコードが複数存在することを考えると、既に CEFACT との交渉窓口をもつ中小企業共通 EDI を活用すべきであると考える。具体的には、受発注業務でも利用されるコードについては、その整備は、一定の期限を設定した上で、中小企業共通 EDI に委ねるべきであると考える。

6. 事業者を識別する仕組み
6-1. 事業者を識別する仕組み
事業者が Peppol を利用するにあたっては、事業者を一意に識別できるコードが必要である。これは、管理の手間を低減する観点から、全く新規のコードではなく、既に存在するコード(例えば法人番号や登録番号)、もしくは既に存在するコードに特定の処理を加えることで容易に生成できるコード(例えば登録番号の頭に JP を付加する)であるべきである。
ここで既に存在するコードとしては、法人番号や登録番号が考えられる。しかし、法人番号は法人にのみ存在し、個人事業主には存在しない。また、登録番号は課税事業者には存在するが、免税事業者には存在しない。このため、どちらにしても、免税事業者である個人事業主はカバーできない。
この問題を解決するために、一つのやり方としては、個人事業主にも疑似的な法人番号を発番することを検討すべきと考える。その上で、課税事業者の登録番号は、法人でも個人事業主でも ”T123456789123” 、 免 税 事 業 者 の ( 疑 似 的 な ) 登 録 番 号 を 、 法 人 で も 個 人 事 業 主 でも”X123456789123”とすれば、全ての事業者を一意に識別できるコードとなる。また、頭の”T”もしくは”X”
によって課税事業者かどうかが容易に判別できると同時に、同一の事業者が課税から免税に、あるいは免税から課税に移行した場合でも、コードの一貫性を維持しやすい。
なお、事業者を識別する仕組みとあわせ、識別コードから、当該事業者の基本的な属性および課税事業者としての登録の有無をオンラインで照会できる仕組みを国として提供することを求めたい。これは、事業者がインボイスに基づいて仕入税額控除を計上する際に、確かに課税登録事業者によって発行され© 2021 電子インボイス推進協議会

Page 6

たインボイスであることを確認することを求められるのであれば、必須である。
また、このような照会の仕組みは、サービスプロバイダーが事業者を受け入れる際に行う KYC(本人確認)にも利用できる(KYC については後述)。ただし、個人事業主に関する情報については、プライバシーの観点からどこまでの情報を照会できるようにするか、慎重な検討が必要である。

6-2. 事業所を識別する仕組み
事業者によっては、複数の事業所もしくは事業部門をもち、インボイスを受領する際に、事業所もしくは事業部門を特定することを求めるケースがある。
Peppol ではないが、イタリアの電子インボイスの仕組み(eInvoicing)では、インボイス発行元/送付先を特定するのは、このために発行される Delivery code を用いる。もともとイタリア歳入庁は VAT 事業者には VAT number(個人には Fiscal code)を発行しているが、eInvoicing では Delivery code を利用することによって、一事業者が事業によって複数の Delivery code を使い分けられるようになっている。
日本版 Peppol においては、一事業者を一意に識別するコードが必要であることは 6-1 で述べた通りであるが、同時に、事業者の中で事業所もしくは事業部門を特定できるコードを利用することも可能にすべきであると考える。これはいわば、事業者が電話の代表番号であるとすると、事業所もしくは事業部門がそれぞれ内線番号を持つことを可能にするということである(逆に言えば、事業所もしくは事業部門がそれぞれ直通番号を持つ必要はないと考える)。

7. ネットワーク基盤
Peppol のネットワークは、主に参加する事業者(4 コーナーモデルにおける C1/C4)とサービスプロバイダー(C2/C3)で構成される。

7-1. C1/C4 に関する参加要件
多くの事業者がより気軽に日本版 Peppol を利用し、業務効率化を実現するために、C1/C4 に求められる要件は極力最小限とすべきである。e メールが、事業者にとって欠かせないコミュニケーションツールとなったように、日本版 Peppol が全ての事業者にとって欠かせない商取引のツールとなるべきであり、そのためには、日本版 Peppol を利用することは、インターネットに接続し、e メールをやり取りできるようになるのと同様に容易なものとならなければならない。一方で、e メールにおける Spam メールが多発するような状況は避けなければならない。
OpenPeppol は C1/C4 の管理はサービスプロバイダーに委ねており、C1/C4 に対し特段の参加要件を設定していない。日本版 Peppol では、Spam 対策として例えば、6 章で記述した事業者識別コードを取得することを条件に、原則として希望する事業者は全て参加可能とすべきである。
なお、必要に応じ、買手(C4)によって、売手(C1)により厳格な要件を課すことも可能であると考える。例
えば公共調達(買手である C4 は行政機関)において、C1 に対し e シールのような発行元の証明を求めることも考えられる。
現在 OpenPeppol では、C2/C3 がユーザーである C1/C4 に対し、所定の KYC を行うことを義務付けることを検討中である。現在のドラフト案では、C1/C4 の法的な登録がある名称、住所、登録番号などをC2/C3 が確認し、その正確性に責任を負うとされている。日本版 Peppol においては、C2/C3 に過重な© 2021 電子インボイス推進協議会

Page 7

負担を強いないよう、また手間の観点から C1/C4 の参加意欲をそがないよう、適切な身元確認レベルの検討が必要である。C1/C4 の KYC において、6 章で記述した「識別コードから、当該事業者の基本的な属性および課税事業者としての登録の有無をオンラインで照会できる仕組み」で C1/C4 の属性を確認でき、KYC の要件が満たされることが望ましい。

7-2. C2/C3 に関する要件
C2/C3 は、Peppol のネットワークに直接アクセスできる存在であり、そのために C2/C3 には PEPPOLPKI から電子証明書が発行される。C2/C3 間の通信メッセージは、電子証明書を利用し、暗号化されて送受信される。このため C2/C3 については、システム全体の信頼性を担保するため、OpenPeppol が求める参加要件をベースとして、一定の参加要件は課されるべきであると考える。一方で、多くの事業者がより気軽に日本版 Peppol を利用し、業務効率化を実現するためには、C2/C3 の選択肢が多いことが求められる。そのため、C2/C3 の参加要件が過重なものとならないように留意が必要である。
OpenPeppol では、C2/C3 に対し、一定の参加要件を課しており、これをもとに各国の PA が審査することとなっている。日本版 Peppol では、OpenPeppol による参加要件が、C2/C3 の選択肢を増やす上で過度な制約にならないか検証が必要である。また、各国の PA は C2/C3 に対し、OpenPeppol が求めるものとは別の参加要件を課すことが可能である。しかしながら、C2/C3 の選択肢を増やし、ひいては日本版 Peppol の利用を促進する観点から、日本独自での C2/C3 の参加要件を課すことには慎重であるべきと考える。

8. 今後の進め方
8-1. OpenPeppol との協議を必要とするもの
3 章を中心に、Peppol をベースとして、日本版 Peppol にどのように拡張するかについては、まず日本側から要件として提示した上で、OpenPeppol より実現方法の提案を受けるべきである。これは日本版
Peppol は、あくまでも Peppol の設計思想に基づいた拡張とすべきであり、Peppol の設計思想を最も深く理解しているのは OpenPeppol であるからである。

8-2. 日本側が検討の中心となるべきもの
4-4、6 章、7 章は、日本国内における意思決定が必要とされる要件である。日本版 Peppol において無理なく実装できるように OpenPeppol のアドバイスを求めるべきであるが、基本的には、日本側(主体は日本における PA であるデジタル庁であり、その前身である内閣官房 IT 室)においてどうあるべきかを早急に検討の上、結論付ける必要がある。

8-3. 一定の時間をかけて検討すべきもの
4-1 の税込表記は大きな課題であり、短期的な課題解決は期待できない。まずは税抜表記に絞って日本版 Peppol を稼働させることを優先すべきと考える。税込表記は、Peppol の設計思想にも深くかかわる部分であり、OpenPeppol と時間軸を設定した上で、OpenPeppol 主導によって対応方法を検討すべき© 2021 電子インボイス推進協議会

Page 8

である。

9. その他
本ドキュメントの趣旨である「日本版 Peppol 実現に向けた業務要件」から外れるが、日本版 Peppol を実現し、なおかつ日本版 Peppol が広く利用されるようになるためには、政府が公共調達において日本版Peppol を積極的に活用する姿勢を早期に示し、なおかつ実際に活用することが必要であることを申し添えたい。
(EOD)© 2021 電子インボイス推進協議会

Page 9