税務申告システム開発は、業務と正解データを整理し、製品か開発方法かを選んだうえで、6つのフェーズの検証を順に進めると、正確な申告と現場への定着につながります。
全体像、6つのフェーズ、費用相場、見積もりの取り方を順に見ていきます。各段階で何を決めておくかに焦点を当てます。
▼全体ガイドの記事
・税務申告システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
税務申告システム開発の全体像
税務申告システムは、会計や給与などの業務データを税務計算へ集約します。対象は、法人税、地方法人税、消費税の申告です。さらに、地方税、償却資産、法定調書の申告と電子送信も支援します。
入力作業の効率化に加えて、誰がいつ何を確認し、どのデータを送信したかを残す統制基盤として設計します。
業務の統制基盤としての位置づけ
仕訳や固定資産台帳が正しく取り込めないと、担当者が手作業で補正することになります。その補正がExcelだけに残ると、税理士や上長がレビューした根拠を追えず、翌期に同じ確認を繰り返すことにもなります。
こうした手戻りを防ぐには、入力元から過年度データまでを一つの業務フローとして組むことが要ります。統制基盤として設計する範囲は、業務フローや送信と保存に加えて、単一法人か複数法人か、自治体や税理士事務所かによって変わります。
- 業務フロー：入力元、税区分変換、計算結果、レビュー履歴、電子署名を一つの流れでつなぐ
- 送信と保存：送信結果、受信通知、過年度データまでを一連の設計として扱う
- 単一法人：中小企業では法人税・消費税を中心に、会計連携と電子申告を整える
- 複数法人：法人別権限、共通マスタ、グループ通算、事業所税、地方税の申告先管理まで含める
- 自治体・税理士事務所：住民税基幹、関与先管理、LGWAN、顧客ごとの権限を分けて、要件にする
税目・データ・送信・証跡の4層による機能の分け方
機能要件は、税目、データ連携、保存・監査といった層に分けて書き出すと、抜け漏れを抑えられます。
- 税目：法人税、消費税、法人住民税、法人事業税、償却資産、法定調書などの対象範囲
- データ連携：会計・ERPから仕訳、残高試算表、固定資産、給与、請求データを取り込む仕組み
- 保存・監査：証憑との紐付け、検索、訂正・削除履歴、操作ログ、バックアップ、データ返却の確認
データ連携では、勘定科目と税区分をどのルールで変換するかを、あらかじめ決めておく必要があります。税目では対象と対象外を明示し、さらに保存・監査では、取引年月日、金額、取引先で検索できるようにします。
送信機能は「e-Tax対応」の一言で判断せず、範囲を具体的に確かめます。国税庁のe-Tax APIは、基本情報や税目情報などの取得に使えます。ただし、認証や申告データ送信のように、API一覧にない操作は、別の受付システムインターフェイス仕様で確認する必要があります（出典: 国税庁「国税電子申告・納税システムAPI」、2026年確認）。
送信まわりでは、電子証明書の保管方法、署名者、送信端末を決めておきます。あわせて、受付結果とエラーの保存、再送、障害時の紙提出や代替手順まで要件に含めます。
電子帳簿保存法は、クラウド保存だけで自動的に対応できる制度ではありません。そのため、保存先の選択とは別に、運用まで含めて対応を進める必要があります。そのうえで、真実性や可視性、検索性、関連書類などの要件を満たす運用を組み、訂正・削除を防ぐ仕組みと社内規程を設計します。
税務申告システム開発の6フェーズの流れ
開発は6つのフェーズで進みます。要件整理と選定に始まり、設計開発とテストを経て、稼働と定着へと進みます。
各フェーズで成果物と責任者、次へ進む条件を決めておくと、法改正や現場要望が入ったときにも、追加費用と納期への影響を示せます。
全社を一度に変えることが難しいときは、代表法人や代表部門で先に試します。その際は、見積から月次保存まで業務を一通り通す方法が有効です。仕訳取込、申告書作成、レビュー、送信の各段階も、この流れに含めます。一連の処理を試せば、工程間の抜けが見つかります。
フェーズ1：要件整理による現行業務と正解データの定義
要件整理では、申告担当者に加えて、経理や各事業部にヒアリングします。給与や固定資産、情報システムの担当者も対象です。税理士と承認者にも話を聞きます。
まず、対象税目と法人・事業所数、申告件数を一覧にします。決算月や申告期限も書き出したうえで、現行ソフトや会計・ERP、Excelの利用箇所、紙資料を洗い出します。
現行フローには、データの作成場所、転記場所、確認者、差し戻しの方法を書き込みます。確定データの保存先まで含めます。
税額計算の正解も、開発の前に決めておきます。税務担当者と開発会社は、同じ資料をもとに次のルールを確認します。
- 税目・計算：勘定科目と税区分、課税・非課税・不課税、端数処理、償却、地方税分割の定義
- 過年度・法人：過去年度の修正、連結・グループ通算の扱い
- 対象・確認者：対象税目と法人の一覧を作り、申告書項目ごとに入力元と確認者を結びつける
- 手作業：人の手で残る項目の明示
- 運用責任：法改正の責任者と期限、障害や送信の失敗時の代替運用の決定
成果物は、業務フローと機能一覧、データ項目定義です。さらに、税務計算ルール、非機能要件、移行方針、概算スケジュールも含みます。
要件が曖昧なまま比べると、デモ画面の印象で選んでしまい、後から個別開発が膨らむおそれがあります。
フェーズ2：パッケージ・クラウド・スクラッチの選定
候補は、標準機能に業務を合わせるパッケージ・クラウド、既存会計と申告専用ソフトを組み合わせるハイブリッド、独自要件を実装するスクラッチです。それぞれの特徴を比べます。
標準業務が中心で、法改正の更新やバックアップ、可用性をサービス側に寄せたい企業は、既製品が候補になります。また、会計やERPは変えず税務申告だけを刷新する場合は、CSVやAPIの連携を検証したうえで専用ソフトを組み合わせます。
特殊な業態や複雑なグループ通算がある場合、独自承認や分析が競争力に直結する場合は、個別拡張やスクラッチを検討します。複数ERPとの深い連携が必要な場合も同じです。
税務計算のロジックを自社だけで持つと、税率、帳票様式、電子申告仕様の更新を継続的に追う必要があります。国税庁の仕様書一覧には、受付システムインターフェイス、API、電子署名、送受信モジュールが別々に掲載されています。この一覧は、2026年6月15日に更新されています（出典: 国税庁「e-Tax仕様書（KSK2対応版）一覧」、2026年）。
製品に「対応」と表示されているかだけでなく、更新を誰が実装し、いつ検証するかまで確かめます。候補の比較では、機能の数よりFit&Gapを重視し、次の項目を同じ条件で評価します。
- 適合範囲：対象税目、会計・給与・固定資産連携、複数法人
- 権限と統制：権限、職務分掌、レビュー履歴、電子署名
- 電子申告・更新：e-Tax・eLTAX、過年度保存、API、法改正リリース
- 導入後の支援：サポート窓口、データ返却、導入支援
各社に同じ過年度データと代表的な例外ケースを渡し、申告書の正解値まで一致するかを確かめます。そうすると、営業資料にない差が分かります。
フェーズ3：データ・計算・権限・連携の設計開発
設計開発では、データと権限を先に定めておき、連携の異常や送信の失敗があっても追跡できる形にします。
- データモデル：法人、事業所、会計期間、税区分、申告書、証憑などの定義
- 画面と履歴：申告担当者、税理士・上長、情報システムで画面を分ける。承認前後の修正は別操作にし、差し戻し理由、修正者・日時、再承認を記録する
- セキュリティ：個人番号、給与、取引先、納税情報を扱うため、多要素認証、最小権限、職務分掌、暗号化、バックアップ、脆弱性管理、再委託管理を要件にする
- データ連携：APIの有無に加えて、取込件数、未変換件数、差分、重複、期間外データを検知し、担当者へ返す
- 電子申告：証明書期限、利用者識別番号、送信可能時間、受付通知と送信エラー時の再送、紙提出への切替を運用手順にする
勘定科目や取引先、固定資産、別表の定義に加え、承認や送信結果、受信通知も決めます。そのうえで、取込前後のデータは分けて保存し、元仕訳まで追跡できるようにします。
フェーズ4：過年度データと例外ケースでのテスト
画面が動くかを見るだけでなく、単体テストでは税額計算、端数処理、必須チェック、権限を確認します。結合テストでは、会計取込から申告書、電子データ、送信結果までを一続きでつなげます。
次に、過年度申告データを使い、旧システムや税理士の結果と突き合わせ、課税所得や税額、還付・納付、帳票、地方税の内訳が一致するかを確かめます。正常系に加えて、次の例外ケースも検証します。
- 申告例外：税区分未設定の仕訳、修正申告、予定申告、中間納付
- 資産・法人異動：固定資産の除却、事業所の新設・廃止、法人統合
- 再計算・提出：過年度データの再計算、証明書の期限切れ、送信後のエラー
- 重複取込：同じファイルの再取込
テストケースには、入力値と期待値、確認者、実績、証跡の保存先を持たせます。合否の判定は、税務担当者が行います。
本番前には、申告期限から逆算して、実担当者がリハーサルを行います。通しでは、データ取込からレビュー、承認、署名、送信まで続けます。続けて、受信通知の確認から納税、証憑保存までを流し、所要時間とボトルネックを測ります。
旧システムとの並行運用は、1回で終わらせず、複数の締めで行います。主要税目と例外を含めて再現できることを、稼働の条件にします。
フェーズ5：段階稼働と切り戻し条件の決定
稼働に向けて、対象法人、税目、年度、ユーザーを明確にします。加えて、マスタの凍結、最終移行、権限付与、電子証明書の設定、バックアップ、連絡網を確認します。
まず代表法人や一部税目から先行稼働させ、申告業務のピークを避けて段階的に広げると、リスクを抑えられます。切替日だけでなく、旧システムを参照できる期間と、旧運用へ戻す条件も決めておきます。稼働の判定では、次の項目を確認します。
- 処理準備：重大障害がなく、税務担当者が主要シナリオを処理できること
- 突合完了：旧システムとの残高・税額・帳票の突合が済んでいること
- 送信対応：送信エラーと再送の手順を理解している
- 問い合わせ体制：窓口と対応時間が周知されている
電子申告は、送信しただけでは完了とせず、受信通知と受付結果を保存できた時点で完了と定めます。
フェーズ6：法改正対応と現場定着の運用への組み込み
稼働後は、利用状況と法改正対応をKPIで追えるよう設定します。
- 運用KPI：利用率、二重入力、取込エラー、レビュー完了日と申告期限までの余裕、送信エラーの再発、手作業の帳票数を追う
- 利用定着：入力項目の多さ、正しいデータの不明確さ、メールでの差し戻し、例外処理の不足など、未入力の原因を見直す
- 法改正：影響税目・帳票・計算ロジック・連携仕様、テストデータ、利用者への案内の管理
- 利用者支援：申告担当者の操作手順、承認者の確認ポイント、情報システムの障害対応を分けて用意する
- 定期見直し：繁忙期に限らず、月次・四半期・決算後にも入力ルールとマスタを点検する
利用者が入力しない原因は、意識の問題とは限りません。システム設計に原因がある場合もあります。
2025年度税制改正では、請求・決済の電子取引データを変更されない状態で保存する見直しが行われています。さらに、仕訳とデータ連携する仕組みも対象です（出典: 国税庁「電子取引関係」「令和7年度税制改正後の取扱い」、2026年確認）。運用会議では、法改正と電子帳簿保存の運用規程をまとめて確認します。
保守契約には、法改正リリース時期と問い合わせ応答時間、障害時の連絡方法を明記します。あわせて、データ返却、ログ保持期間、追加開発単価も残しておきます。
税務申告システムの費用相場
費用は、製品利用料、導入支援、移行に分けて考えます。さらに、連携開発、テスト・研修、年間保守も別々に見積もります。ただし、公開価格を基にすると、法人・税目の追加、移行、法改正、運用支援の費用が抜けてしまいます。
次の概算は、2026年時点の公開価格と、会計・財務・税務領域の類似開発をもとにしたものです。
既製品の利用料と導入費
公開されている製品価格には、次のような例があります。
- PCAクラウド法人税：法人税のみで、1ソフトあたり月額16,200円
- 会計併用モデル：1ソフトあたり月額10,200円
- 年間利用料の目安：単純計算では年10万円台から数十万円ですが、税目、ユーザー、法人、連携先で変わります
- 達人シリーズ：Professional Editionモデルは年間163,700円
PCAの価格は、いずれも税抜です。サーバー利用ライセンスなどの条件も付いています。ただし、インストール、操作指導、データ移行は対象外です（出典: ピー・シー・エー株式会社「PCAクラウド 法人税 価格」、2026年確認）。
達人シリーズのモデルは、法人税、消費税、内訳概況書、電子申告の主要4タイトルを組み合わせた価格です（出典: 株式会社NTTデータ「法人税・消費税の申告」、2026年確認）。この価格には、独自の会計連携、移行、研修、導入支援、複数法人の運用費は含まれません。そのため、見積書では製品価格と導入作業を分けて示してもらいます。
導入支援と個別開発を含めた費用の目安
導入支援や個別開発を含めた概算は、刷新の範囲によって異なります。
- 小規模な部分刷新：導入支援、連携、移行を含めて、100万円〜500万円程度
- 複数システムの統合：複数法人・周辺システム、ワークフロー、電子申告、証憑保存を含め、500万円〜2,000万円程度
- スクラッチ開発：独自計算や複雑なグループ通算、複数ERP連携では、1,500万円〜5,000万円超となる可能性があります
この数字は、NotebookLMの調査による類似案件の推定額です。公的な標準価格として示されたものではありません。実額は、税目と申告数で大きく変わります。法人・事業所の数も、費用に響きます。さらに、データ品質、連携数、移行年数によっても差が出ます。
テスト範囲や法改正対応、保守体制も金額に影響します。そのため、見積書では要件定義から保守までの内訳を分けてもらう必要があります。
年間保守費と法改正対応費を含めたTCO
初期価格だけでなく、利用中と契約終了時にかかる費用を合わせて比較します。
- 継続費用：利用料、サーバー、追加ユーザー・法人、バックアップ・監視・問い合わせ、法改正、証明書・保守開発・教育の費用
- 保守・運用費：類似システムでは初期開発費の年5〜15％程度が目安ですが、契約と改正対応範囲で変わります
- 5年間の総額：法改正が個別見積か通常保守内かを確かめたうえで、初年度、2年目以降、5年間で試算する
- 初年度と継続年：環境設定、移行、研修、並行運用を最初の年に加え、以降は利用料、保守、改正、追加法人を見込む
- 終了時と工数：データ返却、ログ持ち出し、移行ファイル、消去証明の費用と、残る手作業の工数
税務申告システムの見積もりを取るポイント
見積もりの精度は、発注前に業務とデータをどこまで具体化できるかで決まります。RFPには、税目と帳票、法人・事業所の範囲を書き込みます。申告件数、既存システム、連携方式も併せて記載します。
あわせて、過年度データの年数や権限、レビュー、署名、保管を含めます。法改正、テスト、教育、保守も盛り込みます。
未確定の要件は未確定のまま明示してもらい、前提条件と追加費用の発生条件も提示してもらいます。
見積依頼書に書く税務・連携・移行・運用の範囲
機能名に加えて、業務上の完了条件と各工程の責任範囲を、RFPに書き込みます。
- 会計連携：CSV取込だけでなく、差分承認と、申告書から元仕訳への追跡まで定義する
- 電子申告：データ作成、署名、送信、通知とエラーの保存、再送、問い合わせ利用までを、要件として明らかにする
- データ移行：移行年数、勘定科目・税区分・法人・事業所コードの対応表、欠損データ、旧システム参照、突合責任者の決定
- 運用保守：法改正のSLAと検証期間、受付時間、復旧目標、バックアップ、ログ、終了時の返却形式の取り決め
会計連携では、未変換の税区分を検出し、税務担当者が差分を承認できることも条件になります。運用条件には、税務担当者が検証する期間に加え、バックアップ世代数とログ保管期間も具体的に記載します。
3社以上を同じデータと評価軸で比べる方法
相見積もりでは、価格だけでなく、同じデータと評価軸を使って提案内容を比べます。製品の機能が優れていても、導入側の税務知識や移行体制が弱いと、現場で使える状態までは届きません。
- 共通条件：同じRFP、代表仕訳、過年度申告データ、例外ケース、想定ユーザー数を渡す
- 回答とデモ：標準・設定・追加開発・対象外を区分して示してもらい、未設定税区分、修正申告、複数法人、送信エラー、差し戻しを実演してもらう
- 評価軸：機能・税務計算の検証、連携・電子申告、セキュリティ・移行、期間・経験、法改正・保守費・データ返却を同じ配点で比べる
- 担当範囲：製品ベンダーとSI・導入支援会社の分担、要件定義から保守までの担当
追加費用と責任分界のリスク
見積条件、将来の改修しやすさ、税務とシステムで、どこまでを誰が受け持つかを、契約前に確認します。
- 追加費用：移行上限、税目や法人の追加、帳票変更、法改正、証明書・API・テスト・研修、稼働後対応の範囲
- カスタマイズ：標準機能で代替できる業務の見直しと、法改正時に改修しやすい設計の優先
- 税務上の責任：計算の正しさや法令解釈、申告書の最終承認を、誰が担うかを明文化する
- 運用上の責任：送信エラーの一次切り分けと、クラウド障害時の連絡・復旧担当の決定
- 法令要件：検索、訂正・削除防止、操作ログ、関連書類を確認し、セキュリティ対策とは別の要件として扱う
どこまでを誰が受け持つかが曖昧だと、法改正対応が標準保守の外に置かれる場合があります。
税務申告システム開発でよくある質問
導入の前には、パッケージかスクラッチか、電子申告の範囲、法改正やセキュリティの担当について質問が多く寄せられます。発注前に判断しやすいよう、よくある疑問に順に答えます。
税務申告システムはパッケージとスクラッチのどちらがよいですか？
標準的な税目と申告業務が中心なら、法改正対応やバックアップをサービス側へ寄せられるパッケージ・クラウドを第一候補にします。一方で、特殊な計算や複雑な法人構成、既存ERPとの深い連携が不可欠な場合は、個別拡張やスクラッチを検討します。全面的な自社開発を始める前に、標準製品で満たせる範囲と独自開発が必要な範囲を、Fit&Gapで分けます。
e-TaxとeLTAXへの対応はどこまで確認すればよいですか？
申告データの作成だけでなく、電子署名や送信、受付結果、受信通知まで確認します。さらに、エラーや再送、担当者への通知、証跡保存も見ます。
e-Tax APIは、基本情報などの取得と、認証・申告データ送信とで仕様が分かれています。そのため、製品がどの方式で接続するかを確認します。
eLTAXでは、「電子申告対応」と一括りにせず、対象税目や申告先、利用者情報、送信単位、受付結果の扱いを確かめます。
法改正とセキュリティは誰が対応しますか？
法令の判断とシステム対応の担当は分けて、その範囲を契約と運用手順に残します。
- 法改正：判断は自社の税務担当者や税理士、製品変更・リリース・テスト支援はベンダー側が担う形が一般的です
- 契約条件：通知、影響範囲、検証環境・テストデータ、利用者案内、問い合わせ、追加費用の明記
- アクセス管理：MFA、最小権限、暗号化、ログ・バックアップ、脆弱性、データ所在の確認
- 閲覧権限：個人番号・給与情報の閲覧者、税務担当者と承認者の分離、退職者の権限停止時期の決定
- クラウド：障害・漏えい通知、再委託、ログ保管、データ返却・消去証明を、規約と個別契約で確認
税務申告システム開発の進め方まとめ
税務申告システム開発の成功の鍵は、申告書の画面を先に作ることより、要件整理の段階でデータ、税務ルール、レビュー、送信、証跡保存を決めることにあります。
6フェーズでの判断と検証の積み重ね
要件整理では、対象税目、現行業務、正解データ、非機能要件を定義します。続く選定では、方式のFit&Gapと5年間のTCOを比較します。
設計開発では、データモデル、税務計算、権限、連携、ログを固めます。テストでは、過年度データと例外ケースを突合します。
最後に、稼働では段階切替と切り戻し条件を決めます。定着では、入力率、手作業、レビュー、期限余裕、法改正対応をKPIとして改善します。
最初の一歩は代表法人の業務フローとRFPの作成
開発を始める前に、比較の土台を整えておきます。
- 代表法人や部門を選び、見積から受信通知保存までの業務フローを作ります。
- 対象税目、連携先、移行範囲、法改正、セキュリティ・保守・終了時の返却をRFPに記載します。
- 複数社へ同じ条件で提案を依頼し、税務の正確性と現場定着を5年間維持できるかで判断します。
▼全体ガイドの記事
・税務申告システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。