计算机软件开发合同纠纷中,已开发成果的价值如何认定?

计算机软件开发合同纠纷中，开发方已交付的代码、软件到底"值多少钱"？委托方能否仅以"未通过验收"为由要求全额退款？最高人民法院知识产权法庭在一起软件开发合同纠纷案中给出了明确回应：不能将阶段付款简单等同于阶段成果对价，合同解除不等于当然恢复原状。本文将以此为切入点，系统梳理计算机软件开发合同解除或终止后，已开发部分工作成果价值认定的法律依据与裁判路径，以期为实务办案提供参考。

一、问题的提出

1. 基本案情

甲乙公司签订软件开发合同，约定由乙公司为甲公司开发"水客168"软件，总价22万元，分三期支付。乙公司完成UI设计并获验收，交付多端软件版本及2937个文档，收取前两期款项共11万元。后双方发生争议，甲公司通知解除合同并要求返还已付款，乙公司反诉请求支付第三期开发款。

2. 一审裁判逻辑及误区

一审法院认为乙公司未交付符合约定验收标准的后续成果，认定其违约，判决解除合同并返还甲公司已付款，一审将每一阶段收取的款项理解为仅针对该阶段工作成果的对价，将软件开发的整体工作割裂为互不关联的片段。

3. 二审最高人民法院知识产权法庭核心观点

（1）  软件开发合同解除后并非当然恢复原状，应视个案情况而定。根据《民法典》第566条的规定，合同解除后已经履行的部分并非当然恢复原状，而是应根据履行情况和合同性质加以权衡；

（2）  应综合考量计算机软件开发合同自身特点、开发方实际履行情况、开发方有无过错及过错大小、开发方实际投入的工作量及已完成的开发成果等多种因素，秉持诚信原则和公平原则加以判断；

（3）  无视上述第二点事实，刻意将软件开发整体工作割裂为互不关联的片段，单纯将每一阶段收取的款项局限理解为仅针对该阶段工作成果的对价，进而认为合同一经解除便应当恢复原状，开发方须返还已收取的全部或部分开发款，既不符合计算机软件开发合同的履行特征，也有违诚信原则和公平原则；

（4）  乙公司已完成的工作量与已收取款项之间不存在明显比例失衡，无需返还已收款项。

4. 案例揭示的实务痛点

（1）验收标准主观化软件功能需求约定往往较为笼统，委托方常以"不符合预期""功能不满足要求"等主观标准拒绝验收，缺乏客观、可操作的量化标准。本案中甲公司主张乙公司未交付符合验收标准的成果，但其所依据的《检测问题总结》系单方制作，被二审法院认定缺乏证明力。

（2）部分履行的价值难以量化软件具有无形性、模块耦合性等特征，开发进度比例不能简单等同于价值比例。一审法院将开发成果与合同款作机械的一一对应理解，被最高人民法院明确指出"不符合计算机软件开发合同的履行特征"。

（3）证据与鉴定难开发方交付的成果不易固定，委托方证明缺陷成本高；司法鉴定周期长、费用高，部分案件鉴定费用高达数十万元，远超争议标的额本身，可能加重当事人负担。

基于上述分析，本文聚焦以下核心问题：计算机软件开发合同解除后，已开发的部分成果能否获得折价补偿？其价值如何认定？举证责任如何分配？

二、法律分析：工作成果价值认定的法律框架与裁判路径

（一）计算机软件开发合同的法律性质

1. 合同定义与类型计算机软件开发合同属于技术合同中的技术开发合同。《民法典》第八百四十三条规定："技术合同是当事人就技术开发、转让、许可、咨询或者服务订立的确立相互之间权利和义务的合同。"技术开发合同是当事人之间就新技术、新产品、新工艺、新品种或者新材料及其系统的研究开发所订立的合同。技术开发合同进一步分为委托开发合同和合作开发合同。在司法实务中，计算机软件开发合同纠纷常见于委托开发合同，即委托方（软件使用者）为满足其特定的商业或技术需要，与开发方（软件开发者）订立的关于开发特定软件或使已有软件适配此种需要的合同。

2. 软件开发合同的双重属性计算机软件开发合同兼具技术开发合同与承揽合同的双重特征。一方面，其以"开发"为核心内容，旨在产生新的技术成果，应适用《民法典》技术合同一章的特殊规则；另一方面，开发方按照委托方的特定需求"定制"软件，以完成特定工作成果为合同标的，符合承揽合同"承揽人按照定作人的要求完成工作，交付工作成果，定作人支付报酬"的基本特征，因此可以参照适用承揽合同的相关规则。这种双重属性决定了其在合同解除后果处理上具有特殊的复杂性，既不能简单适用承揽合同关于工作成果检验的规则，也不能完全排除承揽合同规则的参照适用。

（二）技术开发合同的特殊规定

技术开发合同在解除权、风险负担、通知义务及无效处理等方面存在不同于一般合同的特殊规定，这些规定对软件开发合同纠纷中成果价值认定具有直接影响。

1. 技术开发合同的解除权

《民法典》第八百五十七条规定："作为技术开发合同标的的技术已经由他人公开，致使技术开发合同的履行没有意义的，当事人可以解除合同。"这是技术开发合同的法定解除事由，其立法本意在于：技术开发合同以"创新"为核心价值，一旦标的技术已公开，合同目的即告落空，继续履行已无实际意义。在软件开发合同纠纷中，若开发过程中出现第三方已公开了相同功能的解决方案，当事人可据此行使解除权，此时已开发成果的价值认定应结合该公开技术对合同目的的影响进行判断。

2. 技术开发合同的风险负担

《民法典》第八百五十八条规定："技术开发合同履行过程中，因出现无法克服的技术困难，致使研究开发失败或者部分失败的，该风险由当事人约定；没有约定或者约定不明确，依据本法第五百一十条的规定仍不能确定的，风险由当事人合理分担。"该条确立了技术开发合同特有的"风险合理分担"规则，而非简单适用一般合同违约责任的归责原则。其规范意义在于：技术开发本身就具有不确定性和探索性，研发失败并不当然等同于开发方违约，而可能构成"技术开发风险"，应由双方合理分担。在计算机软件开发合同中，若因技术瓶颈（如算法无法实现预期精度、系统架构不兼容等）导致开发部分失败，法院不应径行认定开发方违约，而应依该条判断是否构成技术开发风险，进而决定开发方是否享有报酬请求权。

3. 技术开发合同无效或被撤销后的处理

《最高人民法院关于审理技术合同纠纷案件适用法律若干问题的解释（2020年修正）》第十一条规定："技术合同无效或者被撤销后，技术开发合同研究开发人、技术转让合同让与人、技术许可合同许可人、技术咨询合同和技术服务合同的受托人已经履行或者部分履行了约定的义务，并且造成合同无效或者被撤销的过错在对方的，对其已履行部分应当收取的研究开发经费、技术使用费、提供咨询服务的报酬，人民法院可以认定为因对方原因导致合同无效或者被撤销给其造成的损失。"该条确立了技术合同无效或被撤销后的损失赔偿规则。其核心逻辑在于：即便合同整体无效，若开发方已部分履行且过错在对方，已履行部分的价值可转化为损失赔偿请求权。这为软件开发合同解除后成果价值的折价补偿提供了参照法理，合同解除与合同无效虽法律后果不同，但在"已履行部分客观上无法恢复原状、应转化为价值补偿"的逻辑上具有相通性。

（三）合同解除后果的一般规则与软件合同的特殊性

计算机软件开发合同解除后，已履行部分的处理应适用《民法典》第五百六十六条第一款："合同解除后，尚未履行的，终止履行；已经履行的，根据履行情况和合同性质，当事人可以请求恢复原状或者采取其他补救措施，并有权请求赔偿损失。"软件开发合同的履行具有持续性、阶段性、无形性等特征，已履行部分难以甚至无法恢复原状，故"折价补偿"成为主要的救济方式。而折价补偿的前提，正是对已开发部分工作成果的价值认定。

软件成果的特殊性进一步加剧了价值认定的复杂性：

（1）无形性：软件以源代码、目标代码等形式存在，不具有物理形态，无法像有形财产那样"返还"；

（2）可复制性：开发方交付源代码后，委托方可以复制留存，而开发方也可以保留副本；

（3）阶段性交付：软件开发通常采用敏捷开发或迭代开发模式，成果分阶段交付，各阶段成果之间具有延续性和依存性；

（4）价值依附性：软件价值主要依附于源代码及技术文档，凝结了开发方的人力成本和技术投入。

这决定了软件开发合同解除后的处理不能简单适用一般动产的"恢复原状"规则，而必须在价值形态上寻求公平的折价补偿方案。

（四）典型案例的裁判逻辑

回到本案，在厘清上述法律框架后，可以更深入地理解其裁判逻辑：

第一，合同解除后的处理应遵循"终止履行—恢复原状（含折价补偿）—赔偿损失"的递进逻辑。一审法院的错误在于以解除即否定一切给付，跳过了对已履行部分价值的独立判断。二审法院则首先确认了解除的效力（终止履行），继而评估已履行部分是否应当恢复原状，最终通过折价补偿的方式维持了既有的给付状态。

第二，价值认定层面，综合多种因素而非以验收为唯一标准。二审法院综合考察了合同特点（软件开发具有连续性和整体性）、履行情况（UI验收、多终端交付、2937个文档）、过错大小（甲公司拒绝沟通）、投入工作量等多重因素，得出了"工作量与已收款项之间不成比例失衡"的结论。

第三，证据层面，客观证据优于单方主张。乙公司提供的验收单、邮件交付记录、文档清单等客观证据被采信，而甲公司单方制作的《检测问题总结》因缺乏客观性未被采信。开发方就交付事实承担举证责任，委托方就成果缺陷负举证责任，这一分配规则在本案中得到了清晰体现。

第四，裁量层面比例原则的适用，只要已完成的开发工作量与已收取的款项之间不存在明显比例失衡，即可维持既有的给付状态，无需返还。这为同类案件提供了清晰的裁量参照。

三、已开发部分价值认定的主要标准

综合最高人民法院典型案例裁判规则及司法实践，工作成果价值的认定主要遵循以下四项标准：

标准一

以合同约定的功能需求为首要认定标准

法院通常以合同文本、附件（如需求说明书、技术协议）约定的功能点、技术指标为基准，结合行业习惯进行解释。若开发成果实现了合同约定的核心功能，即使存在部分非核心功能瑕疵，通常不认定为根本违约，工作成果仍具有相应价值；若成果完全不具备合同约定的关键功能，或使用了完全不同的技术架构，则认定工作成果价值极低甚至为零。

需求变更的认定规则：若在开发过程中，双方通过微信、邮件等书面形式对功能需求进行了变更或补充，法院会将其视为对合同内容的补充，并以此作为认定工作成果是否达标的依据。这也提示当事人：需求变更的书面确认，不仅是合同内容的变更依据，也是后续价值认定的重要证据。

标准二

以实际履约与交付情况为客观认定标准

书面确认文件的证据效力：经双方签署的《验收报告》《源代码移交确认书》或《上线申请单》具有极强的证据效力，法院通常以此推定工作成果符合约定，或推定已交付并达到阶段性或最终验收标准。若委托方已实际接收软件、投入商业使用或支付部分尾款，通常视为对交付成果的认可，工作成果价值得以确认。

当庭演示与勘验：在缺乏书面确认的情况下，法院会通过当庭演示、现场勘验或委托第三方鉴定的方式，核实软件实际实现的功能点与合同约定功能点的比例，以此估算工作成果的实际价值（如按完成功能点比例折算）。

工作量与人力折算：若合同约定不明或软件功能难以量化，法院会结合双方履约过程中的沟通记录（如微信、邮件）确认的实际工作量、人力投入（如人天、人时）及对应的单价，酌定工作成果的价值。

标准三

以软件功能实现度与合同目的为实质认定标准

软件行业具有"允许试错、持续迭代"的特点，法院通常不会苛求软件完美无瑕。若软件主体功能已实现，能够支撑核心业务并实现合同目的，仅存在局部Bug、界面瑕疵或优化需求，通常不否定工作成果的整体价值，委托方不能以此为由拒付全部尾款或要求全额退款。

若软件存在影响核心功能运行的实质性缺陷，导致软件完全无法使用或合同目的彻底落空，则工作成果无实际价值，开发方构成根本违约，需返还已收款或承担违约责任。

标准四

以公平与诚信原则为补充认定标准

在合同解除或双方均存在违约的情况下，法院会结合开发方实际投入的研发成本、已凝结的开发成果、双方的过错程度及行业特点，对已履行部分的工作成果价值进行合理酌定，避免机械适用"全有或全无"的裁判结果。这一标准尤其适用于合同约定不明、证据不足、双方均有过错等难以通过前述标准直接认定的情形。

四、实务启示：把"价值"固定下来

（一）合同订立阶段——防患于未然

1. 细化功能需求与验收标准合同正文及附件（需求说明书、技术协议）应尽可能明确约定功能点、技术指标、性能参数，避免使用"用户体验良好""界面美观"等主观标准。对于核心功能与非核心功能应分别列明，并约定不同功能模块的价值占比或对应的付款比例。

2. 明确阶段交付物与验收程序应约定各阶段的交付物清单（包括但不限于源代码、文档、UI设计图、测试报告等）、验收程序、验收期限及验收不通过的后果（如整改期限、整改后仍不通过的处置方式）。同时应明确约定：委托方在验收期限内未提出书面异议的，视为验收通过。

3. 约定需求变更的书面确认程序应在合同中设置专门条款，约定任何需求变更必须通过书面形式（包括邮件、补充协议等）确认，否则不产生变更效力。这有助于避免开发过程中需求蔓延导致的价值争议。

4. 合理设置付款节点与比例付款节点的设置应尽量与可独立验证的交付物相对应，而非笼统地与时间节点挂钩。同时应避免将前序付款与后序成果价值过度绑定，明确各阶段付款的性质（是阶段性结算还是预付款）。

（二）合同履行阶段——留痕即留权

开发方的证据管理要点

开发方应建立规范的文档管理体系，保留以下关键证据：

（1）需求确认文件（邮件确认、会议纪要、微信聊天记录等）；

（2）各阶段交付记录（交付时间、方式、内容清单）；

（3）验收申请及催告记录；

（4）第三方测试报告；

（5）工作量投入记录（人员、工时、内容）。

交付方式上，建议通过邮件发送并附回执，或通过版本控制系统（如Git）进行正式发布并保留日志。对于关键交付，应主动要求委托方签署书面的验收单或交付确认书。

委托方的证据管理要点

委托方应保留以下关键证据：

（1）需求变更的书面记录；

（2）收到交付物后的检验记录；

（3）缺陷清单及运行问题截图/录屏；

（4）催告记录（催促整改、要求履行等）。

委托方应特别注意：发现问题应及时以书面形式提出异议，避免因长期沉默而被视为对交付成果的默示认可。

此外，双方在履行过程中如需变更需求，应严格按照合同约定的书面确认程序进行，避免以口头或非正式方式调整开发内容。验收环节中，委托方应在约定期限内组织验收，确有问题的应出具具体的、可验证的缺陷清单，而非笼统地以"不符合要求"拒绝验收。

（三）争议发生后——理性选择救济路径

开发方在起诉或反诉时，应根据合同履行阶段合理设计诉请：若合同已符合解除条件，可在请求确认解除的同时主张折价补偿或确认无需返还已付款；若合同尚可继续履行，应优先主张继续履行及支付相应价款。应注意区分"已付款返还""折价补偿"与"赔偿损失"的不同法律后果和构成要件。

同时鉴于该类案件当事人对合同履行事实的证据固定程度较低，举证较为困难，尤其是委托方缺乏证据意识并在技术事实的说明上处于弱势地位，故案件事实常常处于真伪不明的状态，促使当事人倾向和解。且案件事实复杂，诉讼成本较高。计算机软件开发合同履行期间较长，履行过程中通常涉及需求的调整和变更，查明事实往往需要进行多次庭审。另外，有些技术事实需要鉴定，而鉴定费用普遍过高。因此通过协商确定一个合理的折价补偿方案，往往比继续诉讼更具经济效益。

结 语

计算机软件开发合同解除后，工作成果价值认定不能"一刀切"，不能仅以"未通过验收"为由否定成果价值，也不能将阶段付款机械等同于阶段成果的对价。

回顾本案中确立的裁判规则，应综合考量合同特点、履行情况、过错大小、投入工作量及已完成的开发成果等多种因素，兼顾鼓励技术创新与维护诚实信用的双重价值取向，促进软件产业的健康发展。