合同审查意见（软件开发服务合同）
- 审查立场：甲方（委托方）
- 审查目的：签约前把关
- 审查口径：常规
- 审查范围：合同正文（第一条至第三条），无附件、无技术方案、无报价单
一、综合审查意见
本合同仅有三条实质内容，属于严重不完整的框架式文本。就本次重点关注的第二条而言，存在尾款支付与验收机制脱节这一结构性缺陷：付款义务被绑定在"合同生效"这一时间事件上，而非绑定在"成果交付并验收合格"这一履行事件上；同时验收条款被写成"交付即视为验收合格"，甲方实质上丧失了验收权。两者叠加，甲方在乙方尚未交付、或交付物不符合要求的情况下，仍可能被要求支付全部合同价款，且事后难以主张成果不合格。
此外，合同缺失标的与需求范围、价款金额与构成、交付标准、知识产权归属、保密、违约责任、争议解决等核心条款，不具备可签署条件。
二、微观层风险清单
风险 1：尾款支付与验收脱节，付款条件与履行进度倒挂
风险等级：P0
相关条款：第二条前段"甲方应于合同生效后 30 日内支付全部尾款"
风险后果：
- 付款触发条件是"合同生效 + 30 日"这一纯时间条件，与乙方是否交付、交付质量完全无关。若乙方在 30 日内未交付或交付不合格，甲方付款义务仍已届期，甲方将丧失最主要的履约制约手段（价款留置）。
- 甲方付清全款后，乙方继续开发的动力和违约成本大幅下降，后续修改、缺陷修复、源码交付、部署上线等极易失控。
- 一旦发生争议，甲方只能事后另行起诉要求返还或赔偿，举证难度和资金回收风险均由甲方承担。
判别标准：开发类合同中，尾款应当以"验收合格"为支付前提；凡以纯日期、"合同生效后 X 日"等与履行进度无关的事件作为尾款触发条件的，一律视为高风险。
法律依据：《民法典》第五百二十六条（互负债务有先后履行顺序的，先履行一方未履行的，后履行一方有权拒绝其履行请求）、第七百八十一条至第七百八十八条（承揽/技术开发合同关于交付与验收的规定）。合同若未约定验收为付款前提，甲方难以直接援引先履行抗辩权。
整改建议：将尾款支付条件由"合同生效后 30 日"改为"验收合格且乙方开具合规发票后 X 个工作日内"，并拆分为预付款／进度款／验收款／质保金四段式付款结构。
推荐措辞：
第二条 合同价款与支付
2.1 本合同总价款为人民币【未提及/待补充】元（含税），价款构成及对应交付节点见附件《报价与交付节点表》。
2.2 双方按以下节点支付： (1) 预付款：本合同生效且乙方开具合规发票后 5 个工作日内，甲方支付合同总价的 30%； (2) 进度款：阶段性成果经甲方书面确认通过后 5 个工作日内，甲方支付合同总价的 30%； (3) 验收款：全部开发成果经甲方按第【X】条约定验收合格并出具《验收合格确认书》，且乙方完成源代码、技术文档交付后 10 个工作日内，甲方支付合同总价的 30%； (4) 质保金：合同总价的 10% 作为质保金，自验收合格之日起满 12 个月且无未处理缺陷的，甲方于期满后 10 个工作日内支付。
2.3 任一节点的付款义务，均以该节点对应的乙方履行义务全部完成为前提。乙方未完成对应义务的，甲方有权暂缓支付，且不构成甲方违约、不计逾期付款违约金。
2.4 乙方应在甲方付款前开具符合税法规定的增值税专用发票；未开具发票的，甲方付款期限相应顺延。
建议展现方式：整条重写（原条款付款逻辑整体失效，局部修改无法修复），并保留批注说明修改原因。
风险 2："交付后视为验收合格"，甲方验收权被架空
风险等级：P0
相关条款：第二条后段"乙方交付成果后视为验收合格"
风险后果：
- 验收环节被彻底取消。乙方只要完成"交付"这一单方动作，即自动产生验收合格的法律效果，甲方无检验期、无提出异议的机会、无拒收权。
- "交付"本身未定义（交付什么、交付到哪、以何种形式确认送达），乙方可主张发送一个安装包、一份文档即已"交付"，从而锁定验收合格状态。
- 验收合格通常同时是质保期起算点、风险转移点和违约责任减免点。本条使甲方在成果实际不可用的情况下，仍被推定为已接受成果，后续主张质量违约的举证责任几乎全部转移给甲方。
- 与风险 1 叠加后果更严重：甲方既无验收权，付款又不以验收为条件，等于对乙方的开发质量完全不设约束。
判别标准：凡出现"视为验收合格""视为交付完成""甲方逾期未提出异议即视为通过"而未同时约定合理检验期、验收标准和异议程序的，均属于对委托方明显不利的拟制条款。
法律依据：《民法典》第七百七十条、第七百七十六条、第七百八十一条（承揽人交付的工作成果不符合质量要求的，定作人可以要求修理、重作、减少报酬、赔偿损失）、第五百六十三条（根本违约解除权）。另《民法典》第四百九十六条、第四百九十七条：若本条属乙方提供的格式条款且不合理免除其责任、限制甲方主要权利，甲方可主张该条款无效。
整改建议：删除"视为验收合格"的拟制表述，补入完整验收机制：验收标准来源（需求文档／技术方案作为附件）、验收期限、验收方式（功能测试＋性能测试＋试运行）、不合格的整改与再验收流程、多次整改仍不合格时的解除权与退款安排。
推荐措辞：
第【X】条 交付与验收
X.1 交付：乙方应于【未提及/待补充】前，向甲方交付全部开发成果，包括但不限于可运行的软件系统、全部源代码、数据库结构说明、部署文档、操作手册及本合同附件约定的其他交付物。乙方应以书面或双方确认的电子方式提交《交付清单》，经甲方书面签收之日为交付日；乙方单方发送不构成交付。
X.2 验收标准：以本合同附件《需求规格说明书》《技术方案》及双方书面确认的变更文件为验收依据。上述文件与本合同正文不一致的，以对甲方更有利者为准。
X.3 验收期限：甲方应自交付日起 15 个工作日内完成验收（涉及试运行的，试运行期【未提及/待补充】日，不计入验收期）。
X.4 验收结果：验收合格的，甲方出具《验收合格确认书》，以该确认书载明之日为验收合格日。未经甲方书面出具《验收合格确认书》，不构成验收合格；不得以甲方使用、试用、沉默或期限届满推定验收通过。
X.5 验收不合格：甲方以书面方式提出不合格事项及理由的，乙方应于 10 个工作日内免费整改并重新提交验收，整改期间不构成甲方违约，交付期限不因整改而顺延乙方的违约责任。
X.6 累计整改两次仍未通过验收，或逾期交付超过 30 日的，甲方有权解除本合同，要求乙方全额返还已付款项并赔偿甲方由此产生的损失；已交付部分成果的知识产权归甲方所有。
建议展现方式：删除原后半句 + 新增独立验收条款。
风险 3：付款条款与验收条款被压缩在同一条内，权利义务结构混乱
- 风险等级：P1
- 相关条款：第二条
- 风险后果：付款与验收是两组独立且互为前提的义务群，压缩为一句话后，既无法表达节点对应关系，也无法在争议中定位适用条款；同时容易被解释为二者互不关联（这正是本合同当前的解释结果）。
- 判别标准：一个条款中同时规定两项以上核心义务且无内部编号的，属于结构缺陷。
- 整改建议：拆分为"合同价款与支付""交付与验收"两条独立条款，并在付款条款中明示以验收条款的完成为前提（见风险 1 推荐措辞 2.3、2.2(3)）。
- 建议展现方式：结构拆分。
风险 4："尾款"表述缺乏上位定义，金额与比例不明
风险等级：P1
相关条款：第二条"全部尾款"
风险后果：全文未出现合同总价、预付款、进度款的约定，"尾款"一词无所指代。实践中易被乙方主张为"除已付款外的全部剩余价款"，甲方无法确定付款上限；若发生变更或增项，更无计价依据。
判别标准：合同中出现"尾款""余款""剩余款项"等相对概念，但无绝对金额或计算基数的，均需补足。
整改建议：先约定合同总价（含税、币种、是否含差旅与第三方软硬件费用），再定义各期款项的绝对金额或百分比；同时约定变更增项须经甲方书面确认方可计价。
推荐措辞：见风险 1 推荐措辞 2.1、2.2；另补入：
本合同价款为固定总价，已包含乙方为履行本合同所需的全部人工、差旅、税费及第三方组件授权费用。未经甲方事先书面确认的任何增项，甲方不承担付款义务。
建议展现方式：局部补入。
风险 5：乙方逾期交付、交付不合格无任何违约责任
风险等级：P0
相关条款：全文（第三条仅为"未尽事宜另行协商"占位）
风险后果：合同仅规定甲方的付款义务（且是无条件的时间义务），未规定乙方任何履行期限、质量标准与违约后果。权利义务严重不对等：甲方逾期付款可能被追究违约责任（甚至适用法定利息），而乙方逾期交付、交付废品无任何成本。这是本合同最根本的失衡点。
判别标准：委托方一侧仅承担付款义务，受托方一侧无期限、无标准、无违约金的，视为对委托方重大不利。
整改建议：补入交付期限、逾期违约金（建议按合同总价日万分之三至万分之五计，上限 10%–20%）、质量违约的修理／重作／减价／解除救济，并明确甲方的单方解除权与已付款返还机制。
推荐措辞：
第【X】条 违约责任
X.1 乙方逾期交付的，每逾期一日应按合同总价的 0.05% 向甲方支付违约金；逾期超过 30 日的，甲方有权解除合同，乙方应全额返还已收款项并支付合同总价 20% 的违约金。
X.2 交付成果不符合本合同及附件约定的，甲方有权要求乙方限期免费整改、重作或相应减少价款；给甲方造成损失的，乙方应予赔偿，赔偿范围包括甲方为完成开发另行委托第三方的费用差额及合理维权费用（律师费、公证费、诉讼费等）。
X.3 乙方交付成果侵犯第三方知识产权的，由乙方独立承担全部责任并赔偿甲方全部损失，该项赔偿不受本合同其他责任限制条款约束。
建议展现方式：新增条款。
风险 6：核心条款大面积缺失，第三条为空白占位
- 风险等级：P0
- 相关条款：第一条、第三条
- 风险后果：合同缺少标的与需求范围、开发周期与里程碑、知识产权归属（开发成果、源代码、后台工具、预存代码的权属与授权范围）、保密与数据合规、人员与分包限制、售后与运维、不可抗力、通知送达、争议解决与管辖、生效条件与份数等条款。第一条为空洞的鉴于条款，未载明合同标的；第三条"未尽事宜另行协商"无法填补上述空白。软件开发合同中，知识产权归属条款缺失对甲方尤其致命——若无约定，依《著作权法》第十九条，委托作品著作权可能归受托人（乙方）享有，甲方付了全款却拿不到成果权属。
- 判别标准：核心条款（标的、价款、期限、质量、违约、知识产权、争议解决）缺任一项即为 P0。
- 法律依据：《著作权法》第十九条（委托作品未约定或约定不明的，著作权属于受托人）；《民法典》第八百五十九条至第八百六十一条（技术开发成果权属）；第四百七十条（合同一般条款）。
- 整改建议：不建议在现有文本上打补丁。建议以规范的软件开发服务合同范本为基础重新出文，并至少补齐：
- 合同标的与需求范围（附《需求规格说明书》）；
- 开发周期与里程碑计划；
- 交付与验收（见风险 2）；
- 价款与支付（见风险 1）；
- 知识产权归属：明确开发成果（含源代码、文档、设计稿）的著作权及其他知识产权自甲方付清相应款项之日起归甲方所有；乙方使用的开源组件须列明清单及许可证类型，且不得使用具有传染性开源协议（如 GPL）而影响甲方使用；
- 保密与个人信息／数据安全；
- 人员稳定与禁止未经同意分包；
- 质保期与运维；
- 违约责任（见风险 5）；
- 争议解决（建议约定甲方所在地人民法院管辖）、通知送达（明确电子邮箱／微信为有效送达方式）、生效条款。
- 建议展现方式：整体重拟。
三、风险汇总表
| 序号 | 风险点 | 等级 | 处理方式 |
|---|---|---|---|
| 1 | 尾款绑定"合同生效后 30 日"，与验收脱节 | P0 | 整条重写为节点付款 |
| 2 | "交付后视为验收合格"，验收权被架空 | P0 | 删除拟制 + 新增验收条款 |
| 3 | 付款与验收混于一条，结构混乱 | P1 | 条款拆分 |
| 4 | "尾款"无总价与基数 | P1 | 局部补入 |
| 5 | 乙方无期限、无质量、无违约责任 | P0 | 新增违约条款 |
| 6 | 知识产权等核心条款整体缺失 | P0 | 整体重拟 |
四、签署前先决事项清单
- 取得并作为附件固定《需求规格说明书》或《技术方案》，作为验收唯一依据。
- 确认合同总价、税费口径与开票安排，据此确定四段式付款比例。
- 明确开发周期、里程碑与最终交付日。
- 确认知识产权归属安排（建议全部归甲方），并要求乙方提供开源组件清单。
- 核验乙方主体资格：营业执照经营范围是否涵盖软件开发、是否具备实际开发能力、签署人是否有授权。
- 补入违约责任、保密、争议解决与管辖条款。
五、谈判优先级
- 第一顺位（P0，不可让步）：尾款绑定验收合格（风险 1）、恢复甲方验收权并删除"视为验收合格"（风险 2）、知识产权归甲方（风险 6）、乙方逾期与质量违约责任（风险 5）。
- 第二顺位（P1）：合同总价与付款基数明确（风险 4）、条款结构拆分（风险 3）。
- 第三顺位（P2）：文本表述、编号、通知送达等技术性优化。
六、审查结论
不建议签。
理由：本合同第二条将全部尾款支付绑定于"合同生效后 30 日"这一与履行进度无关的时间条件，同时以"交付即视为验收合格"取消甲方验收权，两者叠加使甲方在乙方未实际履行或履行不合格的情况下仍负有全额付款义务，付款与对价严重脱钩；且合同缺失标的范围、交付期限、知识产权归属、违约责任、争议解决等全部核心条款，乙方一侧无任何可执行的约束。以现有文本签署，甲方将处于"先付全款、无验收权、无追责依据、可能拿不到成果权属"的境地。
修改后可签的条件：完成上述"签署前先决事项清单"全部 6 项，并落实第一顺位 P0 修改（尾款绑定验收、恢复验收程序、知识产权归甲方、补足乙方违约责任）后，可再次提交复核。建议不在现有三条文本上修补，直接以规范的软件开发服务合同重新出文。
七、说明
- 本次审查仅基于所提供的合同正文，未见需求文档、报价单、双方主体资料及往来磋商记录，涉及商业条件的部分已标注"未提及/待补充"。
- 本意见中的金额、比例、期限均为基于常规实务的建议值，需结合本项目实际商业安排调整。
- 本轮为文字版审查意见。如需交付审核修订版 DOCX 与 Word 审查意见书，请提供可访问的 DOCX 原件并确认审查人姓名与所属机构/公司。