付款前一周才翻验收？没有证据包的里程碑，到期日只是催款日历
日历亮了绿灯、现场演示了一遍、纪要写「基本完成」——这些都不构成验收。能签字的是：约定交付物齐不齐、检查表勾没勾、缺陷是否低于事先门槛。
读这一篇能得到什么
- 里程碑管理的单位是证据包，不是日历上的一个点
- 验收结论用通过 / 附条件通过 / 不通过三态；附条件必须带遗留项、责任人与关闭期限
- 付款触发认证据齐套，不认「日期到了」；无证据不启动请款
- 内部验收与客户验收分层，内验通过只是状态机一站，不是完成
- 延期要记客户 / 己方 / 共同原因码；范围变更必须回写交付物与检查表
尾款前七天的会议室
客户翻开合同附件，指着三条「当时口头答应过」的功能；实施翻开计划，指着「里程碑已标完成」；销售说「先签再补材料」。三小时后散会，谁也说不清：完成定义写在哪、缺陷门槛是多少、遗留项谁关、关不完能不能请款。
扯皮很少诞生在签字当天。它早在立项就把里程碑做成了只有日期的点——甘特好看，证据链空。到了付款周，才用人脑临时发明标准，贵且伤关系。
日期到了，不等于可验收
现场最常见的五种「假完成」：
| 说法 | 实际缺什么 | 往后会怎样 |
|---|---|---|
| 日期到了先签，材料后补 | 证据永久补不齐 | 付款纠纷与审计双杀 |
| 差不多能用了 | 无检查表 | 客户日后以缺陷拒付 |
| 内部已经验过了 | 未走客户侧 | 客户打回，进度假绿 |
| 小问题下次再改 | 附条件无期限 | 遗留项吞掉下一阶段 |
| 演示跑通就算 | 无门槛数字 | 临场谈判替代合同 |
当场抽检一招就够：任取一个「已完成」里程碑，能否导出交付物清单、检查表勾选、三态结论、遗留项状态、是否已触发请款。导不出完整包，那个点只是日历装饰。
证据包长什么样
可付款的里程碑，证据通常不少于五类：
- 交付物清单（含版本、环境、责任方）
- 检查表勾选结果（事先与客户书面对齐过的那一版）
- 缺陷清单与门槛说明（致命/严重为零、一般缺陷上限等，事先数字化）
- 双方签字或等效电子确认
- 遗留项关闭计划（若走附条件：描述、关闭标准、责任人、计划关闭日）
缺一类就判「未完成」，比口头「差不多」干净。制造现场类里程碑还可加安全交底、试运行参数、备件与培训签到——这些常是尾款争议点，宜写进模板而不是临场想起。
部分验收不是禁区，危险的是边界不清：哪些算本里程碑、哪些明确排除、排除项何时交付。写不清，尾款阶段会被重新打开。
三态结论，比「完成/未完成」诚实
只有两态时，现场会把「勉强能演示」挤进完成。三态把诚实留给系统：
- 通过：检查表达标、缺陷低于门槛、无未关闭阻塞项。
- 附条件通过：可付款或可进入下一阶段，但遗留项字段齐全；缺责任人、期限或关闭标准，不允许点附条件。
- 不通过：材料不全、缺陷超门槛或关键交付物缺失——回到计划，而不是靠销售压签。
内部验收与客户验收必须分层。内验过滤低级问题（环境不对、账号没有、演示数据是假的），这些不该第一次出现在客户面前。内部通过只是状态机一站，不是完成。
钱认证据，不认日历
JEDP-PMS 在执行侧管交付物与问题/风险，在结案侧管文档齐套、验收回款与多维报表；验收超期可进风险预警。业务上要落成的规则很简单：
| 能力 | 落法 | 意义 |
|---|---|---|
| 里程碑模板 | 目标、交付物、检查表、责任方、计划/实际日期 | 每个点可验收，而非只可「标完成」 |
| 齐套校验 | 必传附件与检查项 | 缺件不能点通过 |
| 分层状态 | 内验通过后才可提交客验 | 减少客户侧反复 |
| 付款触发 | 通过，或附条件且无超期遗留 | 证据优先于日期 |
| 责任码 | 客户/己方/共同原因分类 | 扯皮时有时间戳 |
请款建议只认系统「可请款」状态，不认项目经理邮件。视同验收若写进合同，系统要留提交与催告轨迹：客户在完整提交后约定工作日内未书面提出不符合项，可视为通过——关键是轨迹可审计，不是口头「你们早该签了」。
变更若不同步，验收验的是旧合同
批准的范围增量若未写入交付物与检查表，客户按旧标准验、实施按新范围做，冲突必然在签字前爆发。WBS 基线与变更准入是上游闸门；里程碑证据包是下游兑现。上游 silent pass（邮件里「再说」、现场先做后补），下游再勤补材料也补不圆。
验收超期、附条件遗留逾期，应按规则进入风险登记节奏（主人、复核日、关闭证据），而不是只在催款邮件里出现一次。回款节点绑证据包之后，销售与项目经理的目标才一致——催的是齐套，不是日历。
别一上来全合同自动化
务实顺序往往是：先与客户（或内部甲方）书面确认近两个付款里程碑的检查表 → 配置三态与遗留项、禁止无附件点完成 → 财务只认系统可请款状态 → 再推广到其余合同里程碑，并把验收超期纳入周清。制造业数字化类项目可对照更细的清单（环境、主数据、权限、培训、切换方案），原则相同：先书面标准，再系统状态，最后绑钱。
不宜硬上的情况也很清楚：验收标准尚未书面确认时，不要上自动付款；交付物只写「系统上线」这类粗话时，先拆成可检查条目；多方签字人未理顺时，先定代理规则，否则系统卡单比线下更慢。纯按月服务费的持续交付，可用迭代验收纪要替代重型里程碑，但仍需每期证据包与客户确认。
观察时不必迷信「一次性通过率」单一数字。更有用的是：附条件占比与按期关闭率、客户验收耗时（结合催告次数区分材料不全与客户拖延）、因验收阻塞的回款金额、范围变更后验收清单是否已更新。一次性通过率过低，多半是内验不足或标准未对齐；附条件高不可怕，遗留超期才可怕。
售前埋下的坑，执行期才会爆炸
许多扯皮其实在售前就埋好了：方案里写「支持某某能力」，合同交付物却只写「系统上线」；演示环境是样板数据，客户以为验收环境同款；培训签到被当成「用户已具备操作能力」，却没有任何抽检题。售前与交付若共用同一套里程碑模板语言——交付物颗粒度、检查表粒度、缺陷门槛——后期谈判空间会小很多。
项目经理周报里的「进度百分比」也不宜替代证据完整度。战情室更该看见：下一付款里程碑的证据包缺哪几类、阻塞项是谁、附条件遗留是否临期。百分比好看、证据空洞，只会让管理层在付款周才第一次认真读合同附件。与 CRM/合同付款条款对齐时，商务侧的节点名称应能映射到 PMS 里程碑 ID，避免两边各喊一套「二期验收」却不是同一包东西。
外包或集成多方交付时，证据包要按责任切分：谁提交哪类交付物、谁有权点内验、谁代表客户侧签字。把「大家一起验收」写成唯一责任人，出问题一定互相推。签字代理规则（出差、授权书有效期）也应事先写清，否则系统里卡单比邮件往返更慢。
本周只写一页检查表
打开下一个付款里程碑，把检查表压成一页纸，本周内与客户对签字。比再开三次「推进验收」会更能减少扯皮。签完入库，再谈系统里能不能点通过——顺序反了，系统只会把临场谈判电子化。若客户当场改检查表，把改动记成版本并双方确认，不要默默用旧表继续点通过。
想把这篇里的做法落到自己的厂里？资源中心有对应场景的在线自测与资料模板，也可以直接约一次真实环境演示。
常见问题
围绕本篇主题的追问，先看这里；仍有疑问可联系我们
客户一直拖着不签怎么办？
合同写清视同验收条件与催告流程；系统保留提交、催告与响应时间戳，作为责任与账期依据，而不是靠项目经理私聊催签。
能不能先验收一部分功能？
可以，但本里程碑范围与排除项要书面冻结；排除项进后续里程碑或变更，禁止口头「先收一笔再说」。
文档类交付怎么验才不主观？
事先给模板与检查表，按项勾选。没有模板就不要把「写一份文档」当成硬里程碑。
延期责任怎么定？
区分客户原因、实施方原因、共同原因，用变更单与责任码留痕；责任未分清时不要先开付款。
附条件通过会不会永远挂着？
会，除非遗留项有关闭期限、责任人与逾期升级。超期遗留项应预警，并阻断下一笔付款触发。