使用補助金的系統開發推進方式 ── 從核准決定回推的時程與事業計畫書製作實務

上一篇文章《系統開發外包能使用補助金嗎》整理了應依目的選擇哪種制度來考量。

本文是其續篇，探討選定制度之後實際上該如何推進。

使用補助金的系統開發，在兩點上與一般開發有決定性的不同。

• 在核准決定日之前發包所產生的經費不屬於補助對象
• 補助金為後付款（核銷撥款），開發費須先由自家公司全額墊付

這兩條規則，從時程的編排方式、簽約的時機，到資金周轉，規定了計畫的一切。反過來說，只要以這兩點為軸來回推規劃，就能避免重大失誤。

本文是寫給使用補助金發包系統的一方（中小企業經營者・資訊系統負責人・事業部門承辦人）閱讀的。對供應商方的讀者而言，請將本文當作了解發包方在怎樣的期限與限制下行動的參考資料來閱讀。

另外，手續的細節依制度・公募梯次而異。本文整理的是截至2026年7月時點的一般性流程，實際規劃請務必以所使用制度的公募要領為準。

1．先講結論

使用補助金的系統開發計畫中，應掌握的要點如下。

• 時程不應從希望的交期出發，而應從「核准決定日（可發包日）」與「事業執行期限（驗收・付款的完成期限）」這兩個時間點回推來編排。成果報告是在此之後的另一個獨立期限
• 「獲選」與「核准決定」是不同的手續。原則上只有在核准決定之後才可以發包
• 應以從著手到撥款約需一年左右為前提來規劃資金周轉（必要時可考慮過橋貸款）
• 事業計畫書的製作主體是發包方。能委託供應商的，僅限於提供與開發相關的事實資料
• 憑證（合約書・交貨單・驗收單・付款記錄）在成果報告中一定會用到。應在發生的當下逐一備齊
• 在申請前，先自問一次：即使沒有補助金，這是否仍是一項值得進行的投資

2．了解整體流程 ── 開發只是工序中的一環

使用補助金時，系統開發會被納入以下一連串的手續之中。

確認公募要領・選擇制度
        ↓
申請準備（事業計畫書・報價單・gBizID等）   … 1〜2個月
        ↓
公募截止 → 審查 → 獲選公告               … 數個月
        ↓
核准申請 → 核准決定                       ← 從這裡開始可以發包
        ↓
簽約・發包 → 開發 → 驗收 → 付款        … 須在事業執行期限之前完成
        ↓
成果報告 → 確定檢查（確定補助金額）
        ↓
核銷撥款申請 → 補助金入帳                    … 核銷撥款
        ↓
事業化狀況報告等                         … 完成後仍持續數年

※ 上圖是需經過「獲選公告→核准申請」兩個階段的制度範例。手續的階段數依制度而異，大致可分為以下兩種模式。

表格最後一列是要點所在。無論手續分為幾個階段，能夠發包都是在核准決定之後，這一點是共通的。先確認自己所用的制度屬於哪種模式，掌握是否存在相當於「獲選」的通知，就能避免搶先發包。

還有一點，是閱讀公募要領時要注意的地方。本文中使用的「事業執行期限」「成果報告」「確定檢查」「核銷撥款申請」等稱呼，依制度・公募梯次的不同，有時會使用別的說法（如「補助事業完成期限」「金額的確定」等）。請不要去尋找名稱上的一致，而應根據該手續在上述流程中所處的位置來對應理解。

如果是一般開發，流程到「發包→開發→驗收」就結束了，而補助事業會在這前後附加申請與報告的工序。特別要注意以下三點。

獲選與核准決定是兩回事。在製造業補助金、省力化投資補助金（一般型）等制度中，獲選公告只是「事業計畫已獲選中」的通知而已，之後還有審核經費內容的核准申請手續，須待核准決定下達後才能發包。手續的階段數依制度而異，但能夠發包是在核准決定之後，這一點無論哪種制度都是共通的。數位化・AI導入補助金的手續指南中也明確載明，IT工具的發包・簽約・付款均須在核准決定之後進行。搶先發包所產生的經費，原則上不會被追加認定。

事業執行期間是有期限的。從核准決定到補助事業完成為止的期間（事業執行期限）由各制度分別訂定，必須在這個期限之前完成開發，並完成驗收與付款。成果報告的提交期限會在此之後另行訂定，但被認定為經費的，僅限於在事業執行期限之前完成付款的部分。若開發延遲、超過了事業執行期限，就有可能無法領取補助金。

入帳是最後一步。在成果報告的確認完成之前，補助金不會入帳。而且，確認完成後也不會自動撥款，在製造業補助金等制度中，須由申請人在補助金額確定後提出核銷撥款申請，才會真正付款。申請的提交期限同樣依制度而異，因此不能提交成果報告後就掉以輕心、放著不管。應預估從著手到入帳約需一年左右，並規劃以自家資金或融資來支應這段期間全部開發費用的方案。

3．時程從兩個時間點回推

補助事業的開發時程，應先確定以下兩個日期，再把開發安排在這兩者之間。

• 起點：核准決定日（預估） ── 在此之前無法發包
• 終點：事業執行期限（補助事業完成期限） ── 須在此之前完成驗收・付款。成果報告的提交是在此之後的另一個獨立期限

3.1．回推範例

假設某項制度是這樣安排的：核准決定在4月，事業執行期限（驗收・付款的完成期限）為11月底，成果報告在此之後提交。

這裡的4月・11月底並非固定日期，只是為了說明方便而設定的一種排列：年內申請，在年度更替前後公告獲選・下達核准決定，並在該年度內完成事業。套用到自己所用的制度時，請根據公募要領中「事業執行期間」的記載，以及過去幾梯次獲選公告日・核准決定日的實際日程，替換下表左欄的內容。間隔（相隔幾個月）比日期本身更重要。

這裡重要的是，要把驗收與付款安排在事業執行期限的前1〜2個月。業務系統的驗收測試中，一定會出現只有讓實際資料實際跑過一次之後才會發現的問題。若把驗收設定在緊貼期限，就沒有修正的時間，會發生「為了趕上期限而在不充分的狀態下完成驗收」這種本末倒置的情況。

3.2．核准決定前能做的事・不能做的事

核准決定前雖然不能簽約，但並非什麼都做不了。

反過來說，在申請前把需求整理與報價的精確度提升得愈高，核准決定後的開發就能愈順利地展開。因為一旦申請時的報價與實際開發內容出現大幅落差，就會在核准申請或計畫變更的手續上耗費時間。

另外，電子申請所需的gBizID Prime帳號申請需要經過審查，有時會比較耗時。建議不要等到申請前夕才辦理，而應在開始研議制度的階段就先取得帳號，這樣比較穩妥。

3.3．工序與合約的對應

並不會因為是補助事業，開發合約的思路就有所改變。若採用需求定義階段為準委任、設計以後為承攬的多階段合約（參見「委託開發‧維運的合約該怎麼簽？── 從 IPA《模型交易‧合約書》學習準委任與承攬的區分使用」），就需要讓哪份合約的哪部分經費屬於補助對象與核准申請的內容相對應。若拆分合約，報價單也依相同單位明細化，成果報告時的核對就會輕鬆許多。

4．資金周轉 ── 為核銷撥款做準備

補助金並非預收款。開發費的支付須全額先行，補助金要等成果報告確認之後才會入帳。

規劃時應確認的事項如下。

• 是否能在入帳之前，墊付開發費全額（包含不屬於補助對象的經費）
• 若墊付有困難，能否利用金融機構的過橋貸款（有時可憑獲選通知洽談）。可洽詢的對象例如：有往來的銀行・信用金庫、日本政策金融公庫、地方政府的制度融資（由地方政府・信用保證協會・金融機構組合而成的融資制度）、商工會議所・商工會的金融諮詢。是否受理及條件因機構而異，因此獲選後立即向多家機構洽詢是比較務實的做法
• 補助率為1/2時，剩餘的1/2；為2/3時，剩餘的1/3，都屬於永久性的自付額
• 上線後的維護費・營運費通常不屬於補助對象，須由自家公司每年自行負擔。不過也有例外，例如數位化・AI導入補助金中，已登錄IT工具的雲端服務使用費可在一定期間內（一般框架下最長2年）納入補助對象。製造業補助金也設有雲端服務使用費的經費類別。哪些營運費能在多長期間內納入對象，請依各制度在公募要領中分別確認

尤其最後兩點很容易被忽略。若因為「反正有補助金」而擴大開發範圍，就會導致自付額與維護費一併膨脹，成為補助事業結束之後仍然存在的負擔。先自問一次即使沒有補助金，這項投資在判斷上是否依然成立，再提出申請，終究才是穩妥的做法。

5．事業計畫書製作 ── 發包方該寫的內容，供應商能提供的內容

補助金的審查是透過事業計畫書進行的，而這份計畫書的製作主體，正是身為申請人的發包方。

5.1．只有發包方才能寫的內容

• 自家公司的經營課題（遇到什麼困難，為什麼要在此時解決）
• 數值目標（勞動生產力、附加價值額、加薪等制度所要求的指標）
• 實施體制（誰是負責人，誰是業務方的聯絡窗口）
• 資金計畫（自有資金與融資的區分）

例如在中小企業省力化投資補助金（一般型）中，要求事業計畫須包含與提升勞動生產力、加薪相關的目標（所用的指標・數值依公募梯次而異，也有部分梯次採用從多項指標中選擇的方式），並設有申請時所設定的目標未達成時的返還條款。這些屬於經營本身的承諾，並非供應商能夠代為承擔的性質。

5.2．供應商能提供的事實資料

另一方面，與開發相關的事實部分，則可以獲得供應商的協助。

• 開發內容說明資料（要做什麼、哪些業務會有怎樣的變化）
• 系統架構圖（現行與導入後）
• 依經費類別明細化的報價單
• 工時削減效果的試算依據（現狀作業時間的測量方式、削減量的計算方法）

其中在審查中真正發揮作用的，出乎意料地是最後的「試算依據」。比起「業務將變得更有效率」這種定性描述，「每筆訂單的輸入時間平均為○分鐘，每月○件，因此每月為○小時；其中轉為自動匯入的○成屬於削減對象」這種逐項累加的方式，更能提升計畫的說服力。而這種逐項累加，只有靠發包方的業務資料與供應商的設計知識共同協作才能完成。

5.3．若需要撰寫方面的協助，請洽公家窗口

計畫書撰寫方法本身的協助，不屬於開發供應商的業務範圍。請洽商工會議所・商工會、萬事支援據點（よろず支援拠点）、Mirasapo plus（ミラサポplus，中小企業廳營運的面向中小企業・小規模事業者的支援資訊網站，彙整了補助金・獎助金的概要，以及支援機構的查找方式）中介紹的支援機構，以及中小企業診斷士等專家諮詢。若使用成功報酬制的申請代辦業者，建議冷靜確認其手續費率與合約條件。

6．為成果報告做準備 ── 憑證應在發生時逐一備齊

成果報告中，需要提交從發包到付款一整套的憑證。一般所需的文件如下。

• 多方報價單（在製造業補助金、省力化投資補助金（一般型）等制度中，對一定金額以上的採購，原則上需要多家的報價單。若只能從一家取得報價，則需要提交廠商選定理由書等說明資料）
• 合約書，或發包單・承接單
• 交貨單、驗收單（日期須在事業執行期間之內）
• 請款單、匯款記錄（在製造業補助金、省力化投資補助金（一般型）中，付款原則上須以申請人本人名義的銀行匯款進行，現金支付不屬於補助對象。即使持有收據，也不能代替匯款記錄，因此支付方式應從一開始就確定為銀行匯款）
• 若有規格變更時的變更合約書・備忘錄

在這裡栽跟頭的模式是固定的，就是想事後一併補齊。由於會核對日期的一致性（是否為核准決定日之後的發包、是否為期間內的付款），事後補做文件既做不到，也不應該去做。在發包・交貨・驗收・付款的每個時間點，都應把附有日期的文件當場確定下來並歸檔保存。光是這一點，成果報告的負擔就能大幅減輕。

從開發方的角度來看，這與一般受託開發中本來就該做的文件管理是一樣的。也可以說，在補助事業中，只是把它明文規定為領取補助金的條件而已。

此外，也有些制度在入帳後仍需持續數年履行報告義務，例如事業化狀況報告。報告中所用的指標（生產力、工時、營業額等），與其等系統上線後才開始測量，不如在開發階段就把記錄機制內建進去，這樣每年的報告會輕鬆許多。

7．常見的絆腳點與對策

總結

• 使用補助金的開發計畫，由核准決定日（可發包日）與事業執行期限（驗收・付款的完成期限）這兩個時間點回推決定。成果報告是在此之後的另一個獨立期限
• 獲選與核准決定是兩回事。發包原則上須在核准決定之後
• 補助金為後付款。應先確定好全額墊付的資金周轉方案
• 事業計畫書的製作主體是發包方。應從供應商處取得開發內容・架構圖・報價・效果試算依據等事實資料
• 憑證不要事後一併補齊，而應在發生時逐一備齊
• 由於制度的詳細內容會依公募梯次而變化，請務必以最新的公募要領為準進行確認

關於制度選擇的整體概況，請參閱上一篇《系統開發外包能使用補助金嗎》；使用省力化投資補助金的具體案例，請參閱《省力化投資補助金能讓 FAX 收單網路化嗎》。

給正在考慮以補助金為前提進行開發的您

合同會社小村軟體承接以Windows業務應用程式為中心的受託開發。對於以使用補助金為前提的案件，我們會協助申請前的概算報價・架構圖・工時削減效果試算依據的製作，核准決定後的開發則會以從事業執行期限回推的時程來規劃。

另外，本公司不承接申請代辦，也不進行是否能獲選的判斷。申請手續請洽公家窗口或專家諮詢，而關於開發的內容與推進方式，歡迎從需求整理階段起隨時與我們洽詢。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

獲選之後，可以立刻發包開發嗎？

在製造業補助金（ものづくり補助金）等許多制度中，獲選公告之後還有核准申請這道手續，須經事務局審查後才會下達核准決定。也有像數位化・AI導入補助金（デジタル化・AI導入補助金）這樣，最初的申請本身就是核准申請的制度，但無論哪種情況，原則上被視為補助對象的，都是核准決定日之後簽約・發包的經費。獲選後立即發包有時仍嫌過早，請務必在公募要領中確認自己所用制度可以開始發包的時點，在此之前不要簽約。

補助事業的系統開發，會比一般開發花費更長的時間嗎？

開發作業本身所需的時間不會改變，但前後會加上手續所需的時間。申請準備需要1〜2個月，到獲選公告為止需要數個月，到核准決定為止還需要更多時間；開發完成之後，也要經過成果報告與確認才會撥款。從著手到撥款花費一年左右的時間並不罕見。此外，由於必須在事業執行期限之前完成驗收與付款，因此開發期間須從這個期限回推來確保。

事業計畫書可以請供應商代寫嗎？

事業計畫書的製作主體是身為申請人的發包方。自家公司的經營課題、數值目標、實施體制，只有自家公司才寫得出來。供應商能夠協助的，是開發內容說明、系統架構圖、報價單、工時削減效果試算依據等與開發相關的事實部分資料提供。若需要撰寫方法本身的協助，請洽商工會議所・萬事支援據點（よろず支援拠点）或中小企業診斷士等單位諮詢。

成果報告需要哪些文件？

雖然因制度而異，但一般需要合約書（發包單・承接單）、交貨單、驗收單、請款單、匯款記錄等，從發包到付款一整套的憑證。由於會核對日期的一致性（是否為核准決定日之後的發包、是否為事業執行期間內的付款），因此包括開發過程中若有規格變更時的變更合約書在內，重要的是在文件產生的當下就逐一備齊。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。