项目延期与增项费用不能混为一谈。延期回答的是“为什么没有按期交付”，增项回答的是“原约定范围是否发生了变化”。前者首先涉及责任归属，后者则取决于新增工作量和成本。只有把交付范围、延期原因、实际投入三条线分开核对，才能判断费用是否成立。
先判断延期责任
如果需求没有变化，开发方因排期、沟通或交付管理未完成原定功能，通常属于原范围内延期。此时，开发方应先说明补救计划和新的交付时间，不能仅因日历顺延就自动向客户收取增项费用。若延期期间团队仍持续开发、修复问题或重新安排人员，则可能产生实际人力投入，但是否由客户承担，仍要结合合同约定和延期原因判断。
如果客户迟迟未提供资料、账号或审核意见，或者双方反复调整已经确认的方案，延期责任就需要重新划分。第三方平台审核、支付接口或应用市场政策变化造成的延误，也不能直接归责于任一方，应核对配合义务和合同约定。
再判断是否构成增项
需求变更的关键，不是增加了几个页面或按钮，而是是否超出需求说明书、原型图和验收标准。新增审批节点、抄送人员、审批记录和消息提醒，已经属于业务流程扩展；调整核心流程、数据结构或多个端的功能，则可能同时增加开发、联调和测试成本。
相反，开发方漏做功能、未按确认原型实现，或修复自身代码问题，通常属于原项目交付责任，不应直接包装成客户增项。企业应要求对方提交变更单，写明变更内容、影响模块、增加人天、增加金额、是否顺延及双方确认记录。
用证据拆分费用
延期费用不能只按“多了多少天”计算，更应核对延期期间实际投入的人天、返工范围、第三方费用和上线窗口影响。需求变更可按“新功能开发成本＋受影响模块返工成本＋额外测试成本”拆分；延期新增费用则可按“延期投入人天×人天单价＋第三方费用＋返工费用＋上线窗口损失成本”估算。
最终判断标准很明确：原范围未完成，先追责；范围发生变化，再评估增项；两者同时存在，则分别列项、分别定价，避免用一个总价掩盖责任边界。
