软件开发合同审查清单

功能范围是否以书面附件（需求说明书/功能清单）为准，而不只是合同正文的几句描述？

口头约定和模糊描述是后续扯皮的根源。必须有白纸黑字的附件，合同里引用附件名称和版本号。

附件里是否包含原型图或线框图？

原型图比文字描述更精确，能大幅减少"你说的不是我理解的"问题。

是否明确写明"本合同不包含以下功能"或"范围外需求走变更流程"？

只写包含什么不够，还要写明不包含什么，否则乙方可能主张什么都算在范围内。

验收标准是否具体可量化（如：按需求说明书逐项测试，通过率 100%）？

"甲方满意"不是标准。必须有客观可衡量的验收依据。

是否约定了甲方的验收期限（如：收到提交后 X 个工作日内完成验收）？

没有期限约束，甲方可能无限拖延验收；乙方拿不到尾款，纠纷也因此产生。

超过验收期限未提出异议，是否视为验收通过？

这条对乙方公平，也能督促甲方认真按时验收，不要拖着不确认。

验收过程中发现的 bug 如何处理？修复期限是多少？

需要区分"必须修复才能验收通过"和"后续优化"，避免验收无限期延长。

每笔款项是否绑定了具体的触发事件（而不只是日期或比例）？

"首付 30%" 不够。要写"合同签署后 X 日内"、"需求说明书经甲方书面确认后 X 日内"。

付款是否与开票挂钩（付款后 X 日内开具发票）？

确认发票品名、税率（信息技术服务 6%）、开票时间，避免付款后久等发票。

尾款比例是否保留在 10–20%，并绑定正式上线条件？

尾款是甲方最后的保障。尾款比例太低（如 5%）失去约束力；太高（如 40%）对乙方不公平。

是否明确写明"验收通过且付款完成后，知识产权归甲方所有"？

不写清楚，乙方可能主张对代码有版权，限制你将来换团队维护。

乙方使用的第三方组件/开源库是否在附件中列明？

防止乙方将来主张某些关键组件属于其自有资产，限制甲方使用权。

交付物清单是否具体列明（源码、数据库文档、部署说明、操作手册）？

"交付系统"不等于"交付源码"。必须逐项列出，否则乙方可以只交付可运行的程序。

交付物是否在验收通过后 X 个工作日内提交完整？

没有时间约束，乙方可能拖延交付源码，增加甲方迁移风险。

是否区分"甲方原因"和"乙方原因"导致的延期？

需求确认拖延、接口提供迟缓都是甲方原因。合同里不区分，双方会互相推责。

乙方延期是否有明确的违约金条款（如每日 X‰，上限 X%）？

没有违约金，合同里的交付日期只是参考，没有约束力。

变更需求是否需要书面确认，并评估对工期和费用的影响？

口头变更是双方扯皮的高发区。必须约定所有变更走书面流程，未确认的变更不产生效力。

质保期是否明确（建议 3–6 个月）？

质保期太短（1 个月）意味着上线稳定期内的 bug 都要另收费。

质保期内的 bug 修复是否免费？响应时间是多少？

需要区分"乙方代码问题"和"甲方需求变更导致的修改"，前者免费，后者另议。

质保期后的维护如何计费？是否有明确的服务模式（包月/按次）？

提前约定好，避免将来找不到人或报价太贵才开始谈。

是否有保密条款，覆盖业务数据、客户信息、系统架构？

保密条款需要定义保密范围、保密期限、违约责任，三者缺一都会降低约束力。

争议解决是否指定了具体的法院或仲裁机构（建议选甲方所在地）？

不写争议解决方式，真正出了纠纷，连去哪告都要先争论一番。