ASC 350-40 准则下的软件资本化：资本化与费用化决策实用指南

2024 年 Gartner 的一项调查发现，63% 的早期 SaaS 创始人对软件开发成本进行了错误的分类。这种错误会给他们带来双重损失：当分类看起来不严谨时，投资者会降低对其财务状况的评价；而审计师会在尽职调查期间指出这一问题，这可能会使融资轮次或出售进程推迟数月。

软件资本化不仅仅是一个会计技术问题。它直接影响 EBITDA、资产负债表，以及贷款机构、投资者和买家对你业务的看法。ASC 350-40 准则（以及 2025 年的一项重大更新）决定了哪些成本应立即计入损益表，哪些成本应分摊到未来几年。

本指南将详细介绍该标准的要求、ASU 2025-06 的最新修订、哪些成本可以资本化、哪些不能，以及正确处理这些成本对财务报表产生的影响。

ASC 350-40 涵盖的内容

ASC 350-40 是美国财务会计准则委员会 (FASB) 针对内部使用软件制定的准则——即公司为自身运营而构建或购买的软件，而不是作为主要产品出售给客户的软件。示例包括：

• 内部 CRM、ERP、人力资源或会计系统
• 云基础设施工具和 DevOps 平台
• 你为客户运营的 SaaS 平台（客户将其作为服务访问，而不是作为他们安装的许可软件）
• 内部数据管道、仪表板和分析工具
• 定制的工作流或后台自动化工具

如果你销售的是由客户安装在自己机器上的许可软件，则属于 ASC 985-20（对外销售的软件）范畴，该准则有不同的规定。大多数现代 SaaS 公司都属于 ASC 350-40 范畴，因为客户是以托管服务的形式消费软件的。

该准则回答的核心问题是：当你花钱构建软件时，这笔费用是应该立即计入费用，还是作为无形资产资本化并在未来期间进行摊销？

旧有的三阶段模型（ASU 2025-06 之前）

几十年来，ASC 350-40 一直采用基于阶段的框架。根据目前对大多数申报者仍然有效的旧版指南（有效期至 2027 年），软件开发分为三个离散阶段。

第 1 阶段：项目初步阶段 (Preliminary Project Stage)

这是探索阶段——定义需求、评估技术、观看供应商演示，并决定是构建、购买还是放弃。此阶段的所有成本均在发生时计入费用，类似于研发费用。理由是：在管理层做出承诺之前，你还没有形成一个可能的资产。

此阶段的活动包括：

• 概念制定和设计方案选择
• 供应商演示和技术评估
• 成本效益分析和可行性研究
• 最终确定方法或供应商

第 2 阶段：应用开发阶段 (Application Development Stage)

当管理层授权项目、承诺资金且完成项目的可能性较高时，资本化开始。此阶段涵盖实际构建过程——编码、测试、配置、集成和安装。

此阶段通常可以资本化的成本包括：

• 开发人员、QA 工程师和项目经理的工资和福利（仅限直接归属于编码、测试和配置软件的时间）
• 开发工作的外部咨询费
• 用于构建应用程序的软件许可证和工具
• 开发中消耗的材料和服务的直接成本
• 利息成本（在极少数情况下）

当软件基本完成并达到预定用途时，资本化停止——通常是在测试完成且系统部署到生产环境时，即使是逐步推广也是如此。

第 3 阶段：实施后阶段 (Post-Implementation Stage)

上线后，持续的成本转回费用处理。培训、维护、漏洞修复和日常支持均计入费用。例外情况：增加新功能（而不仅仅是修复或维护现有功能）的增强功能可以按照第 2 阶段的相同标准进行资本化。

2025 年重大更新：ASU 2025-06

2025 年 9 月 18 日，FASB 发布了 ASU 2025-06，对 ASC 350-40 进行了显著的现代化改造。该更新对于 2027 年 12 月 15 日以后开始的年度期间是强制性的，并允许提前采用。

这一变化是结构性的：三阶段模型已不复存在。FASB 明确删除了所有关于项目阶段的引用，因为旧有的框架不适应现代敏捷和迭代开发实践，在这些实践中，需求是演进的，并且“阶段”往往重叠或并行运行。

基于原则的新阈值

根据修订后的准则，只有在满足以下两个条件时，才能将软件成本资本化：

1. 管理层授权：管理层已授权并承诺为该项目提供资金。
2. 完成可能性阈值 (Probable-to-complete threshold)：项目很有可能完成，且软件将发挥其预定功能。

第二个测试起到了实质性的作用。FASB 引入了一个名为重大开发不确定性 (significant development uncertainty) 的概念来评估完成的可能性。你必须评估：

• 软件是否包含尚未通过编码或测试验证的新颖或未经证实的特性
• 性能要求是否仍未确定，或是否面临重大修订

如果存在重大不确定性，资本化必须推迟到不确定性消除为止。FASB 已经示意，它预计新规则将导致更多的软件成本被费用化，特别是在需求不断迭代的 SaaS 公司中。

这在实践中意味着什么

对于一家正在构建全新事物的初创公司——例如 AI 代理平台或新型自动化引擎——新规则可能会促使更多支出在早期进入运营费用。对于增强成熟且定义明确系统的成熟公司而言，实际影响会较小。无论哪种情况，从机械式的阶段检查转向基于判断的阈值，都意味着公司需要对管理决策、技术可行性和项目状态提供更清晰的文件记录。

你可以和不可以资本化的项目：实用清单

无论你是采用传统的阶段模型还是新的基于原则的测试，资本化支出与费用化支出之间的界限在精神上是相似的。以下是一个实用的清单。

通常可资本化的项目

• 构建阶段开发人员、设计师和 QA 的直接人工成本
• 为这些员工分摊的工资税和福利
• 用于开发工作的外部咨询和承包商费用
• 在开发中直接消耗的软件、工具和云基础设施成本
• 发布后开发新功能的成本（实质性扩展功能的增强）
• 开发转换软件的成本（将旧数据迁移到新系统的软件），而非数据转换活动本身

通常费用化的项目

• 初步研究、供应商选择和可行性分析
• 针对新系统对员工进行的培训
• 数据清洗、对账和记录迁移
• 日常维护、Bug 修复和次要重构
• 在重大开发不确定性期间发生的软件成本
• 与开发没有直接关系的通用行政管理开销
• 营销、支持和发布后的客户成功活动

工时追踪难题

最大的实际挑战是分配工程时间。一名每周工作 40 小时的资深工程师不太可能 100% 都在做可资本化的工作——他们还要调试生产环境、指导同事、参加站会以及审查旧系统的拉取请求（PR）。如果没有可辩护的工时追踪方法（按项目标记的工程工单、工时追踪软件或正式的分配调查），资本化估算将无法通过审计审查。

对财务报表的影响

对同一笔资金进行资本化与费用化处理，会产生截然不同的财务报表。

对损益表的影响

资本化成本不会在支出当期计入损益表。相反，它会被摊销——对于内部使用软件，通常在三到五年内按直线法摊销。因此，第一年 100 万美元的资本化工程支出可能每年仅产生 20 万至 33.3 万美元的摊销费用，从而使第一年的营业收入显著提高。

这就是为什么 EBITDA 会因资本化而得到提升。根据定义，摊销被排除在 EBITDA 之外——因此，将更多开发成本从运营费用（降低 EBITDA）转移到摊销（不影响 EBITDA），会提高该指标。审查 SaaS 指标的投资者通常会查看“资本化研发前的 EBITDA”或使用现金研发支出的“40 原则”计算，以洞察这种动态。

对资产负债表的影响

资本化软件表现为长期无形资产，通常标记为“资本化软件开发成本”或类似名称。这会：

• 增加总资产和权益
• 仅在收益增长快于资产基数时提高资产回报率（ROA）
• 创建一项在项目放弃或其价值下降时必须进行减值测试的资产

如果项目在开发中期被放弃，之前资本化的成本必须被冲销——这会产生突然的、通常是重大的损失。这也是新发布的 ASU 2025-06 如此强调“完成的可能性（probable-to-complete）”阈值的原因之一。

对现金流量表的影响

资本化开发成本通常被归类为投资活动（而非经营活动），这使得经营性现金流看起来更强劲。成熟的投资者在比较公司时会对此进行调整，但标题数据（headline number）仍然会从中受益。

让公司陷入麻烦的常见错误

审计师和收购方经常看到同样的错误。

预授权成本资本化

典型的错误是在管理层正式批准项目之前，就将投入的工程时间资本化。如果没有记录在案的授权和资金承诺，这些成本应该被费用化。确保你有会议纪要、董事会批准或书面签署文件，以确定管理层做出承诺的时间。

缺乏项目级文档

如果监管机构或审计师要求“向我展示你资本化的项目”，而你只能指向总体的工程支出，那么你将会失败。你需要逐个项目的记录：范围、授权日期、预算、状态和收取的工时。

将所有工程时间视为可资本化

资深工程师需要修复 Bug、审查代码、参加会议并处理突发事件。这些都不是可资本化的。那些简单地将工程团队的工资乘以某个百分比的公司，很少能在审计中幸存。

上线后继续资本化

软件达到预定用途的那一刻起，资本化即告停止。此后的错误修复、性能调优和细微改进均属于运营支出。具有独立范围的新功能可以开启新的资本化阶段，但常规的上线后工作则不行。

遗漏减值测试

资本化软件是一项资产，而资产在价值下跌时必须进行减值。如果你封存了某个产品、停用了某项功能或从根本上重写了系统，则必须重新评估并可能核销之前的余额。

如何建立一套合理的流程

如果你决定资本化适合你的公司，那么流程与政策同样重要。

1. 制定软件资本化政策。 定义哪些项目符合条件、授权流程、预计使用寿命以及如何分配时间。获取首席财务官 (CFO) 或审计委员会的批准。

2. 在项目层面跟踪工程时间。 这是基础输入。无论你使用 Jira 标签、项目跟踪器中的自定义标签，还是正式的工时表，你都需要能够证明“工程师 X 在项目 Z 的可资本化工作上花费了 Y% 的时间”。

3. 记录管理层审批。 每个可资本化项目都需要授权证据——带有日期的书面批准、董事会会议纪要或由领导层签署的项目章程。

4. 定期重新评估重大不确定性。 根据新规定，你需要监控功能是否仍然新颖或未经证实，以及需求是否趋于稳定。与工程领导层进行季度审查是合理的做法。

5. 为每个项目建立摊销表。 每个资本化项目在准备好使用时开始摊销，你需要跟踪该资产的成本基础、累计摊销和剩余寿命。

6. 项目发生变化时进行减值测试。 每当你放弃、实质性重写或停用资本化工作时，请进行减值分析并根据需要入账资产减记。

为什么这对记账很重要

软件资本化是那种从第一天起就坚持记账纪律，并在多年后获得回报的领域之一。B 轮融资期间的投资者会调取你的试算平衡表；出售过程中的收购方会将交易追溯至日记账分录；美国国税局 (IRS) 可能会将你的 GAAP 处理方式与 Section 174 研发税务处理（其有自己的规则）进行比较。如果你的账目没有将资本化项目与运营支出分开，无法将工程时间费用与特定项目关联，或者没有维护清晰的摊销表，那么每一次审计和尽职调查周期都会变得痛苦不堪。

解决方法在概念上很简单：保持清晰的账户结构，在项目层面跟踪时间，并记录每笔资本化分录背后的决策。从一开始就这样做可以避免日后昂贵的清理工作。

保持你的软件会计处于随时待审状态

无论你是在为第一个内部平台进行资本化，还是在为几十个项目运行摊销表，清晰的财务记录都是基础。Beancount.io 提供纯文本会计服务，为你提供透明且受版本控制的账目——每笔分录都可追溯，每个账户都可审计，每份报告都可重现。对于跟踪跨多个项目的资本化开发的软件公司来说，拥有像代码一样的账目是一项巨大的优势。免费开始使用，看看为什么开发人员和财务专业人士正在转向纯文本会计。