一个信息化项目，供应商已经提交验收材料并正式申请验收，项目委托方却一直没有签验收单。后来，委托方又以系统仍存在问题为由拒绝付款。

没有签字盖章的验收单，这个项目当然还没有验收——很多人的第一反应都是如此。

但在一件BI系统开发合同纠纷中，最高人民法院给出的结论并不是这样。

01

“没签验收单”，为什么仍被认定视同验收通过？

CASE 01

BI系统开发合同纠纷

该项目合同约定：开发方提交上线试运行测试报告、UAT测试报告等材料后，由委托方组织验收；如有不合格项目，应在2个工作日内书面通知，逾期视为验收通过。

开发方后来提交了约定材料并提出验收申请。法院结合合同条款、双方此前的交付确认、付款以及后续运维等履行情况，认定项目已经进入验收环节。委托方未在约定或合理期限内书面提出不合格事项，应按合同约定视同验收通过。

关键不在于“委托方没有回复”这一件事，而是合同对验收材料、异议期限和逾期后果有明确约定；开发方已提交约定成果并有效发起验收；双方履行过程也能证明项目确实进入了验收阶段。

没签验收单，不一定意味着合同上没有形成验收效果。

但问题也随之而来：是不是系统只要上线了、用了一段时间，就更能证明已经验收？

02

反过来，上线使用也不等于已经验收

CASE 02

大数据分析平台纠纷

另一件大数据分析平台纠纷中，软件已经部署上线，供应商也多次催促验收。但法院查明，该次上线主要用于测试，系统仍处于修改完善阶段，部分图表数据出错，源代码也未按合同目的完成交付。

法院据此没有把“上线”直接等同于“全部交付完成”，而是继续审查约定功能、源代码、需求变更、双方测试和协作过程。最终，法院认定双方均有违约，合同解除，并结合实际完成情况确定开发工作的对价。

系统已经上线、已经在用，也不等于项目已经通过验收。

这两个案件放在一起看，恰好构成双向提醒：验收单很重要，但它不是唯一证据；上线使用很重要，但它也不是最终结论。

03

真的发生争议，法院到底看什么？

验收争议的审查核心

不是一张验收单，而是完整证据链。

信息化项目验收发生争议时，真正需要核查的不是一张验收单，而是合同约定、成果交付、测试反馈、整改复验和实际履行共同形成的完整证据链。

至少沿着以下六条线核查

1

看合同到底怎么写。验收对象是什么，交付物有哪些，验收标准和方式是什么，谁有权发起验收、谁有权签收，异议期限多长，逾期未答复有什么后果。合同写得越模糊，事后越容易出现“我以为已经提交”和“我认为还不具备验收条件”的对立。

2

看验收条件是否真正成就。系统上线并不当然等于已经具备验收条件。需求规格说明书、测试报告、源代码、部署文档、操作手册、培训记录、第三方测评报告等，是否按合同要求全部提交，往往决定验收期限是否已经开始计算。

3

看验收申请是否有效到达。一封标题为“项目已上线”的邮件，未必等于正式验收申请。申请是否写明验收对象、依据、材料清单和期限，是否发送给合同约定的联系人或指定系统，是否留有送达凭证，都会影响其证明力。

4

看异议是否具体、及时并符合约定。“系统还有问题”通常不等于完整的验收不合格意见。争议发生后，更有价值的是在期限内形成的问题清单：对应哪项需求、如何复现、属于严重缺陷还是一般缺陷、是否影响核心业务、要求何时整改。微信里零散提Bug，与按约提交正式验收意见，证明效果可能并不相同。

5

看问题后来怎么处理。提出问题之后，是否完成整改，是否提交整改说明，是否复验，复验期限是否重新起算，问题属于原合同缺陷还是新增需求，都要留下连续记录。很多项目的真正断点，不在第一次验收，而在“改完以后没人确认”。

6

看双方后续实际怎么做。系统是否转入正式业务使用，是否开始运维，是否支付了与验收挂钩的款项，是否继续提出新需求，建设单位是否仍明确表示验收不通过。这些行为不能单独决定验收结果，却可能帮助判断双方当时究竟把项目视为何种状态。

04

项目建设过程中，怎样避免陷入这种争议？

真正有效的做法，不是等纠纷发生后再寻找一张“决定性文件”，而是在合同和履约过程中把验收链条提前搭好。

1

把验收触发条件写成可核对的清单。不要只写“项目完成后组织验收”。应明确是系统上线、试运行期满、验收申请送达，还是全部交付物提交齐全后才启动验收。若缺少材料，应在收到申请后几日内一次性告知。

2

把验收标准写到可以测试。“满足使用要求”“运行稳定”很难直接执行。应尽量对应需求清单、测试用例、性能指标、数据准确性、接口联通、文档和源代码交付要求，并区分严重缺陷与一般缺陷，明确什么情况可以通过、附条件通过或不通过。

3

把期限起算点写清楚。不仅要写“几日内完成验收”，还要写从哪一天、哪一事件开始计算；材料补正、整改复验是否重新起算；遇节假日如何计算。期限没有起点，逾期后果就很难落地。

4

把有效异议方式写清楚。明确由谁向谁，通过正式函件、指定邮箱或项目管理平台提出。问题单应关联合同需求和测试证据。项目群可以用于协作，但重要结论最好及时归集为正式记录。

5

把整改和复验做成闭环。每个问题都应有编号、责任人、处理结果和关闭状态。整改后由供应商提交复验申请，建设单位在约定期限内复核并形成结论，避免问题长期挂起，也避免同一问题反复争执。

6

把需求变更与缺陷整改分开。原需求没有实现，通常属于整改；新增功能、业务规则调整或接口范围扩大，则可能属于变更。

建设单位认为：“这是原项目本来就应该做的。”供应商认为：“这是后来新增的需求，需要增加费用。”

因此，对于实施过程中发生的需求调整，宜及时通过变更记录明确变了什么、为什么变、是否影响工期和费用，以及对原验收计划有什么影响。

特别是涉及软件功能增加或调整时，仅仅记录“新增了哪些功能”还不够，后续往往还需要进一步评估由此增加了多少开发工作量、费用是否需要调整。

实际项目中，也可以借助专业的软件造价工具辅助量化。例如“软件造价喵”可以根据需求内容辅助识别功能点，并结合行业基准数据和相关造价标准进行测算，为需求变更前后的工作量及费用变化提供参考依据，也方便后续变更审批、结算或审计时进行复核。

需求变更不仅要留痕，还要尽量把“变了什么、增加了多少工作量、费用如何变化”说清楚。

这样既可以防止新增需求不断加入，却一直被认为是“原项目还没做完”；也可以避免原本就应该整改的问题，被重新包装成收费变更。

结语

信息化项目验收最危险的状态，不是明确的“通过”或“不通过”，而是系统已经上线、问题仍在修改、双方都在继续使用和付款，却没有人说清楚项目究竟处于测试、试运行、验收还是运维阶段。

因此，验收管理的重点不应只放在最后那张验收单上，而应把合同条款、交付清单、验收申请、问题反馈、整改复验和需求变更连成一条可追溯的证据链。

不签验收单，不一定代表没有验收；上线使用，更不等于当然验收通过。

真正决定风险的，是合同有没有写清楚，项目过程有没有做扎实，关键节点有没有留下能被复核的记录。