我们目前处于 FASB 350-40 所定义的开发阶段，且该软件属于内部使用性质。在 SOP 98-1 与 FASB 350-40 之外，我希望能获得更具体的建议，以明确哪些资源应予以资本化，或哪些职能所花费的时间应计入资本。我理解编码人员及项目负责人通常应资本化，代码测试同样如此。困惑主要源于 Scrum Master——他们 100% 的时间用于管理负责软件开发的稳定团队。

有建议认为，Scrum Master 的职能属于行政管理性质，不应资本化；但另一些文章及多数敏捷实践站点则主张 Scrum Master 应资本化。请问是否有更详细的文档，能够说明在敏捷环境中哪些职能、何时应资本化？此外，若存在审计师的相关裁定，亦将有助于厘清问题。需要说明的是，本问题仅针对美国会计准则（U.S. GAAP）适用场景。

资本化判断的核心分歧

FASB 350-40 要求，内部使用软件在开发阶段的直接与间接成本可资本化，但一般行政管理成本、培训成本及维护成本不得资本化。问题在于，Scrum Master 的日常管理活动是否属于“直接服务于软件开发”的必要职能，还是更接近一般行政管理。

支持资本化的观点认为，Scrum Master 负责消除障碍、协调冲刺、保障团队交付，其工作直接支撑开发流程，类似于项目管理的延伸。反对观点则强调，Scrum Master 并不直接编写代码或测试，其核心是团队流程与人员管理，更接近行政监督，因此应费用化。

实务中的参考因素

  • 时间记录细化：若 Scrum Master 同时参与开发任务（如编写用户故事、参与设计评审），则需按实际工时拆分，仅资本化与开发直接相关的部分。
  • 职能实质重于形式：审计师通常关注该角色是否对软件功能产生直接影响，而非仅看职位名称。
  • 行业惯例与审计立场：部分大型会计师事务所曾发布非公开指引，倾向于将纯流程管理角色（如 Scrum Master）视为间接成本，但若其参与技术决策，则可部分资本化。

寻求更权威的指引

目前，FASB 未针对敏捷开发发布专门解释。可参考的补充材料包括：AICPA 的《内部使用软件审计指引》（若存在更新）、各会计师事务所的行业立场文件，以及 FASB 员工问答（Q&A）。建议与外部审计团队提前沟通，并准备详细的工时记录与职责说明，以支持资本化判断。

“资本化与否，最终取决于该角色是否直接参与软件开发的创建或改进，而非其管理头衔。”——某四大会计师事务所技术会计合伙人（匿名引用）

综上，Scrum Master 的资本化问题并无统一答案，需结合具体职责、时间分配及审计判断。建议企业建立清晰的工时分类体系，并保留支持性文档，以应对潜在审查。