IT導入補助金 事業実施・実績報告の実務ポイント|基本情報技術者資格を有する行政書士が解説

【2025年12月11日作成】

IT導入補助金は、会計ソフトや予約システム、ECサイト、CRM、チャットボット、AI解析ツールなどの導入・活用を支援する制度です。 しかし実務の現場では「採択された後の事業実施・実績報告が大変」「証憑の集め方が分からない」「名義や口座の取り扱いが不安」といったご相談をよくいただきます。

特に「実績報告」は、単なる書類提出ではなく、交付申請で示した計画どおりにIT投資が実行されたかを確認する“検証フェーズ”にあたります。ここでの不備は、不支給や補助金返還といった結果にも直結しかねません。

この記事では、IT導入支援事業者としてのベンダー登録経験と、IT導入補助金の支援・採択実績が豊富な行政書士の立場から、 事業実施・実績報告フェーズで押さえておきたいポイントを、 「請求書」「支払証憑」「名義・口座」「事前設計」といった切り口で整理して解説します。

IT導入補助金2025の事業実施・実績報告の実務ポイント

1. 制度上の位置づけ:交付申請後の「検証フェーズ」

IT導入補助金の手続きは、大きく「交付申請 → 事業実施 → 実績報告 → 効果報告」という4つのフェーズに分かれています。 交付申請の段階で示しているのは、あくまで

「こういうIT投資を、この金額・この内容で行う予定です」

という“計画レベル”の情報だけです。 これに対して実績報告では、申請時の計画どおりに事業が実行されたかどうかを、各種の証憑をもとに検証していきます。具体的には、

  • 請求書
  • 支払に関する証憑
  • ITツールの利用状況や役務の実施内容を示す資料
  • (必要に応じて)契約書などの関連資料

といった書類を突き合わせながら確認していくプロセスです。 制度上、事業が適正に実施されていない場合や、実績報告の内容・証憑に重大な不備がある場合には、補助金は交付されません。すでに交付された補助金であっても、内容によっては返還の対象となる可能性があります。

「一度採択されれば安心」ではなく、実績報告の段階でもう一度きちんと“審査される”というイメージを持っておくことが大切です。

2. 実績報告における「要求仕様」

2-1. チェックリストの読み解き方

「事業実施・実績報告にあたっての重点確認事項」では、実績報告で見られるポイントが、大きく次の4つのカテゴリに整理されています。

  1. 「請求書」
    契約年数や単価など、交付申請の内容と比較するうえでの基本情報が記載されている部分です。
  2. 「支払証憑」
    支払方法ごとに必要書類が指定されており、どのような資料をセットで提出すべきかが定められています。
  3. 「支払完了の確認」
    支払金額・支払日・支払元が、システム上の入力内容と整合しているかどうかをチェックする観点です。
  4. 「実施内容説明資料(役務のみ)」
    コンサルティングや設定作業など、形のないサービス提供について、本当に実施されたのかを確認するための資料です。

これら4つは、審査側から見た“最低限の要求仕様”にあたります。実務上は、この4カテゴリを起点に

「どんな証憑を、どのタイミングで、どこに保管するか」

という“証憑設計”をプロジェクト開始前に決めておくと、実績報告の負担が一気に軽くなります。

2-2. 電子申請前提のドキュメント運用

IT導入補助金2025では、交付申請・実績報告ともに電子申請が前提です。

  • 申請者(中小企業・個人事業主)は「申請マイページ」
  • IT導入支援事業者は「IT事業者ポータル」

を通じて、オンライン上で手続きを進めていきます。 そのため、紙でバラバラに管理するのではなく、最初から「電子化を前提にしたドキュメント運用」を設計しておくことが重要です。たとえば、

  • すべての証憑をPDF・画像ファイルとしてスキャン・保存しておく
  • フォルダ構成とファイル名のルール(命名規則)を事前に決めておく
  • 可能であれば、事業者・ITベンダー間で共通のクラウドストレージを利用する

といった工夫をしておくことで、「どこに何があるか分からない」「ファイル名がバラバラで探せない」といった事態をかなり防ぐことができます。

3. 請求書に関する実務ポイント

3-1. サブスク契約の年数・期間の書き方

事業実施・実績報告の手引きでは、サブスクリプション型のITツールなどについて、請求書の段階で「契約年数」や「契約期間」が分かるようにしておくことを求めています。 イメージとしては、次のような点に注意する必要があります。

  • 「1年分」「3年分」など、契約年数・期間がはっきり分かるように記載する
  • 「一式」とだけ書いてしまうと契約年数が読み取れず、そのままでは要件を満たさない

そのため、実務では次のような対応を行います。

  • 請求書の品目欄に「○年分」と明記する
  • もしくは、後述する「請求・支払内訳シート」で年数を補完する

これらはプロジェクト開始前に、ITベンダー側と請求書のフォーマットを共有・調整しておくことが理想です。

3-2. 単価とシステム入力値の整合性

もう1つ重要になるのが、請求書に記載された金額情報と、交付申請・実績報告システムで入力した内容の整合性です。

  • 単価
  • 数量
  • 小計・合計

といった項目が、申請時・報告時の入力値と“完全に一致している”ことが求められます。 実務的には、例えば次のような工夫をしておくと、後のチェックがスムーズです。

  • 値引きを行う場合は、備考欄などに「値引き前価格」と「値引き後価格」を整理して記載する
  • 複数年契約の場合は、「年額なのか」「複数年の総額なのか」が分かるように表現を工夫する
  • オプション料金や保守料金は、本体とは別行で書き分け、内訳が分かるようにしておく

これらは厳密な意味での“必須要件”というより、あとから自社や事務局側がチェックしやすいようにしておくための「設計面での工夫」と考えていただくと分かりやすいかと思います。

3-3. 「請求・支払内訳シート」の位置づけ

請求書だけでは契約年数や単価などが判断しづらい場合について、手引きでは「請求・支払内訳シート」等を作成して補完する運用が示されています。 このシートの役割は、「請求書単体では読み取れない情報(契約期間や内訳など)を明確にする補完資料」というものです。 したがって、基本方針としては次のような役割分担を意識しておくと良いでしょう。

  • メイン:請求書で要件を満たすよう設計する
  • 不足分:内訳シートで丁寧に補う

あくまで主役は請求書であり、その“読みやすさ”をベースに、ベンダー側と調整しておくのが望ましい形です。

4. 支払証憑と会計処理の整合性

4-1. 支払方法ごとの必須書類

支払方法ごとに求められる証憑の組み合わせのうち、代表的なものを簡単に整理すると、次の通りです。

ATM振込の場合

ATM利用明細に加えて、当該取引が記載された通帳(表紙+該当ページ)をセットで残しておきます。

窓口振込の場合

振込依頼書の控えと、同じく通帳(表紙+該当ページ)を組み合わせて証憑とします。

インターネットバンキングの場合

振込完了画面や取引明細に加えて、口座名義が分かる資料(通帳の表紙やキャッシュカードなど)を揃えます。

クレジットカード払いの場合

利用内容・利用日・金額・カード名義が分かるカード利用明細に、引落口座の名義を確認できる資料を組み合わせます。

これらは補助金の観点だけでなく、将来の会計監査や税務調査でも重要な資料になります。IT導入補助金への対応をきっかけに、自社の経理フローや証憑管理を見直しておくと、その後の業務にもプラスになります。

4-2. 「支払完了」と見なされる条件

支払証憑について、事務局側がチェックしているポイントは、おおまかに次の4点です。

  • システムに入力した金額と、実際の支払金額が一致しているか
  • 証憑上に「支払日」または「振込日」が明記されているか
  • その支払日が、請求日より後の日付になっているか
  • 支払元の名義から、「補助事業者自身の支払い」であることが客観的に分かるか

要するに、「支払ったらしい」という印象ではなく、

「誰の口座から・いつ・いくら支払ったのか」

が第三者から見ても明確に分かることが求められています。 インターネットバンキングの画面をキャプチャして保存する場合は、振込完了の状態・金額・振込日・口座名義(またはそれに紐づく情報)が1つの画面で分かるようにしておくと安心です。

5. 名義・口座の問題とコンプライアンスリスク

5-1. 代表者個人口座・親族口座からの支払い

支払証憑においては、「口座名義」と「補助事業者名」の一致が非常に重視されます。次のようなケースは特に注意が必要です。

  • 代表者個人名義の口座から支払ってしまうケース
  • 代表者の家族・親族名義の口座から支払うケース
  • グループ会社・関連会社名義の口座から支払うケース

こうした支払いは、証憑の見え方として「補助事業者自身が支払ったものとは判断できない」と見なされる可能性があります。その結果として、不支給や交付済み補助金の返還を求められるリスクにつながりかねません。

5-2. クレジットカード利用時の注意点

クレジットカード払いの場合も考え方は同じで、

  • カードの名義
  • 利用明細に表示される名称
  • 引落口座の名義

が、補助事業者名と一致していることが重要です。 ここで判断されるのは、「依頼人」欄や連絡先として書かれた名前ではなく、カード名義や口座名義として表示される名称です。法人であれば法人名義のカードを、個人事業主であれば屋号付き名義など、補助事業者と紐付けて認識できるカード・口座を使うことが、コンプライアンス上欠かせないポイントになります。

6. プロジェクト開始前に済ませておきたい「3つの設計」

実績報告の段階で慌てないためには、プロジェクト開始前のタイミングで

  • 契約・請求の設計
  • 支払フローの設計
  • 証憑ストレージの設計

という「3つの設計」を済ませておくことが非常に有効です。

6-1. 契約・請求の設計

まずは、交付申請時の見積内容と、実際の契約・請求内容が一貫するように、テンプレートを整えておきます。 サブスクリプションや保守契約については、契約期間・年数を明示できるよう、契約書・請求書のいずれにも反映させます。 また、値引きやオプション追加が発生しそうな場合は、「交付申請の内容との整合性をどう確認するか」を事前にベンダー側と決めておくと、後のトラブルを避けやすくなります。

6-2. 支払フローの設計

次に、支払そのものの流れを整理します。例えば、次のようなルールを決めておきます。

  • 補助対象となる支払いは、原則として補助事業者名義の口座だけを使う
  • 可能であれば「補助金関連支出専用口座」を用意し、会計上もトレースしやすい形にする
  • インターネットバンキングの画面キャプチャを、いつ・どの画面で保存するか、ルール化しておく

といった点を、社内ルールとして明文化しておくと、現場担当・経理担当の間で認識がずれにくくなります。

6-3. 証憑ストレージの設計

最後に、証憑の保管方法です。契約前の段階から「補助金フォルダ」を作っておき、たとえば次のようにフォルダを分けておきます。

  • 01_交付申請・採択通知
  • 02_契約・見積
  • 03_請求書
  • 04_支払証憑
  • 05_実施報告・利用状況資料

ベンダー側とも共有できるクラウドストレージ上に同じ構成を用意しておくと、証憑の受け渡しや確認がオンラインで完結し、「誰かのPCの中にだけある」といった属人的なリスクを減らすことができます。 この3つの設計を先に済ませておくことで、「証憑が足りない」「どこに何があるか分からない」といった事態をかなりの程度防ぐことができます。

7. よくある失敗パターンとその対策

7-1. 期限ギリギリになって証憑不足に気づくケース

もっとも多いのが、「実績報告の期限目前になって、必要な証憑が足りないことに気づく」パターンです。 対策としては、交付決定のタイミングで、実績報告までを含めた簡易的なガントチャートを作っておき、

  • 請求書の受領
  • 支払いの実行
  • 証憑の電子化と保管
  • 実績報告書の作成

といった一連の流れをタスクとして見える化しておくことが有効です。

7-2. ベンダー側の請求書フォーマットが要件を満たさないケース

サブスクリプション年数や内訳が分からない請求書が後から出てきて、慌てて差し替えをお願いする──というのも典型的なパターンです。 これを避けるために、プロジェクト開始前の打合せ段階で「事業実施・実績報告の手引き」の該当箇所をベンダー側と共有し、

  • 契約年数の表現
  • 単価・内訳の書き方

などを、あらかじめフォーマットとしてすり合わせておくことが大切です。

7-3. 個人口座から立替払いしてしまうケース

現場レベルの“良かれと思って”の対応で、責任者個人の口座や家族名義の口座から立替払いをしてしまうことがあります。 しかし、補助金の実務上は「補助事業者自身の支払であること」が非常に強く求められます。 そのため、「補助金対象の支払いは、法人口座(補助事業者名義の口座)のみ使用する」というルールを社内で明文化し、経理部門だけでなく、現場の担当者にも周知しておくことが必要です。

7-4. インターネットバンキングの画面キャプチャ不足

最後に、インターネットバンキングの画面キャプチャに関するトラブルも少なくありません。

  • 金額だけの画面を保存してしまう
  • 振込日や口座名義が分からない画面だけ残っている

といったケースです。 対策としては、「振込完了の状態」「金額」「振込日」「口座名義(または紐づく情報)」の4点が確認できる画面を必ず保存する、というルールを徹底します。可能であれば、具体的な画面例を添えた“キャプチャの取り方マニュアル”を作っておくと、担当者が変わっても運用がぶれにくくなります。

8. 専門家にアウトソースするメリット

IT導入補助金の実績報告は、見かけ上は「書類をアップロードするだけ」にも思えますが、実際にやってみると、

  • 補助金の要件と、会計・税務の要件を同時に満たす証憑設計
  • ベンダー側との請求・契約フォーマットの調整
  • マイページへの入力内容と証憑の整合性チェック
  • 名義・口座・日付など、細かい要素の確認

といった、プロジェクトマネジメントとドキュメントレビューを組み合わせたような業務になります。

9. まとめ|実績報告は「書類作業」ではなく「統制の確認」

ここまで見てきたように、IT導入補助金の実績報告は、単なる書類提出ではなく、

  • 計画どおりのIT投資が行われたかを検証するプロセスであること
  • 請求書・支払証憑・実施内容資料の「3点セット」を軸に、証憑設計が非常に重要になること
  • 名義・口座・日付といった細かな不一致が、不支給・返還リスクに直結し得ること
  • プロジェクト開始前の設計と、ベンダーも巻き込んだ合意形成が成功のカギになること

といったポイントを押さえておく必要があります。 制度の要件をしっかり理解したうえで、自社の現場オペレーションと無理なく両立させることが、IT導入補助金を“安全かつ効果的に”活用するうえでのポイントです。

筆者は、理学修士(金融工学専攻)として技術領域に深い理解を持ち、 基本情報技術者・行政書士として、ベンダー登録とIT導入補助金の申請支援実績が豊富です。 加えて当事務所では、IT事業者様により上質なサービスを提供すべく 提携先の応用情報技術者を有する行政書士である藤原先生とともに、単独受任時と変わらない報酬での共同受任にも応じています。 LINE、問い合わせフォーム、または、お電話にてお気軽にお問い合わせ頂ければ幸いです。

当事務所の提携先(あわせてなないろバックオフィス):行政書士藤原七海事務所

今すぐ相談(全国対応、無料相談、土日歓迎)

Yohei Komori

行政書士
基本情報技術者
J.S.A. ワインエキスパート
古森洋平 Yohei Komori

080-6521-1647

LINE / Zoom(全国対応、無料相談、土日祝日可)