ちょっと話題の記事

本当に怖い軽減税率対応 by @masaru_b_cl #devio2020

2019年10月1日より、新たな消費税法、通称「軽減税率」がスタートしました。我々事業開発部が開発する prismatix https://prismatix.jp というプロダクトでも、軽減税率対応を行いました。その対応の中で向き合った、課題と取り組みについてご紹介します。
2020.07.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

事業開発部の高野です。2020/6/17 - 2020/7/7に開催されたオンラインイベント Developers.IO 2020 CONNECT は、お陰様で盛況のうちに終了となりました。そんな中、私もDay 5「ビジネスとマネジメント」にて、「本当に怖い軽減税率対応」というタイトルでビデオセッションを行っていました。

本エントリはその内容を元に一部再構築したものです。軽減税率という制度が与えるインパクトがどのようなものであったのか、赤裸々に紹介しています。ぜひご覧ください。

本当に怖い軽減税率

本当に怖い軽減税率対応というタイトルで、クラスメソッド事業開発部の髙野が発表します。

今日お話することは、軽減税率対応の光と闇についてです。

2019年10月1日より、新たな消費税法、通称「軽減税率」がスタートしました。我々事業開発部が開発する prismatix というプロダクトでも、軽減税率対応を行いました。その対応の中で向き合った、課題と取り組みについてご紹介します。

prismatixの簡単な紹介

動画 0:36

本題に入る前に、我々のプロダクトである prismatix について、かんたんに紹介させてもらいます。

prismatixは、EC(電子商取引)、CRM(顧客管理)に特化したAPIプラットフォームです。各機能はマイクロサービスとして開発され、AWSの機能を活用したクラウドネイティブな実装となっています。クラスメソッドのB2B自社サービスとして開発を行っています。

EC/CRMプラットフォームというのがどういうことか、もう少し詳しく説明します。

EC/CRMを実現するには、注文、商品、在庫、顧客管理等の機能が必要です。従来はこれらの機能は、各サービスで必要な店舗用システム、ECサイト、スマホアプリなどのプラットフォームごとに作り込まなければなりませんでした。これには相当のコストが掛かりますし、汎用的なパッケージを導入したとしても、事業者ごとに必要な機能は違うため、無駄な機能も抱き合わせでついて来てしまうということがありました。

そこで、我々が開発・提供するprismatixでは、注文、商品、在庫、顧客管理などの機能をREST APIとして提供することで、各プラットフォームから統一したインターフェイスで必要な機能を利用できるようにしています。また、それぞれの機能を独立したマイクロサービスとして提供しているため、事象者は必要な機能のみ利用することで、コストの削減が可能です。

より詳しい情報については、弊社塩谷のブログエントリを参照ください。

自己紹介

動画: 2:16

ここで改めて自己紹介です。新潟県長岡市在住で、在宅のフルリモートワーカーをしている「高野 将(TAKANO Sho)」といいます。Twitterなどでは、@masaru_b_clという名前で活動しています。

現在私は事業開発部でprismatixの注文系マイクロサービスの開発リーダーをしています。

よって、今回の話の主役も、prismatixの「注文」「カート」といった機能に絞って、どのように軽減税率対応を行ったのかについて、詳しくお話できればと思います。

免責事項

動画: 2:55

それでは、実際にどのように軽減税率に対応していったかについて順にお話していこうと思いますが、その前に1点注意です。

本セッションの内容の正確性には万全を期していますが、「消費税法」というものを扱う性質上、完全とは言えません。よって、ご自身のプロダクトに本セッションの内容を適用する場合、必ず一次情報である国税庁や財務省のサイトなどを参照するようにしてください。

また、必要に応じて税理士への相談なども行うようにしてください。

軽減税率のおさらい

動画: 3:21

それでは、最初に軽減税率制度についておさらいしておきましょう。

軽減税率制度とは、簡単にまとめると次のようになります。
(No.6102 消費税の軽減税率制度の実施 | 国税庁より)

  • 2019年10月1日より消費税税率を 10% にする
    (これを通常税率と呼ぶ)
  • ただし、特定の品目は消費税率を 8% に据え置く
    (こちらを軽減税率と呼ぶ)
  • 軽減税率の対象品目
    • 飲食料品 (食品表示法に規定する「食品」)
    • 新聞

ただし、飲食料品については、外食・ケータリングは贅沢品とみなされ、通常税率の 10% が適用されます。

つまり、どういうことかというと、同じ品目でも異なる取引では違う税率になる可能性があります。また、1つの取引でも複数の税率が混在する可能性もあります。

したがって、事業者においてはそれぞれの取引を 税別に区分して 帳簿に記載する義務が発生します。

prismatixでの軽減税率対応

動画: 4:37

軽減税率の制度について大まかにわかったところで、いよいよ我々のprismatixでどのように軽減税率に対応したかについてお話していきましょう。

prismatixでは 取引の税別計算・記録 を行えるように対応しました。それに対して、対応しなかったものもあります。

それは、各品目が通常税率、軽減税率のどちらであるかを判定することです。

では、どうして税率の判定処理をしないのでしょうか。もちろん「面倒くさいから」ではなく、各品目の税率は 事業者のさじ加減 で決まる部分が多すぎるためです。

軽減税率クイズ

動画: 5:27

「事業者のさじ加減」がどういうものかわかっていただくため、ここで様々なケースで各品目が軽減税率、通常税率のどちらであるか、簡単なクイズ形式で紹介していきます。

簡単な問題からいきましょう。最初は「野菜」です。これは軽減税率、通常税率のどちらでしょうか?

答えは軽減税率です。これは簡単だったと思います。

次は「ビール」です。こちらはどうでしょう?

ビールは通常税率でした。ビールなどの「酒類」は「食品表示法に規定する『食品』」ではないため、通常税率になります。

今度はビタミン剤などの「サプリメント」を考えてみましょう。

答えは軽減税率です。サプリメントを含む「栄養機能食品」や「特定保健用食品」は、食品扱いなので軽減税率になります。

だんだん難しくなります。栄養ドリンク―例えばリポ○ビタンDといったものがあります―はどちらでしょう?

答えは通常税率です。多くの有効成分を含んだ栄養ドリンクなどの「医薬部外品」や「医薬品」は、食品ではないという扱いのため、通常税率になります。

栄養ドリンクと似ているエナジードリンク―レッド○ルやオロ○ミンCといったもの―はどうでしょう?

答えは軽減税率です。エナジードリンクの多くはカフェインなどの成分を含んではいますが、「清涼飲料水」でありこれは食品扱いなので、軽減税率になります。

今度は少し視点を変えて、「食品」と「それ以外」が一つになったもの、例えば「おもちゃ付きラムネ」のような食玩を考えてみましょう。

この場合、実は簡単には税率が決まりません。まず、「食品」と「それ以外」が一つになったものを一体資産と呼びます。そして、一体資産の場合、全体の税抜の価格のうち、食品分が2/3以上であれば、それは軽減税率です。

反対に、食品分が2/3未満であれば、通常税率になります。

次に一体資産の別バージョンで「鬼のお面がついた高級な恵方巻きロール」といったものを考えてみましょう。

先程と同様、こちらも一体資産なので、基本的なルールは一緒です。ただし、高級なものの場合、その価格が問題になります。新税法のルールでは、税抜価格が1万円以内なら軽減税率です。

しかし、税抜価格が1万円を超える場合、それは贅沢品とみなされ、通常税率の対象になります。

「買い方」に視点を変えて見ましょう。ファストフード―マクド○ルドなど―で食品を買うケースを考えます。

まず、テイクアウトやドライブスルーなど、持ち帰りの形式は、他の食品と変わらず軽減税率です。

ただし、店内飲食(イートイン)の場合、通常税率の対象になります。しかし、話はこれで終わりません。

事業者によっては販売の手間などを考え、イートインだとしても顧客には軽減税率で販売し、通常税率との差額を事業者が負担するという戦略を取る場合があります。この場合、どんな買い方でも軽減税率として扱います。

全部で8問やってきましたが、いかがでしたでしょうか?どちらの税率となるのか、想像と違っているものもいくつか合ったのではないかと思います。

これまで見てきたように、軽減税率かどうかは、簡単には決まりません。飲食料品かどうか、一体資産であれば食品分の価格の割合が軽減税率の対象範囲内であるか、外食かどうか、イートインを外食として扱うかどうかなど、多くの条件が絡み合っています。

現実として、大手コンビニ、ファストフードなどではイートインも軽減税率として扱うという動きが出てきているそうです。

参考:
企業側の地力の強さが物を言う:コンビニ、イートインでも8%常態化 | ビジネスジャーナル
https://biz-journal.jp/2019/10/post_121493_3.html

つまりお客さん同士のトラブルこそ懸念されるのです。こうしたトラブルを防ぐために、マクドナルドやケンタッキーなど体力のあるファーストフード店は、テイクアウトもイートインも一律8%で会計しています。しかも、イートインの商品の本体価格(税抜価格)は、増税前より値引きしています。店としてはレジのスピードアップにつながるし、お客もお得で会計も単純です。店内で食べようが持ち帰ろうが気兼ねすることなく安心して食事を楽しめます。店もお客もお金をめぐってトラブルを起こしたくないのです。

「軽減税率かどうかの判定処理」がいかに「事業者の都合」に左右されるか、わかっていただけたと思います。

汎用ECプラットフォームであるprismatixは、こういった事業者の都合よりも、もっと本質的なところに注力すべきです。このような視点で「何が最低限できないといけないのか?」を考えると、それが 取引の税別記録・計算 ということになります。

言い換えれば、事業者が処理するための「容れ物」さえ用意してあれば、後は如何様にでもできるということです。容れ物を用意した後、もし汎用的なものがあれば、その時取り入れればよいのですから。

取引の税別記録・計算

動画 10:00

「何をやるのか」についてお話してきましたので、いよいよ「どうやるのか」について詳しくお話をしていきましょう。

最初に税別に扱わなければならないものが何なのかを考えていきましょう。商品はもちろんですが、その他にも「ギフトラッピング」などの付帯作業、配送料、商品割引、クーポン割引、ポイントなど、取引に必要なすべてを税別に扱わなければなりません。

しかし、それぞれについて説明しているとややこしくなってしまいますので、このエントリでは商品に絞って説明をします。他のものは、また別のエントリで紹介できればと思います。

Before 軽減税率

動画 10:38

はじめに、軽減税率対応前はどのように取引を記録していたかについて説明します。

このレシートのような取引を行った事を考えましょう。

軽減税率対応前は「税率を持たずに税抜/税込価格、金額で保持」していました。

prismatixの注文サービスでは、一つの取引を注文と呼び、orderというリソースで管理しています。また、取引の明細(注文明細)はorder_detailsというリソースで管理しています。そして、注文明細は商品を取引する際の最小単位であるSKU(Stock Keeping Unit)ごとに記録します。そして、SKUの価格を税抜、税込ごとに管理することで、軽減税率対応前は「税率」を扱っていませんでした。

各項目とその役割は次のとおりです。

  • order
    • order_details: 注文明細
      • sku_code: SKUを一意に表すコード
      • price_ex_vat: SKUの税抜価格
      • price_in_vat: SKUの税込価格
      • quantity: 数量
      • amount_sku_ex_vat: SKUの税抜金額
        • price_ex_vat * quantity
      • amount_sku_in_vat: SKUの税込金額
        • price_in_vat * quantity
    • sku_ex_vat: SKUの税抜合計金額
      • SUM(order_details[].amount_sku_ex_vat)
    • sku_in_vat: SKUの税込合計金額
      • SUM(order_details[].amount_sku_in_vat)
    • adjustment_ex_vat: 税抜調整金額
    • adjustment_in_vat: 税込調整金額
    • total_ex_vat: 注文の税抜合計金額
    • total_in_vat: 注文の税込合計金額

(vat: Value Added Tax、直訳は付加価値税、いわゆる消費税のこと)

このとき、注文の税抜/税込金額を計算するには、注文明細のSKUの税抜/税込金額を集計すれば良いと思うかもしれません。しかし、単に集計するだけでは、注文全体で見ると税抜額と税込額にずれが出てしまうことがあります。今回の例では次のように-5円の差が出ます。

  • 税抜額合計: 744円 + 139円 + 224円 = 1,107円
  • 税込額合計: 800円 + 150円 + 240円 = 1,190円
    • 1,190円の税抜額は 1,190 / ( 1 + 税率8% ) = 1,102円
    • 税抜額合計と5円の差がある

その差を調整するのが税抜/税込調整金額です。税込合計金額と税率から計算した本来の税抜合計金額を、prismatixのAPIを利用するユーザー側(以下フロント(エンド)と呼ぶ)で計算してもらい、その差(先程の例では-5円)をorder.adjustment_ex_vatにセットすることで、注文全体の金額のつじつまを合わせていました。

こうすることで、税抜合計金額と税込合計金額が決まります。消費税額が欲しい場合は、この税抜合計金額と税込合計金額の差をフロントで計算すればよいのです。

軽減税率対応前をまとめましょう。

まず、税率はprismatixとしては管理していませんでした。そのため、注文明細では税抜/税込価格を保持しています。そして、注文明細の金額は価格に数量を掛けて計算しています。

注文には注文明細の税抜/税込金額を積み上げてセットします。

ただ、そのままだと注文全体としての税抜/税込金額のズレが出てきてしまうので、税抜/税込の調整金額を使い、フロントから差額を調整していました。

注文の消費税額はフロントが税抜/税込合計金額の差を計算して導出できるので、項目としては保持していません。

After 軽減税率

動画 13:56

軽減税率前のprismatixの注文データの持ち方を踏まえて、今度は軽減税率対応後について見ていきましょう。

軽減税率対応後のレシートはこのようになります。先ほどの軽減税率対応前に比べると、何箇所か違うところがありますね。大きな3点について順に説明します。

まず、軽減税率の対象となる品目がわかるような表示が義務付けられています。これは、明細に「軽減税率対象」と書いてもいいですし、このレシート例のようにマークで表記し、「マークしたものは軽減税率対象である」という説明を書くこともできます。

次に、税率ごとの対象品目の金額の小計の表示も必要です。

最後に、税率ごとの消費税額の表示も必要です。この税額は、先程の税率別の金額小計から、税率を使って計算します。

これらの違いを元に、実際のデータの持ち方を見ていきましょう。

注文明細から見ていきます。

注文明細には、軽減税率対応前にはなかった、通常税率、軽減税率などの税の種類を表すためのtax_code、そして実際の税率であるtax_rateを追加しました。この対応により、フロント側ではtax_codeが軽減税率のものかどうかを判断して、軽減税率対象の表示を行えるようになります。 *1

また、注文明細には現れていませんが、商品の価格も税別に管理しています。これにより、同じ品目でも通常税率、軽減税率両方の価格をシステムとして保持することが可能になります。

次に、税別の小計部分を見てみましょう。この箇所には、税別明細order_vat_detailsという名前の項目を注文データに追加しました。

まず、各品目の税抜、税込金額sku_ex_vat/sku_in_vatおよびSKU他の税込金額を合算した税込小計金額subtotaL_in_vatを注文明細などからtax_code別に集計してセットします。

  • sku_in_vat = SUM(order_details[].amount_sku_in_vat)
  • subtotal_in_vat = SUM(sku_in_vatなど各種in_vat)

次に税込小計額とtax_rateから、税抜小計額subtotal_ex_vatを計算します。計算式は次のとおりです。

  • subtotal_ex_vat = subtotal_in_vat / ( 1 + tax_rate )

このsubtotal_in_vatsubtotal_ex_vatの差が、税率ごとの消費税額になります。

  • 消費税額 = subtotal_in_vat - subtotal_ex_vat

なお、このままだと、税抜小計額と各品目の税抜金額を集計した値にズレが出てしまいます。これを自動で調整するため、税抜消費税調整額tax_adjustment_ex_vatを計算します。

  • tax_adjustment_ex_vat = subtotal_ex_vat - SUM(sku_ex_vatなど各種ex_vat)

最後に注文です。

軽減税率対応前は、注文の合計金額tatal_ex_vattotal_in_vatは、単にSKUなどの金額の積み上げでした。しかし軽減税率対応後は、これを税別明細order_vat_detailsの税別小計金額subtotal_ex_vatsubtotal_in_vatを集計してセットするよう変更しました。

  • total_ex_vat = SUM(order_vat_details[].subtotal_ex_vat)
  • total_in_vat = SUM(order_vat_details[].subtotal_in_vat)

また、税別の税抜消費税調整額も集計してセットします。

  • tax_adjustment_ex_vat = SUM(order_vat_details[].tax_adjustment_ex_vat)

以上で、レシート例に示した内容を、余すことなく記録できるようになりました。

軽減税率対応後をまとめましょう。

まず、一番大きな変化は、これまで管理していなかった税率税の種類を記録するようになったことです。それに伴い、商品などの価格も税別に管理するようになりました。

次に、取引に含まれる金額を税別に集計して税込小計金額を計算し、そこから税率を使って税抜小計額を計算するようになりました。先程は触れていませんでしたが、この税抜小計額を計算するとき、切り上げ、切り捨て、四捨五入などの端数処理が一度入ります。

こうやって計算した税抜小計金額と、各税抜金額を積み上げた金額にはズレが起きます。このズレは税抜消費税調整額を計算することで、自動で調整するようにしました。

以上が軽減税率対応の基本的な部分です。

消費税の端数処理

動画 17:42

さて、軽減税率対応前にはやっていなかった税率を用いた税計算を行うようになり、そこには端数処理が一度入るという説明をしました。

ここで一つ疑問が生じます。この端数処理方法は、法律で決まっていないのか、ということです。

この答えは事業者に一任されている、になります。つまり、切り上げ、切り捨て、四捨五入など、どの端数処理方法でも良いのです。 *2

端数処理方法が事業者に一任されているとはいえ、最低限守らなければならないルールも存在します。それは端数処理のタイミングについてです。

消費税の端数処理は、税別に1回だけ許可されています。つまり、商品一つごとに端数処理をしてはいけません *3し、商品の明細単位でも端数処理をしてはいけません。また、同じ税率に対して複数回の端数処理を行ってもいけません。

この内容は、財務省が公開している適格請求書等保存方式 *4についての資料に記載されています。

適格請求書保存方式の導入 - 消費税の軽減税率制度等に関する資料 : 財務省

この資料の中には、端数処理は一請求書あたり、税率区分ごとにそれぞれ一回行うことと記載されており、どの端数処理方法を使うかについては取り決めがありません。よって、どの方法で処理しても良いことになるのです。

この情報を元に、prismatixでも税率ごとに一回、税込小計金額から税抜小計金額を計算するときに端数処理(既定は切り上げ)を行っています。 *5

端数処理方法についてはわかりましたが、もう一つ疑問が出てくると思います。我々は「税込額から税抜額を計算する」という方法をとっていますが、「税抜額から税込額を計算する」のはだめなのでしょうか?

実はこちらも事業者に一任されています。やりたければ、税抜額から税込額を計算しても構いません。

ただ、我々は税込額から税抜額を計算する今の方法のほうが、面倒が少ないと考えています。それは、商品の価格について、総額表示の義務があるためです。

総額表示の義務とは、「消費者向けに商品の価格を提示するときには、税込の価格を表示しなければならない」というものです。

No.6902 「総額表示」の義務付け|国税庁 https://www.nta.go.jp/taxes/shiraberu/taxanswer/shohi/6902.htm

これにより、税抜価格から計算した税込価格を表示すると、税抜小計金額から計算した税込小計金額と税込価格を積み上げて計算した額にズレが起きてしまい、結果として消費者への説明が煩雑になってしまうでしょう。税込価格を基準にすれば、税込小計金額とのズレは起きないため、価格表示で悩む必要はなくなります。

なお、最近スーパーマーケット等で商品の税込価格を小数点以下2桁くらいまで表示しているのを見たことがある人もいるかと思います。これは、税抜価格を基準とするPOSシステムを使いながら総額表示の義務に対処するための苦肉の策で、小数点以下まで表示することで、税込価格と税込小計金額の差を小さくするためだと想像しています。

まとめ

動画 21:01

それではまとめに入ります。

軽減税率対応の本質は取引を税率ごとに記録できるようにすることです。

そのためには、同じ品目でも税率ごとに価格を管理するよう変更します。そして、取引の商品等の明細項目ごとに、適用した税率ならびに価格、金額を記録します。

消費税額の表示は税率ごとに行う必要があるため、税率ごとに各種明細の金額を集計し、その税込小計額から税抜小計額を計算します。また、税抜価格を元に積み上げた金額とのズレを、税抜消費税調整額として計算し、自動で調整します。

そして、消費税の端数処理は税率ごとに1回だけになるように実施します。

軽減税率対応についてこれまでお話してきましたが、話はこれだけでは終わりません。

軽減税率対応によって、経理情報はどう記録するようにしたのか、セットなどの割引やクーポン、ポイント計算にはどのような影響があるのでしょうか、予約取引などで軽減税率が施行される2019年10月1日をまたぐ場合、どのように処理すればよいのでしょうか、などなど、まだまだ多くのネタがあります。

それらについては、今後Developers.IOブログで紹介していければと思っています。

以上で「本当に怖い軽減税率対応〜入門編〜」を終わります。どうもありがとうございました。

最後に

prismatixでは、こういった軽減税率対応のような面倒複雑な業務ルールへの対応を、共に悩み解決に導くために助け合う仲間を常に募集しています。興味のある方は、下記のリクルートページよりご応募ください。

リクルート|プリズマティクス株式会社

参考URL

脚注

  1. 税率だけでなく税の種類も保持することにしたのは、同じ税率でも異なる税の種類ということがあり得るためです。たとえば、新税法が施行される前後にまたがる取引では、ある条件を満たすことで適用される税率が旧税率の8%になりますが、これは軽減税率ではないため、取引としては区別して記録しなければなりません。
  2. とはいえ、消費者に消費税額が少なくなるように見せるため、税込額から税抜学を計算する際は「切り上げ」がよく使われてはいるようです。
  3. 表示価格としてはよいが、取引の金額にそのまま端数処理した金額を使ってはいけません。
  4. 令和5年10月1日より施行される制度で、大雑把位に言えばある一定の決まりを守った請求書のみを有効な請求書としてみなすというようなものです。
  5. 一番良く使われる端数処理であろうことから、切り上げを選んでいます。