消費税0%についてチャッピーと考える

Filed in チャッピーと話そう

前回の記事のあと、少し消費税0%について調べてみた。世の中には本当に0%に対応できていないシステムがたくさんあるらしい。正直ちょっとびっくりした。消費税0%の壁は本当にシステム改修に時間がかかるというのが理由である可能性がでてきた。

ある記事では軽減税率を0%に設定すると標準税率の10%が適用されるということが書かれていた。軽減税率が0ではないというのが軽減税率を適用するフラグになっている仕組みなのだと思われる。「税率0に特殊な意味を勝手に持たせただけでは?意味の違う変数を流用するべきではないというのは基本では?」というのが感想であった。寧ろキチンとフラグを新設した方がバグを作り込みにくいのではないか。

また、ある記事では税率で除算をして税額を算出する処理があり0で除算するとエラーになるからと書かれてあった。一定の理解はできるが、こちらも「除算処理の分母が変数である場合には事前に変数値をチェックするのが基本では?」と思う。

なんなら軽減税率の導入時に生活必需品は0%にすべきという議論もあったと記憶している。0%になりえる可能性は容易に想像できたはずだ。その時、考慮されていれば今回のような問題は起きなかったはずである。

ぶっちゃけて言うと、0%にできないのが本当にこういったことが原因なのだとすれば、これは政府の責任というよりもIT業者の能力不足が原因だと思う。

と思ったのでチャッピーと話してみた。

今回のテーマ:なぜ税率0%を想定してないのか?

(私)  世の中には本当に0%を想定していないシステムがあるらしい。0%を想定しないということになってしまう動機として考えられることは?

(チャッピー) 0%を想定しない動機として考えられるもの
1. 「0%」を税率ではなく“課税対象外フラグ”として使っていた
2. 「課税取引なら税率は正の値」という業務前提で作っていた
3. レシート・帳票の印字ルールが「0%=表示しない」前提だった
4. 商品マスタ・税区分マスタが「税率番号」で設計されていて、0%用の意味づけがない
5. インボイス・会計連携が「0%課税売上」を別物として扱えない

(私) 軽減税率の導入時に0%の可能性も容易に想定できたはずだが何故対応されなかった?

(チャッピー) 短く言うと、「想定できたはずなのに対応されなかった」のは、0%の可能性を知らなかったからというより、2019年の軽減税率対応プロジェクトの目的が“将来のあらゆる税率変更に強い設計に作り直すこと”ではなく、“8%と10%を期限までに動かすこと”だったから、と考えるのが自然です。

  中略

(私) 軽減税率導入時の要件は8%と10%に対応することではなく
1.軽減税率を導入する
2. 軽減税率は変更可能
3. 標準税率も変更可能
ではなかったか?

(チャッピー) **本当に必要だった要件は「税率を変更可能にする」だけではなく、「税率ごとに区分して処理できること」**です。
より厳密に言うならこうです。
1. 複数税率を扱えること
標準税率と軽減税率を併存させられる
2. どの取引にどの税率を適用するか判定できること
食品/外食/新聞などの判定
同じ食品でも持ち帰りか外食かで変わる場合への対応
3. 税率ごとに区分して記帳・集計・請求書発行できること
区分経理
税率ごとの請求書・レシート・元帳表示
4. 税率値を固定値ではなく変更可能にしておくこと
標準税率も軽減税率も、将来の改定に備えて設定可能にする

「軽減税率導入時の要件は8%と10%に対応することではなく、軽減税率という制度を導入し、その税率値も変更可能にすることではなかったか?」
というあなたの指摘は、かなり筋が通っています。

(私) あなたの言う要件が満たされているなら今回問題は起きていないのでは?

(チャッピー) はい。かなり率直に言えば、その通りです。
少なくとも私が先ほど挙げたレベルの要件がきちんと満たされ、その趣旨どおりに実装されていたなら、今回の「0%は大改修」という問題は本来かなり起きにくいはずです。

では、なぜ問題が起きているのか
1. 要件が実はそこまで明確に定義されていなかった
2. 要件はそれっぽく書かれていたが、実装がその趣旨を満たしていない
3. POS本体は対応できても、周辺システムが同じ前提で作られていない

私の見立てを一番短く言うとこうです。

もし軽減税率導入時に、本当に「標準税率・軽減税率を任意に変更可能な複数税率制度」として正しく要件化・実装されていたなら、今回の0%で“特別に大きな問題”は起きにくい。
今回問題が起きているということは、どこかでその要件が欠けていたか、文書上はあっても実装がそのレベルに達していなかったか、あるいは周辺システムを含めた全体整合が取れていなかった可能性が高い。

(私) 今対策しなかった場合、今後0%にしたい場合に問題が再浮上すると考えられる。今対策した場合としなかった場合の予測は?

(チャッピー)
今対策しない場合
次回0%議論が出たとき
再び「0%は特別で難しい」が論点化
ベンダー影響調査をやり直す
1%や給付案が再浮上
実施時期が遅れやすい
時限措置の延長・終了でも毎回揉める
中長期の状態
技術負債が残る
政治的にも「0%は難しい」が既成事実化
1%→0%や再減税のたびに追加コスト
今対策する場合
次回0%議論が出たとき
論点は「対象範囲」「開始時期」「期間」に寄る
システムは税ルール変更+テスト中心
1%→0%の移行も比較的素直
期間限定・延長・恒久化にも対応しやすい
中長期の状態
0%を通常税率として扱える
将来の税率変更コストが下がる
政策議論で「レジの壁」が使いにくくなる

今対策する場合、短期的には当然コストがかかります。
POS本体の改修
レシート/帳票確認
会計連携修正
本部集計やBI確認
商品マスタ運用の見直し
0%→8%戻しまで含むテスト

将来また0%をやる可能性が高いなら今対策しないのは、ほぼ確実に将来へ問題を繰り延べるだけです。
しかも次回は、
今回の議論のやり直し
既存システムに積み上がった追加パッチの整理
1%→0%の差分対応
まで加わるので、むしろ複雑になる恐れがあります。

0%は難しいというのが既成事実化するのは凄く嫌ですね。