软件著作权评估，成本法用得最多，也最容易出错。原因很简单：软件的成本容易统计（多少人、多少月、多少工资），但成本与价值之间没有稳定关系。
一套投入 300 万元开发的软件，可能卖了 8000 万元；也可能一套投入 2000 万元的软件，上线三年无人问津。成本法算的是“重做一遍要花多少钱”，回答不了“它能挣多少钱”。
一、陷阱一：人力成本口径不一致
重置成本的核心是人力投入。常见的口径混乱：
- 用实际历史工资，还是用当前市场工资：重置成本应使用评估基准日的市场人力价格，不是当年的工资单。三年前的开发人员月薪 1.8 万元，现在同岗位 2.6 万元，直接套历史工资会低估 30% 以上。
- 是否含五险一金与办公分摊：完整的人力成本应包括工资、社保公积金（约工资的 30%-40%）、办公场地分摊、设备折旧、管理费分摊。只算工资，成本低估 40% 左右。
- 是否含外包与采购：第三方组件、云服务、测试服务的采购支出，属于重置成本的组成部分。
二、陷阱二：把所有项目都算进来
企业的研发投入总额，不等于某款软件的重置成本。
- 失败项目、废弃版本、试验性开发，不应计入；
- 多个产品共用的底层平台，要按受益比例分摊，不能全部计入某一个产品；
- 定制开发项目中，为特定客户做的个性化功能，价值依附于该客户合同，不应计入通用软件的价值。
三、陷阱三：遗漏后续维护与升级成本
软件不是一次开发完就结束。评估基准日后，为维持软件可用、适配新系统、修复漏洞，需要持续投入。这部分支出在收益法里是成本，在成本法里也应体现——如果重置的是“基准日状态”的软件，那么达到该状态所经历的所有版本迭代投入都应计入；如果重置的是“可运行版本”，则后续维护成本要在收益中扣除。
两种口径不能混用。常见错误是：成本按最初版本计算，收益按当前版本预测，两头占便宜。
四、陷阱四：功能性贬值与价值脱钩
软件的技术迭代极快。一套 2018 年开发的系统，即使功能完好，也可能因为架构老旧（单体架构 vs 微服务）、技术栈过时（已停止维护的框架）、无法上云，而产生巨大的功能性贬值。
量化方法：按重构或迁移的成本计算。若迁移到新架构需要投入原开发成本的 60%，功能性贬值就是重置成本的 60%。
更根本的问题是：成本法完全不反映软件的商业模式价值。SaaS 软件的估值取决于 ARR、留存率、客户获取成本，与代码行数无关。
五、一个 ERP 软件的对照案例
某软件公司以自主研发的 ERP 系统著作权出资，拟作价 3000 万元。公司提供了研发投入台账：2019-2023 年累计投入 2860 万元（工资 1980 万元、外包 420 万元、云服务 260 万元、差旅 200 万元）。
评估机构用成本法测算：
- 按基准日市场工资重算人力成本：由 1980 万元调整为 2640 万元；
- 加社保公积金与办公分摊（按工资的 35%）：924 万元；
- 外包与云服务按原值计入：680 万元；
- 剔除失败项目（两个已废弃的模块，投入 310 万元）；
- 扣除功能性贬值（架构需重构，按 40% 计）；
- 重置成本合计约 2760 万元，扣除贬值后 1656 万元。
同时用收益法测算：该软件已服务 62 家客户，年订阅收入 1850 万元，续费率 88%，按可比 SaaS 公司 PS 4.5 倍（考虑规模折价），评估值约 8300 万元。
两个结果差 5 倍。最终采用收益法结论，评估值 7800 万元（考虑客户集中度折扣）。
这个案例说明：对已商业化的软件，成本法只能作为下限验证；对未商业化的软件（内部工具、在研产品），成本法才可能是主要方法。
六、什么时候该用成本法
- 软件尚未投入商业使用，无收入可预测；
- 软件为内部管理工具，不对外销售；
- 软件开发失败或已停止维护，只剩代码资产；
- 作为收益法的交叉验证，判断收益法结论是否偏离成本太多。
其余情形，优先用收益法（许可费节省法或增量收益法）或市场法（可比软件交易）。
七、操作清单
- 明确评估对象：软件名称、版本号、登记号、著作权人；
- 核查著作权登记证书与源代码归属（职务作品 vs 委托开发）；
- 人力成本按基准日市场价重算，含社保与分摊；
- 剔除失败项目与非受益项目的投入；
- 共有平台按受益比例分摊；
- 测算功能性贬值（重构成本、迁移成本）；
- 已商业化的软件优先用收益法；
- 成本法与收益法差异过大时，说明原因并取舍；
- 开源组件与第三方库的合规性一并核查；
- 报告中披露软件的版本、客户数、收入等关键事实。
成本法给的是“投入了多少”，收益法给的是“值多少”。软件行业里，这两个数经常差得很远，评估师要做的是解释差距，而不是选一个好看的填进报告。
