使用补助金进行系统开发的推进方法 ── 核准决定的逆向推算日程与事业计划书编制实务

上一篇文章《外包系统开发能否使用补助金》梳理了应按目的选择哪种制度进行考虑。

本文是其续篇，探讨选定制度之后实际应该如何推进。

使用补助金的系统开发，在两点上与通常的开发有决定性的不同。

• 在核准决定日之前下单产生的经费不属于补助对象
• 补助金后付（结算付款），开发费需要先由本公司全额垫付

这两条规则，从日程的编排方式、签约的时机，到资金周转，规定了计划的方方面面。反过来说，只要以这两点为轴进行逆向推算来制定计划，就能避免重大失误。

本文面向使用补助金发包系统的一方（中小企业经营者・信息系统负责人・业务部门负责人）撰写。对于供应商一方的读者，请将本文作为了解发包方在怎样的期限与制约条件下行动的资料来阅读。

另外，手续的详细内容因制度、公募轮次而异。本文整理的是截至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. 常见的绊脚点与对策

总结

• 使用补助金的开发计划，由核准决定日（可下单日）与事业实施期限（验收・付款的完成期限）这两个时间点逆向推算决定。成果报告是在此之后的另一个独立期限
• 入选与核准决定是两码事。下单原则上须在核准决定之后
• 补助金后付。应先确定好全额垫付的资金周转方案
• 事业计划书的编制主体是发包方。应从供应商处获取开发内容・构成图・报价・效果测算依据等事实资料
• 凭证不要事后一并补齐，而应在发生时逐一备齐
• 由于制度的详细内容会因公募轮次而变化，请务必以最新的公募要领为准进行确认

关于制度选择的整体概况，请参阅上一篇《外包系统开发能否使用补助金》；关于使用省力化投资补助金的具体案例，请参阅《省力化投资补助金能否实现传真订单的网络化？》。

致正在考虑以补助金为前提进行开发的读者

合同会社小村软件（合同会社小村ソフト）承接以Windows业务应用程序为中心的受托开发。对于以使用补助金为前提的项目，我们会协助申请前的概算报价・构成图・工时削减效果测算依据的编制，核准决定之后的开发则会以从事业实施期限逆向推算的日程来规划。

另外，本公司不承接申请代理，也不进行是否能够入选的判断。请就申请手续咨询公共窗口或专业人士，而关于开发的内容与推进方式，欢迎从需求梳理阶段起随时与我们咨询。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

入选之后，可以立刻下单开发吗？

在制造业补助金（ものづくり補助金）等多数制度中，入选公布之后还有核准申请这道手续，须经事务局审查后才会下达核准决定。也有像数字化・AI引入补助金（デジタル化・AI導入補助金）这样，最初的申请本身就是核准申请的制度，但无论哪种情况，原则上被认定为补助对象的，都是核准决定日之后签约・下单的经费。入选后立即下单有时仍嫌过早，因此请在公募要领中确认自己所用制度可以开始下单的时点，在此之前不要签约。

补助事业的系统开发，会比通常的开发花更长时间吗？

开发作业本身所需的时间不会改变，但会在前后追加手续所需的时间。申请准备需要1～2个月，到入选公布为止需要数个月，到核准决定为止还需要更多时间；开发完成之后，也要经过成果报告与确认才会到账。从着手到到账花费一年左右的时间并不罕见。此外，由于必须在事业实施期间的期限之前完成验收与付款，因此开发期间须从这一期限逆向推算确保。

事业计划书可以请供应商代写吗？

事业计划书的编制主体是身为申请人的发包方。本公司的经营课题、数值目标、实施体制，只有本公司自己才能写。供应商能够协助的，是提供开发内容说明、系统构成图、报价单、工时削减效果测算依据等与开发相关的事实部分资料。如果需要写作方法本身的支援，请向商工会议所・万能支援据点（よろず支援拠点）或中小企业诊断师等咨询。

成果报告需要哪些文件？

虽然因制度而异，但一般需要合同书（订购单・承接书）、交货单、验收单、发票、转账记录等从下单到付款的一整套凭证。由于会核对日期的一致性（是否为核准决定日之后的下单、是否为事业实施期间内的付款），因此包括开发过程中发生规格变更时的变更合同书在内，重要的是在文件产生的当下就逐一备齐。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。