本年2月、電子インボイス推進協議会　代表幹事　岡本浩一郎氏、内閣官房情報通信技術（IT）総合戦略室　加藤博之氏、流通標準システム普及推進協議会（流通BMS協議会）事務局長 坂本真人氏より、電子インボイスの仕様の標準化の取組の基本的な考え方を伺った。
　今回、その取組の進捗状況も含め、加藤氏、坂本氏より、「標準仕様」のポイントについて語ってもらった。

※文中における意見、主張等に関する部分については、質問者及び回答者の個人的な見解に基づくものであり、所属した・所属する組織の公式な見解等ではありません。なお、内容等につきましては、令和3年5月末時点のものであり、変更等があり得ることも予めご理解願いします。

 

 

標準仕様ではデジタルを前提にした実務を実現する観点が重要

 

坂本氏
　まず、「電子インボイスの標準仕様」の策定方針について、基本的な考え方を教えてください。

 

加藤氏
　「標準仕様」のベースは「Peppol　BIS Billing 3.0」（ https://peppol.eu/what-is-peppol/peppol-profiles　specifications/ ）です。売り手が買い手に対して取引都度に提供する「電子インボイス」であれば、基本的にはそれで対応できるのではないかと考えます。したがって、日本の「標準仕様」のための「拡張」は必要最小限にとどめることが重要だと考えています。

 

 

坂本氏
　シンプルな形での標準化は重要なポイントだと考えます。将来、新たな法令対応等が求められるような場合、標準化しておけばその対応もシンプルです。ただし、標準仕様の中に特殊なことを盛り込んでしまうと、その分だけ個別対応が必要になります。システム的には、そういう個別対応はできる限り避けたいところです。標準化された電子インボイスがシンプルなものであれば、そのデータを処理する業務・会計システムの負荷も軽減され、さらなる生産性の向上も期待されますね。

 

加藤氏
　そうですね。海外では、Peppol対応のサービスについて、スマートフォンのアプリケーションを使い、請求データを入力するといった非常にハンディーなものもあります。そもそも、スマートフォンでの入力には、物理的な限界もあり、入力する項目等はシンプルであることが重要だと思っています。肝心なことは、ユーザーが請求データを入力するスマートフォンのインターフェイスはシンプルであっても、その入力されたデータを業務・会計システムが適切に処理できる仕組みとなっていることだと思います。この点は、今後、業務・会計システムベンダーが、Peppol対応を実現させていく中で、改めて考えてもらいたい視点でもあります。

坂本氏
　流通BMSでも、中小企業向けにスマートフォンのアプリケーションで必要最小限の情報を入力するだけでASPが提供するサービスに情報を送り、その他の必要とされる情報（商品名称や商品分類情報など）はASPであらかじめ管理している各種マスタを参照し付加して相対の企業に流通BMS標準のメッセージとして送付するサービスなどもあります。現状、業務遂行が円滑にできているからといって、その実務がデジタルを前提にしたときに最適なものなのか、今後の労働環境、労働人口減少などの影響も視野に入れて、改めて考える必要があるということですね。

 

加藤氏
　同じ考えです。また、標準仕様は、デジタルを前提にした実務を実現するために最適なものである必要があります。デジタルの世界で、「紙」を前提とした実務を無理に実現しようとすることは、効率化や生産性向上に資さないおそれがあります。また、そういう観点からは、現行行っている実務全てが標準仕様の中に取り込まれていくわけではないことも認識する必要があります。

 

 

「月締め請求」への対応可能性

坂本氏
　ところで、先ほど、売り手が買い手に対して取引都度に提供する「電子インボイス」であれば、Peppol対応が問題なく行えるのではないかとの示唆がありました。その点、流通BMSは、1か月間の取引をまとめて、月末に請求する仕組み（「月締め請求」とします。）が現状多いと思われます。それに対応できるのか不安になりました。いかがでしょうか。

 

加藤氏
　前回の座談会において、岡本氏より「月締め請求への対応は必須」である旨の発言がありました。そもそも、この「月締め請求」は、例えば、「複数の商品を一度に取引し請求する」場合とインボイスの対応は変わりません。要すれば、一定期間の取引を明細という形で、ラインレベルでどう記載するということだと思います。

 

坂本氏
　請求において、各取引の明細を持たないケースもあります。例えば、「取引番号」を記載するような対応です。そのような実務はサポートされていないのでしょうか。流通BMSを考えた場合、日々の取引情報（受発注や出荷の情報）は流通BMSでやり取りされ、請求だけ外部の事業者に委託しているというケースもあります。そのような場合、請求の中では、受発注や出荷情報と紐付けられた「取引番号」が記載されていることがあります。


加藤氏
　そのような場合には、例えば、ドキュメントレベル（請求レベル）やラインレベル（項目レベル）で「取引番号」を参照・記載するといった方法も可能です。前者であれば「Additional Document Reference（追加文書参照欄）」を、後者であれば「Item（取引内容欄）」や「Document Reference（文書参照欄）」を活用し、取引番号を参照・記載する方法が考えられます。

 

坂本氏
　流通BMSの一般的な実務もサポートされる方法があるということですね。

 

加藤氏
　繰り返しになりますが、重要なことは、「現行の実務がサポートされているか」ということではなく、「デジタル化」を前提にしたときに、そのやり方が最適解なのかを考えることです。例えば、先ほど言及がありましたとおり、「月締めの請求」において、各取引の明細まで「電子インボイス」で記載される必要があるのかということもあります。確かに、「紙」を前提にした場合、要すれば、「電子インボイス」を「書面出力」することを前提に考えれば、より詳細な情報を視覚的に認識できることの価値があるかもしれません。ただ、「デジタル化」を前提に考えれば、マシーンリーダブルであることが必要であり、「視覚的に認識できること」の優先度合いは下がるかもしれません。そういったことも考えながら、どういう情報が、どのような形でやり取りされることが最適なのか、これを機に考えてみることも重要かもしれません。

 

 

「紙」を前提とした実務、「月まとめ請求」の取扱

 

坂本氏
　ところで、流通BMSは既に「電子化」「デジタル化」された仕組みですので、「デジタル化」に適さない「紙」を前提にした実務のイメージがなかなかわいてこないのですが、どのような実務があるのでしょうか。

 

加藤氏
　これは先ほど申し上げた「月締め請求」と混同されて語られることが多いのですが、「月まとめ請求」というのがそれに当たると思います。例えば、取引都度に請求を行いつつ、さらに月末にそれらの請求をまとめて請求する、そういった実務を「月まとめ請求」と言うとします。

 

坂本氏
　同じ取引について、2度請求をするということですか。「電子化」「デジタル化」された仕組みではあまりない実務ですね。

 

加藤氏
　そうです。「電子化」「デジタル化」を前提とした場合、この実務にはあまり合理性がありません。それなのに、なぜ、そのような実務が行われるのか。それは「紙」を前提にしたとき、一定の合理性があるアクションだからです。

 

坂本氏
　どのような観点から合理的なのでしょうか。

 

加藤氏
　事業者の方からは「取引相手が請求書（紙）を紛失していると困るので念のため月末に請求書を再度送っている」との声が多く聞かれました。確かに、取引と支払いのタイミングが離れている場合（支払いサイトが長い場合）、取引都度に送付した請求書（紙）の紛失リスクやそれに伴う代金回収漏れのリスクも高まりかねず、そういう事態を回避するためのリマインドという意味では、支払いのタイミングにより近い段階で再度「月まとめ請求書（紙）」を送付するというのも合理的な行動かもしれません。

 

坂本氏
　確かにそうかもしれません。また、取引都度に請求を行ったとしても、支払いが一括されることも多いことを前提にすれば、そもそも「取引都度に請求を行う」ということが合理的なのかということですね。もちろん、経営・財務状況の把握の高度化・リアルタイム化を推進する観点から考えれば、取引都度の請求は望ましいのは言うまでもありませんが。また、「月まとめ請求書」について、さらに言えば、取引相手に金額を伝える必要性があるのであれば、請求という形をとる必要もありませんよね。

 

加藤氏
　そうですね。現状、「紙」「データ」を問わず「請求」には様々な情報が盛り込まれていると思います。デジタルを前提とした実務を考えるときには、それらの情報が「請求」の中に盛り込まれる必要性も少し考えていただく必要があるかもしれません。そのような観点から考えると、デジタルを前提とした「電子インボイス」の標準仕様は、情報項目をできる限り絞り、シンプルなものになってくるのかなと思っています。

 

 

 

「Peppolでサポートされていない」ということは「実現できない」ということではない

 

坂本氏
　請求以外のプロセスにおいて、請求に関連する情報をやり取りするという発想は、流通業界の中では既に実践されている部分があります。具体的には、請求データの修正のオペレーションです。現状、請求データの修正については、流通BMSのメッセージを再度送るのではなく、メールやFAXなどで、修正箇所や修正内容を伝達し、それぞれ手作業で補正することがあるようです。

 

加藤氏
　いわゆる修正インボイスの対応は、Peppolの中でも少し工夫が必要となります。修正インボイスの対応は、一般的には、①修正した上で電子インボイスを出し直す、②修正箇所のデータのみを提供する、の２つのパターンがあり得ます。両者にそれぞれにメリット・デメリットがあるところですが、Peppolでの対応としては、データ処理の利便性を重視する観点から、①の方法をルールとしたいと考えています。

 

坂本氏
　①はなかなかハードルが高いですね。例えば、請求システムが独立している場合であれば、請求を出し直すというプロセスも煩雑ではないと思いますが、販売管理システムと請求システムが一体となっているような場合には、単純に「請求だけ出し直す」というわけにはいきません。販売管理システムでの情報の修正から必要になり、処理に時間を要することが懸念されます。

 

加藤氏
　確かにその点は懸念されますね。ただ、発想を切り替える必要がありますね。手作業というアナログな対応が必ずしも悪いわけでなく、アナログとデジタルを組み合わせ、バランスを取ることで逆に効率化に資することもあります。修正対応の例であっても、修正だけはアナログ対応を残す、という判断もありだと思います。また、金額の修正であれば、値引き・追加料金の対応をベースに「翌月の請求の中で加減して対応する」ということもあり得るのではないかと思います。Peppolでも、ドキュメントレベル、ラインレベルで加減に対応できます。

 

 

令和3年度税制改正による電子帳簿保存法改正と電子インボイスの保存

 

坂本氏
　少し話がそれるかもしれません。バックオフィス業務の効率化・生産性の向上を目指すのであれば、単に電子インボイスをやり取りするだけでは必ずしも十分ではないと考えています。冒頭でも言及したとおり、提供した・提供された電子インボイスをどう処理するのか、そのデータの保存のあり方も含めて対応を考える必要があると思います。その観点から、令和3年度税制改正で電子帳簿保存法が改正されました。その改正内容の一つに「電子取引データを書面に出力して保存する方法の廃止」がありますが、この改正が電子インボイスの実務に与える影響について、ご意見をうかがえませんか。

加藤氏
　まず、電子インボイスは、仕入税額控除の適用を受けるためには、電子帳簿保存法に準じた方法で保存する必要があります。その観点から、電子帳簿保存法が求める要件等を理解しておくことは重要です。ただ、ご指摘の改正内容については、所得税・法人税の観点ですので、やや整理が必要です。

 

坂本氏
　具体的には、どう理解すれば良いのでしょうか。

 

加藤氏
　現状、電子取引データを書面に出力して保存する方法が許容されています。これは、電子帳簿保存法のスコープとなる所得税・法人税だけでなく、消費税制度においても然りです。しかしながら、令和3年度税制改正において電子帳簿保存法が改正され、令和4年1月1日以後、所得税・法人税の観点からは、電子取引データを書面に出力し保存する方法は許容されなくなりました。他方、消費税の仕入税額控除の適用の場面では、引き続き、提供を受けた電子インボイスを書面に出力し保存することも可能とされています。

 

坂本氏
　よくわかりました。要すれば、仕入税額控除の適用の観点からの保存という意味では、引き続き、書面に出力して保存する方法でも良いということですね。

 

加藤氏
　そのとおりです。ただ、所得税・法人税の観点からは、電子取引データを電子帳簿保存法に従い電子取引データを保存している一方で、消費税の仕入税額控除の適用という目的のみに、それを書面に出力して保存するという実務はあまり効率的な気はしません。「電子取引データの保存」という一つの実務の中で、「アナログ」と「デジタル」を混在させるのではなく、「データはデータで保存する」という一貫した対応が浸透していくことが期待されます。

 

坂本氏
　そうかもしれませんね。これまでは、法人税・消費税や所得税・消費税のいずれの観点からも書面に出力して保存する方法が許容されていたからこそ、そういう対応も合理性があったのかもしれませんが、法人税・所得税と消費税の対応が「泣き別れ」になるのであれば、どちらかに合わせた処理というのが合理的かもしれません。

 

 

加藤氏
　その際、電子インボイスの保存の仕方というのも考えてもらっても良いかもしれません。自社で独自のサーバーを用意し、そこで保存していくという方法も選択肢の一つかもしれませんが、例えば、改ざんができないなどの一定の要件を満たすクラウドを利用して保存をする（令和2年度税制改正で措置）などの対応も検討に値するのではないかと思います。電子インボイスを「提供する/提供される」という考え方から、「共有する」という考え方への変化です。

坂本氏
　そうですね。バックオフィス業務全体の効率化の実現という目的を考えれば、クラウドを利用したやり取り・保存というが現実的な話かもしれません。流通BMSにおいても、令和2年度税制改正により、データの保存場所に関して一定の要件を満たすクラウドを利用して保存する事が認められたのを受けて、ASP事業者がデータの保管と参照機能をサービス化する動きが出てきています。これによりユーザー企業の負担は減少することが期待できます。

 

両者
　今回も非常に勉強になりました。ありがとうございました。