信息化项目中途终止，项目款该怎么算？

信息化项目实施过程中，需求变更、进度延期、验收争议、项目中途终止并不少见。很多问题在项目推进阶段看似只是管理分歧，但一旦进入合同争议甚至诉讼，原本模糊的问题就必须被具体判断：建设范围怎么认、履约程度怎么看、哪些证据有效、已经完成的部分值多少钱。

因此，我们准备结合法院公开的真实审判案例，陆续梳理信息化项目在合同履行、需求变更、验收、结算等环节中容易出现的问题。重点不是讨论案件本身，而是借助已经形成司法判断的真实案例，看看这些风险在项目实施阶段能否提前识别和规避。

重点不是讨论谁输谁赢，而是看看：

法院最终认了什么证据、依据什么判断，以及这些争议在项目实施阶段能不能提前避免。

今天先来看一个很典型的软件开发案例。

在最高人民法院知识产权法庭公开的一起软件开发合同纠纷中，其中一个报价55万元的软件系统，合同约定了243项功能。

法院组织双方对实际系统逐项演示核对，最终确认：

164项基本实现，功能完成率67.49%。

那么是不是很简单？

55万元×67.49%=约37.12万元。

项目做到67%，项目款就按67%结算。

但法院并没有这么算。

这恰恰揭出了信息化项目结算中一个很容易被忽略的问题：

功能完成率，不等于价款完成率。

一、为什么“做了67%”，不能直接“付67%”？

问题首先出在一个很简单的地方：

不同功能，并不是等价的。

假设一个系统有100项功能。

其中90项只是常规的查询、录入、修改、查看详情；剩下10项则涉及复杂业务流程、多系统接口、大量数据处理或者核心算法。

如果前90项全部完成，从功能数量看，完成率已经达到90%。

但能不能据此认定：

软件工作量完成了90%，所以合同价也应该支付90%？

显然未必。

因为需求清单中的“一项功能”，只是一个数量上的计数单位，并不意味着每一项背后的开发工作量相同。

一个简单查询可以是一项功能，一个涉及多个角色、多个业务环节、多系统数据交互的复杂流程，也可能只被写成一项功能。

在数量上都是“1”，在工作量上却可能差很多。

所以：

“已完成功能数÷总功能数”，可以反映一定的履约程度，但不能直接作为软件开发费的结算比例。

本案就是一个很典型的例子。

法院虽然认定243项功能中有164项基本实现，完成率为67.49%，但在确定已经完成工作的价值时，并没有直接套用：

55万元×67.49%。

而是结合实际完成情况、合同报价、成果价值、双方履约情况以及项目终止后不再继续发生的后续开发、修改和维护工作等因素，综合认定已经完成部分的价值。

换句话说：

67.49%可以说明“做了多少项”，却不能直接说明“值多少钱”。

二、项目做到一半，该怎么算？

项目中途终止以后，首先当然要确认：

到底哪些内容已经完成。

功能清单、需求规格说明书、变更记录、测试材料、系统演示、阶段成果确认，都可以成为判断实际完成范围的重要依据。

但确认完“做了什么”以后，还要继续回答第二个问题：

这些已经完成的内容，对应了多少实际软件工作量？

这一步很关键。

因为如果只按照功能条目数量平均分摊合同价格，就默认了所有功能的价值完全相同。

显然，这往往并不符合软件开发的实际情况。

更合理的处理思路，是把已经确认完成的建设内容重新还原成可计量的软件规模和工作量，再结合原合同价格构成、项目实施情况、需求变更情况以及已形成成果的实际价值，判断已经完成部分对应的合理价款。

简单来说，可以把这个过程理解成三步：

第一步，划清范围。

哪些功能已经完成，哪些没有完成，哪些属于新增需求，哪些属于原合同范围，要先分清。

第二步，核实工作量。

不能只数“做了多少条功能”，还要进一步分析已经完成部分对应的软件规模和实际开发工作。

第三步，再谈价格。

结合合同计价方式、原报价构成、实际履约情况以及尚未发生的后续工作，确定已完成部分的合理价值。

这样算出来的，才更接近：

项目真正已经完成了多少“价值”，而不仅仅是多少“数量”。

软件造价测算，也可以更高效

现实工作中，面对几百项甚至上千项需求，逐项整理、识别软件规模，本身就需要投入大量时间。

这类场景下，也可以借助专业的软件造价工具提升测算效率。

例如软件造价喵，可以基于项目需求材料自动识别功能点、生成软件功能清单，并结合行业基准数据开展软件造价测算，将大量原本需要人工逐条整理、分类和计算的工作结构化。

尤其是在预算评审、结算审核或者项目中途终止需要重新核定已完成软件规模时，可以先针对已经确认完成的建设内容进行功能点识别和规模测算，再结合合同、需求变更以及实际交付成果形成造价分析基础。

对于“243项功能做了164项”这样的情况，真正需要进一步测算的，也正是：

这164项已完成功能，究竟对应了多少实际的软件规模和开发工作量。

而不是只停留在：

164÷243=67.49%。

三、真正要防的是“后面算不清”

这个案例最值得关注的，不是项目做到67%后怎么处理，而是：

为什么项目实施到中途，才开始重新判断“到底做了多少、值多少钱”？

很多信息化项目只有总价，没有把建设内容、软件规模和价格对应起来。

项目正常完成时问题不明显；一旦出现范围调整、功能取消、阶段暂停或需求新增，就容易出现：

知道少做了什么，却不知道该扣多少钱。

所以，造价管理不能只回答“这个项目总共多少钱”，还应尽量建立：

建设内容—软件规模—价格

之间的对应关系。

这样后续发生变化，才有调整依据。

四、前期至少把三件事说清楚

1.建设范围要能核对

合同和需求材料不能只写几个模块名称。

至少要形成相对清晰的功能清单，能够判断：

哪些属于原合同范围；

哪些属于新增；

哪些已经取消；

哪些已经完成。

本案之所以能核出“243项中完成164项”，前提就是合同中已有较明确的功能清单。

2. 建设内容要和价格有对应

只有“软件开发费500万元”是不够的。

如果项目后期取消一个模块、增加一批功能，价格怎么调？

前期如果已经通过软件规模、工作量等方式形成测算基础，后续调整就更有依据。

例如，软件造价喵可以辅助识别功能点、生成软件功能清单，并结合行业基准数据开展造价测算，使项目从“一个总价”进一步形成可追溯的软件规模和价格依据。

这不仅方便前期预算，也有利于后续需求变更和范围调整时重新测算。

3.什么叫“完成”要提前约定

功能做出来，不一定等于合同义务完成。

因此，合同中最好区分：

开发完成、测试完成、部署上线、试运行、验收通过等不同状态。

否则很容易出现：

供应商认为“已经做完”，项目单位认为“还没达到交付条件”。

五、实施过程中，要把“变化”管住

信息化项目需求变化很正常。

真正容易出问题的是：

需求变了，但范围、工作量和价格没有同步调整。

新增了什么、取消了什么、调整了什么，都应形成清晰记录。

对于影响较大的变更，还应同步分析：

软件规模变化多少，费用是否需要调整。

否则到结算阶段，再靠会议纪要、聊天记录和口头说明重新还原，往往很难说清。

回到这个案例。

“项目做到67%，是不是就该付67%的钱？”

真正值得借鉴的，并不是法院给了一个新的计算公式。

而是提醒项目管理者：

范围要提前说清，价格要有对应，变更要及时留痕，完成标准要事先约定。

这些事情做好了，项目即使发生调整，也有依据可核、有价格可算。

别等项目做到67%的时候，才发现这67%到底值多少钱，没人说得清。