外包合同里最常见的付款写法是"按月付""按进度付"，听上去合理，实际埋着大坑：付款一旦挂时间，就会与成果脱钩。本文给出一个把付款节点与验收节点严格绑定的结构，并说明尾款比例为什么不能太低。
核心原则：付款挂验收，不挂时间
"时间到了就付款"的写法，会让甲方在最需要约束力的阶段失去筹码。正确的做法是：每个付款节点都对应一次明确的验收动作和一份产出物。没通过验收，就不进入下一个付款节点。
一种可参考的节点结构
| 节点 | 触发条件 | 产出物 |
|---|---|---|
| 预付款 | 合同签订 | 合同、项目计划 |
| 二期款 | 需求与原型验收通过 | 需求规格、原型 |
| 三期款 | 设计验收通过 | 设计源文件、设计规范 |
| 四期款 | 开发完成并提交测试 | 测试版本、测试报告 |
| 五期款 | 验收测试通过 | 验收报告、缺陷清零 |
| 六期款 | 上线试运行稳定 | 上线记录、运维手册 |
| 尾款 | 缺陷责任期满 | 源码与账号交接完成 |
这套结构的要点不是"分几期"，而是每一期都有可验收的产出物。期数可以按项目规模调整，但"产出物"这一列不能省。
尾款比例为什么不能太低
尾款是缺陷责任期内的约束力来源。比例过低，开发方在项目后期就失去了响应的动力；比例过高，又可能影响开发方现金流与合作意愿。行业里常见的做法是保留一定比例的尾款，与缺陷责任期挂钩，具体比例由双方根据项目周期商定。
变更与付款的关系
需求变更会带来工作量变化，必须走书面变更单：提出 → 评估工作量 → 双方书面确认 → 调整工期与费用。变更单是付款调整的依据，没有变更单就调整费用，很容易变成"扯不清的加钱"。口头约定在争议时几乎无法举证，所有变更都要落到书面。
合同里要写清的四件事
- 每个付款节点的触发条件（对应哪次验收）
- 每个节点的产出物清单
- 变更流程与变更单模板
- 尾款与缺陷责任期的挂钩方式
预付款给多少才合理
预付款是启动阶段的信任成本。给太少，开发方没有启动动力；给太多，甲方在前期就失去了约束力。行业里常见的做法是预付款覆盖启动所需的人力与采购成本，而不是覆盖整个前期阶段。具体比例需要结合项目周期与双方合作基础商定，没有放之四海皆准的数字。
一个实用的判断方法：把每个节点的付款比例，与该节点交付物的"可验收程度"对应起来。产出物越难验收，付款比例就该越低。
三个容易踩的付款细节
- "验收通过"由谁确认：是甲方单方确认，还是双方会签？不写清容易出现"我通过了、你没通过"的僵局；
- 发票与付款的先后：先票后款还是先款后票，涉及双方财务流程，提前约定；
- 逾期的处理：甲方逾期付款、乙方逾期交付，各自的责任与宽限期。
里程碑怎么定才合理
里程碑的常见错误是"按时间切"：第一个月、第二个月、第三个月。合理的切法是"按可交付成果切"：
- 需求与原型确认 → 可以验收的文档；
- 设计定稿 → 可以打开的设计源文件；
- 开发完成 → 可以运行测试版本；
- 上线 → 可以访问的线上系统。
按成果切，每个节点都有实物可查；按时间切，节点到了却可能什么都没交付。里程碑的意义不在于"过去了多久"，而在于"产出了什么"。
付款节点设计得好，项目风险就小一半。它决定了你在项目不同阶段的约束力：前期给足启动信心，中期绑定成果，后期保留追责筹码。签合同前把这张节点表填完整，比任何口头承诺都可靠。