如果你问一位软件工程经理某个项目是何时"启动"的，得到的答案大概是某个冲刺（sprint）编号。但如果你问公司财务总监同样的问题，按照自1998年以来一直规范内部使用软件的会计准则，答案本该来自一套僵化的三阶段核对清单——这套清单假定在需求锁定之前没有人会动手写代码。过去十年里做过软件交付的人都清楚，事情早已不是这样运作的了——而到了2025年9月，FASB终于也承认了这一点。
会计准则更新（ASU）2025-06号《无形资产——商誉及其他——内部使用软件（350-40子专题）：内部使用软件会计处理的针对性改进》彻底废除了旧有的分阶段测试，取而代之的是一个基于职业判断的单一问题：这款软件是否很可能最终完成并实现其预期功能？对于任何自主开发软件的公司而言——尤其是那些旧规则从未真正适配过的敏捷团队——这决定了开发成本何时、以多大比例从利润表转移到资产负债表。
症结所在：为瀑布式开发编写的1998年规则手册
ASU 2025-06所取代的旧准则ASC 350-40（前身为SOP 98-1）诞生于"软件开发"还等同于线性瀑布流程的年代。它把每一个内部使用软件项目都拆分为三个先后相继的阶段：
- 初步项目阶段 —— 概念构思、评估备选方案、供应商选型。这一阶段的所有支出均在发生时计入费用。
- 应用开发阶段 —— 实际编码、配置与测试。这一阶段的成本予以资本化。
- 实施后阶段 —— 培训与维护。再次计入费用。
如果一个团队花三个月写需求文档、拿到审批后才开始动工，这套框架运作良好。但一旦团队开始以两周为周期冲刺、持续发布增量版本，并在每次回顾会上调整范围，这套框架便土崩瓦解。在敏捷环境中，"初步"与"应用开发"并非先后相继的阶段——它们相互交织，有时甚至发生在同一个冲刺周期内。多年来，企业与审计师一直在争论某个两周冲刺到底应归入哪个阶段，而诚实的答案往往是"两者都有一点，我们只能靠猜"。FASB自身的调研也发现，利益相关方一致认为，这是美国通用会计准则（GAAP）中执行起来最令人头疼的部分之一。
解决方案：一项测试，而非三个阶段
ASU 2025-06删除了所有关于旧项目阶段的表述，取而代之设立了单一的**"很可能完成"确认门槛**。根据新准则，公司只有在以下两个条件同时满足时，才能将内部使用软件成本资本化：
- 管理层已批准并承诺为该项目提供资金。 这并非新概念——旧准则中同样存在——但如今它作为仅有的两个门槛条件之一，发挥着比过去埋没在阶段分析中更重要的作用。
- 该项目很可能会完成，且软件将被用于实现其预期功能。 这是真正意义上的新内容，也是职业判断的核心所在。
第二项标准要求评估是否仍存在重大开发不确定性。FASB指出，这种不确定性主要来自两个方面：
- 尚未验证的技术或新颖功能——其可行性尚未通过实际编码与测试得到证明，光有设计文档或需求说明书还不够，必须有可运行的证明。
- 尚未明确或仍在变动中的性能要求——准则将其定义为"实体希望软件实现的功能，例如各项功能或特性"。如果团队仍在实质性地争论产品到底需要做什么，说明这种不确定性尚未化解。
实际操作中，这意味着资本化的时点如今取决于可行性证据，而非日历上的阶段划分。如果一个团队为验证某项技术上颇具新意的功能先花两个冲刺做"探针（spike）"，之后才认真投入构建，那么这两个探针冲刺的成本应计入费用——因为这项功能到底能不能实现的不确定性尚未化解。一旦探针验证可行，且管理层承诺投入预算全面构建，"很可能完成"门槛便告达成，此后的开发成本予以资本化，无论采用何种敏捷仪式都不影响这一判断。
为什么FASB认为资本化整体变化不大——SaaS却是例外
FASB自身预计，对于大多数本地部署或基于许可证的内部使用软件而言，此次修订不会大幅改变资本化结果——企业原本就是在真正开始编码后才进行资本化，新测试得出的结论大体相同，只是不再需要给项目贴阶段标签。
但通过SaaS或云端方式交付的软件情况则完全不同。 FASB明确预计，这类项目的资本化金额将会下降。原因在于：SaaS产品本质上处于持续构建与重构之中，重大的技术与产品不确定性会持续存在于开发周期的很深阶段——有时甚至一直延续到某项功能即将发布之前。在"很可能完成"测试下，这种持续存在的不确定性意味着，许多SaaS开发成本要到构建过程中远比旧阶段模型所暗示的更晚的时点，才能达到资本化门槛。其净效应是：SaaS产品的更多工程人力成本会计入当期研发费用，而不是形成一项需要多年摊销的资产。即便实际代码尚未改动一行，这也会对任何SaaS公司披露的EBITDA与资产规模产生实质性影响。
一个具体案例：两种做法，两种结果
假设一家拥有40名员工的SaaS公司决定为其产品构建一个由AI驱动的预测模块。以下是新旧规则将如何以不同方式处理这同一段为期八个月的开发工作。
在旧的阶段模型下，财务团队会试图划出一条界线：前六周的需求收集与供应商评估属于"初步阶段"（计入费用），启动会之后的一切都属于"应用开发阶段"（予以资本化）——尽管工程团队接下来还花了两个月做探索性的探针（spike），以判断所选的预测方法能否在生产级数据量下达到可接受的准确度。按照旧规则的字面规定，一旦"阶段"发生切换，这些探针冲刺往往也会被一并资本化，因为它们从技术上讲发生在启动会之后。
在ASU 2025-06下，财务团队转而追问：这项功能何时变得"很可能"会按预期完成并投入使用？如果准确度方案在头两个月里仍未得到验证——团队正在测试三种不同的建模方法，且不知道哪一种能够达标——那么整个探索期都应计入费用，无论它在日历上落在哪个"阶段"。只有当团队选定一种已验证可行的方案、且管理层承诺投入预算全面构建时，资本化才会开始，在这个例子中，这个时点可能是第三个月而非第二个月。结果是：资本化资产规模更小，当期研发费用更高——更重要的是，这个数字在审计中真正站得住脚，因为它对应的是一个具体、有据可查的决策节点，而不是事后贴上的阶段标签。
这正是FASB预期在整个SaaS行业中会出现的转变：少一些"我们称之为应用开发，是因为它发生在启动会之后"，多一些"我们可以准确指出技术风险被消除的那个冲刺"。
生效日期与过渡安排
ASU 2025-06适用于所有主体——无论上市公司还是非上市公司——自2027年12月15日之后开始的年度报告期及其中的中期期间起生效。准则一经发布，任何主体均可在任意中期或年度期间提前采用。
各主体可以三种过渡方式之一适用本次修订：仅对生效日之后发生的新软件成本采用未来适用法；对采用年度期初及以后发生的成本采用未来适用法；或对所有列报期间采用追溯调整法。这种灵活性十分重要——如果一家公司在规则生效时正处于某个重大平台重构项目的开发中途，除非其选择追溯调整法，否则无需推翻多年的资本化成本历史记录。
中小型软件公司现在应该做什么
2027年12月听起来似乎还很遥远，但实际的准备工作绝非最后一个季度才需要着手的事，尤其对于那些财务团队精简、没有专职技术会计职能的公司而言更是如此。
从现在起就实时记录"很可能完成"的判断依据，而不是事后追溯。 旧的阶段模型是机械化的——几个月后你仍能根据冲刺日期反推出项目当时处于哪个阶段。而新测试问的是我们是从什么时候起不再存在技术不确定性，这样的判断事后要重构起来困难得多。现在就养成一个轻量级的习惯：当工程负责人与财务部门一致认为某项功能已经通过技术探针验证、并已承诺投入构建时，记录下这个日期。这份记录将成为你的资本化起始日期，也是你的审计支持材料。
在工时记录或项目代码中，把"探索性"工作与"已承诺构建"工作区分开来（如果目前尚未这样做的话）。无论是通过Jira史诗（epic）标记、独立的成本中心代码，还是工时记录工具中的一个标签，只要拥有一条清晰的数据轨迹，能够说明某项功能何时从探针/原型阶段转为已承诺开发阶段，就能让新准则的适用工作远比在审计中凭记忆重构来得轻松。
在选定过渡方式之前，先把两种方案都测算一遍。 如果贵公司此前在旧阶段框架下对SaaS开发成本采取了较为激进的资本化策略，那么追溯调整法可能会导致此前已资本化的资产出现一次性减记，因为这些成本会被重新分类，视同其自始就已计入费用。未来适用法可以避免这种重述，但也意味着在采用后的新项目启动之前，利润表都不会体现新方法的影响。在审计委员会不得不做决定之前，先把两种方案下的数字都算清楚。
尽早与审计师沟通，尤其如果你是一家SaaS公司。 鉴于FASB自身也预计SaaS开发的资本化金额会下降，审计师很可能会比过去审视旧阶段分类时更严格地审视"很可能完成"的判断——正因为这类判断主观性更强。一家在2028年审计中就能拿出一套有据可查、同期记录的判断框架的公司，其沟通过程将远比事后重构要顺畅得多。
干净的账簿让职业判断更容易站得住脚
每一项会计判断——而"很可能完成"正是典型的判断——其可辩护性完全取决于背后的记录是否扎实。如果贵公司的科目表本就按项目区分了研发支出，且账本条目具备版本管理、可供审计，而不是散落在互不相连的电子表格中，那么适用ASU 2025-06这类准则，就只是给现有数据打标签的问题，而不必从Slack聊天记录中拼凑历史。Beancount.io的纯文本会计默认就为你提供这种透明、经git版本管理的账本——每一笔条目都可追溯，每一次变更都可审阅，且不存在供应商锁定。免费开始使用，打造无论面对审计师、收购方，还是FASB的下一次准则更新，都能经得起检验的账簿。