固定資産管理と住民福祉管理に続いて、所得税と住民税の計算過程を合理化するために私なりに考えたデータモデルを紹介しよう。所得税は国税で、住民税は自治体税で市区町村とその所属都道府県に分配される。つまり、所得税の計算様式は自治体別に異なるわけではなく、年度（単独主キー）で一律に決まる。いっぽう住民税の計算様式は、自治体と年度の組み合わせ（複合主キー）に関数従属する。
税金の計算様式と一口に言うが、その内訳は複雑である。扶養者数、基本控除額、基本所得額、累進税率、ローン残額、保険料支払額といった多彩な計算要素が関係する。自治体毎に、また年度毎に変化するそれらの要素を全自治体において統一様式で扱うためには、計算要素や計算式を可変的に定義するためのモデリングパターンが有用だ（前回記事参照）。
データモデルを見てほしい。煩雑になるので法人向けは割愛してあるので、個人向けの所得税・住民税計算のためのモデルである。まず、年度毎に決まるのが、所得税の計算式と計算要素で(1,2番号は各テーブル左上のもの)、翌年度の課税方針が決まった時点で先行して登録される。計算式にはそれに関わる計算要素(2)の計算要素コードを用いた計算過程が設定される。計算式の実際値として単純明快に (elm1+elm2)*elm3 と例示したが、実際はスクリプト言語で書かれるのでいくらでも複雑に書ける。また、計算要素(2)ごとに、個人別の計算要素(7)として申告された要素値の妥当性を検査するための評価式やデフォルト値が設定される。
所得税に続いて、年・自治体の組み合わせで決まる住民税の計算式が登録される(5)。計算に必要な要素(4)は、所得税別に設定される計算要素(2)を包含したもので、住民税計算に固有な要素を付加することで完成する。その過程で計算式や計算要素の妥当性を検証する手間は必要だが、年度が切り替わってもアプリそのものを作り替える必要がないので、運用・保守コストは桁違いに小さく済む。年・自治体の組み合わせで変化する個別施策を取り込むとはそういうことだ。
データ基盤の整備が済むと、いよいよ当該年の運用が始まる。まず、元日にその自治体に居住している住民に対して、個人別の年次サマリ(6)が展開される。その上には「扶養者id」が置かれており、自己参照関係を構成している。子供（被扶養者）の場合に親の住民idが扶養者idに設定され、課税対象外とされる（親の扶養者数もこの情報から自動計算できる）。
いっぽう、あらかじめ個人が契約している法人契約(9)にもとづく所得課税計算要素取引(8)が月次のバッチ処理で取り込まれ、蓄積されてゆく。年末時点で計算要素(7)別の集計値が確定すると、住民税と所得税が自動算出され、源泉徴収分との差額が決まる。
ちなみに、法人契約(9)として自治体に把握される情報は税計算に関わる要素に限られ、雇用契約、寄付契約、保険契約、住宅ローン契約、医療契約等が含まれる。つまり、給与や源泉徴収税をふくめ、法人が月次の取引実績として報告する形だ。ただし法人契約を締結する際に、法人に契約者のマイナンバーを伝える必要があるべきではない。契約するたびにマイナンバーを相手企業に伝えていては情報漏洩のリスクが大きすぎるからだ（参考記事「職場にマイナンバー提出っておかしくない？」）。
市販薬の購入実績等、法人が直接関わらない計算要素は残るがそれほど多くない。行政システムが合理化されている国々がそうであるように、例外的な計算要素を自己申告する以外は、自動的に計算が済んでしまう。この意味で、自己申告すべき要素はなるべく減らしたほうがいい。公平感のために税金の計算過程の複雑化は避けられないが、やりすぎると課税コストの増大を招く。賢く落としどころを探らねばならない。
なお、ここまでの説明で税務署と自治体税務担当との役割を区別していないが、意図的である。データ構造を合理化することが先決であって、それに沿ったデータ処理においてそれぞれの手順をどこの誰が担当するかは些末な問題だ。また、住民にとっては課税合計額が重要で、その内訳がどの主体に振り分けられるかはどうでもいい。「ワンストップ」で納税が済むのが理想、というか当然である。
