インボイス経過措置リンター 80%→70%（2026年10月1日改正）

日本のEC・請求コードのこの5行が、2026年10月1日に間違いになります。

サンプルの請求・仕入コードは11行でした。そこから13件（error 11 / warn 2）が出ました。 いちばん多いのは、どのリポジトリにもある1行です。

// 免税事業者からの仕入れ（経過措置）
const KEIKA_RATE = 0.8;
const deduct = shiire * KEIKA_RATE;

インボイス制度は2023年10月1日に始まり、適格請求書を持たない仕入れでも、 仕入税額相当額の80%を控除できる経過措置が置かれました。 この80%が終わるのが2026年9月30日です。

ここからが本題です。2026年10月1日以降の控除割合を検索すると、 多くの記事とAIが「50%」と答えます。それは改正前の予定値です。 令和8年度税制改正で引き下げ幅がなだらかにされ、適用期限も延長されました。 2026年10月1日からの控除割合は70%です。

// ×  const KEIKA_RATE = 0.8;              80%は2026-09-30まで
// ×  const afterOct2026 = shiire * 0.5;   50%は改正前の予定値
// ○  const rate = keikaRateOn(new Date()); // 0.8 → 0.7 → …

つまり日本の請求コードには、間違い方が2種類あります。 0.8 を放置して10月1日に間違えるか、記事のとおり 0.5 に直してやはり間違えるかです。

壊れるのは経過措置だけではありません。適格請求書の端数処理は 「一の適格請求書につき、税率ごとに1回」で、商品ごとの端数処理は認められません。 ところが生成AIに請求ロジックを書かせると、ほぼ必ずこう書きます。

const items = cart.map(i => ({ ...i, tax: Math.round(i.price * 0.1) }));

明細ごとに丸めて合計する形です。税率ごとの合計額に対して1回だけ丸めるのが正しく、 軽減税率8%と標準税率10%が混在する請求書なら、端数処理は合計2回までです。 切捨て・切上げ・四捨五入のどれを選ぶかは自由ですが、回数は自由ではありません。

さらに、適格請求書発行事業者の登録番号は「T」＋13桁です。 /^T\d{12}$/ と書かれた検証は、正しい番号を弾きます。 旧税率5%の * 1.05、軽減税率に10%を当てている行、 電子取引データの物理削除（電帳法は訂正・削除の履歴を求めます）も同じ種類の事故です。

これらは人間のレビューでは見落とされます。数字が1文字しか違わず、 今日はまだ正しいからです。だから機械に探させます。

インボイス経過措置リンター 2026 は、VS Code の拡張として動きます。 開いているファイルを24規則で検査し、行番号・深刻度・修正案を出します。 無料版でこの検査は全部できます。件数を隠したり、ぼかしたり、 回数で止めたりはしません。コードは端末から出ません。 製品版で増えるのは範囲と反復です。リポジトリ全体の走査、CSV/JSON/HTML への書き出し、 保存時の自動再検査、そして CI 用の JSON 出力。 2026年10月1日以降に 0.8 が誰かのプルリクで戻ってきたとき、機械がそれを止めます。

税理士のスポット相談は1時間5,000〜15,000円、 高度な税務判断を伴う相談なら10,000〜30,000円が相場です。 ただし税理士は、あなたのリポジトリの何行目かを指すことはできません。

80%控除が終わるまで、あと22日です。