内部使用软件的会计

作为一个财务和会计的家伙，我一般倾向于确定性。如果所有内容都能很好、直观地归类并解释，那就太棒了。但是，这并不总是可能的。特别是随着越来越多的公司从基于项目的软件交付转向更多的基于产品的管理。所有这些改变都是为了改善业务结果。亚博vip9通道换句话说，公司想要、努力并且变得更加敏捷。那么，一个在瀑布环境中资本化成本10年、20年甚至30年的组织应该做什么呢?

这些在组织设计、开发方法、团队资金和运营方面的变化，是那些有抱负的敏捷人员重新评估其组织内部使用软件的会计和相关资本化政策的大好机会。但是，在这一过程中，他们可能会面临一些有趣的会计挑战。例如:

• 在ASC350-40下对内部使用的软件进行会计核算最初是基于瀑布方法的，那么当实现这些新的软件开发过程时会发生什么呢?
• 内部会计在敏捷环境中如何资本化成本方面产生了不确定性。你是怎么做到的?
• 随着团队效率的提高和软件生产速度的加快，跟踪他们的成本变得更加重要。选择什么存在吗?

解决历史的方法

在过去，软件开发的方法——在IT软件项目框架内——由于以下因素可能成为争论的焦点:

• 项目的正式年度资助
• 由于收购、遗留系统未退役等原因，某些项目可能涉及组织内的重复工作。
• 组织转向双峰方法，其中某些项目需要可预测的发展和完成，而其他项目需要不断的探索和速度是至关重要的

历史上固定的和项目驱动的筹资方法通常会导致越来越多的不满，因为整个筹资过程太长了——特别是对于多年的瀑布式项目。通过使用这种遗留资金方法最终解决所需的业务问题可能需要数年时间，而且在竞争激烈、变化迅速的业亚博vip9通道务环境中，这是不可接受的。

这种旧方法的缺陷是，通过竖井或合并和收购建立起来的组织拥有支持相同业务流程或相同业务流程部分的软件应用程序。亚博vip9通道显然，这将导致不必要的技术债务，使IT组织负担过重，以至于不能投资于任何新的工作。

解决方案是什么?以产品和能力为中心的管理。从关注单个项目转移到更高的整体产品优势点，将允许您的业务从单个项目成本转移到更高的分析级别——无论是产品级别，还是整个组织/部门的视图。亚博vip9通道扩大相关成本池和相应流程中涉及的成本池将使您的组织能够将更多的运营成本资本化——只要它们属于相关会计指南中适当的资本化类别。

FASB会计准则汇编(ASC) 350-40中关于内部使用软件的会计指导，内部使用软件的会计，概述了如何基于实现两个关键目标来利用或支出内部使用软件。第一个目标包括确保初步项目阶段已经完成，第二个是在应用程序开发阶段内完成的工作类型有资格作为资本化活动。

最初的会计指导源于1998年的AICPA头寸声明(SOP) 98-1占电脑软件的成本或获得内部使用的成本．这个SOP是在敏捷宣言写出来的三年前发布的，所以您可以想象它在很大程度上依赖于当时流行的软件开发方法——瀑布。并且，会计标准遵循了如下图所示的瀑布式活动布局的严密结构。

虽然在ASC指南中使用的语言可能存在灰色地带，但在一个关键需求上没有歧义。这一要求是，初步项目阶段必须完成并适当地记录下来。最终，这一限制项意味着，在此阶段完成之前，任何费用都不能资本化，即使您真的在创建可用的软件代码。ASC350-40-25-12规定-我解释一下-初步项目阶段必须完成，管理层打算为一个软件项目提供资金，该软件项目将在资本化开始之前完成并用于其预期目的。

因此，会计师希望确保完成适当的勤格水平。他们想要编写良好的文档，那些参与者已经对手头的业务问题进行了评估的每个替代解决方案。亚博vip9通道完成此阶段的一个关键步骤将获得来自管理的管理资金和授权，该项目具有适当的授权级别。除非已获得，除非您将继续在初步项目阶段继续。因此，完成这些步骤对您的内部会计部门同事和外部审计师来说非常重要，并且应该在成本的资本化之前妥善记录。

现在，虽然这是资本化的一个关键需求，但另一个需求是理解进入应用程序开发阶段后可以资本化的成本类型。让我们考虑以下问题。基于ASC 350-40-55-4的详细指导，没有要求瀑布方法中的每个步骤都发生在特定的阶段。相反，ASC指出，“…内部使用软件的开发不能按照前面列出的顺序进行。”这是成本的性质，不完全是发生的时间这一点很重要。”这种区别是允许我们将适当的成本资本化的关键，即使在敏捷环境中也是如此。因此，项目是在瀑布方法还是敏捷方法下完成并不重要，重要的是所进行的具体活动。

利用成本

好的，让我们假设初步过程阶段已经完成，我们已经获得了适当的授权，并得到了我们需要的资金。现在,软件开发资本化成本就可以开始了。

大多数组织使用考勤卡是因为他们一直在使用瀑布方法，这是没问题的。您仍然可以在敏捷格式中使用它们。在继续使用考勤卡或其他成本追踪方法之前，需要考虑以下几点:

• 使用现有时间跟踪系统将减少需要额外的培训，鉴于当前员工已经熟悉现有流程
• 如果时间跟踪以准确性为重点，那么在sprint期间故事的完成可能会受到影响
• 或者，如果完成故事是员工关注的主要领域，员工可能忘记了在一周中真正完成了什么，那么可能会出现缺乏准确性的情况

对于所有这些问题，您将需要评估维护现有时间跟踪系统的利弊。作为评估的一部分，您应该考虑其他几种跟踪资本化成本的替代方法。第二种方法是，您可以使用故事点，并为sprint期间完成的每个点分配美元价值。注意，使用这种方法需要考虑以下几点:

• 与计时相比，团队的努力和您可以利用的金额之间可能有更高的相关性
• 故事点已经在Scrum中使用了，所以它是追踪活动和成本的自然方式
• 故事点对于每个开发团队来说都是主观的，所以要在所有开发团队之间保持一致可能相当具有挑战性
• 故事点的使用可能无法满足审计人员的需求，因为它们是成本估算，所以从一开始就让他们参与进来是至关重要的

如果您的开发团队在使用故事点方面存在很大的差异——这并不罕见或不常见——第三种方式，也可能是最适合敏捷的方式，是将成本资本化，这是基于与每个开发团队在特定时间内完成的所有其他工作相关的新功能特性。这种方法依赖于评估每个团队完成的工作，包括新功能特性——与bug修复和增强相比——这是“可资本化的”——这是要付出代价的。因为团队中的故事点值应该是一致的，并且准确地反映在一个特定的发布或者甚至是一个Epic中完成的工作量，这应该为您的内部会计同事和外部审计人员提供一个合理的方法。

当然，在适当的严格条件下，这些方法都可以工作。这将取决于你的公司对什么感觉舒服，以及对你的会计团队的支持。最终，最重要的是将您的开发团队转变为具有凝聚力的、持久的团队，并期望成为高性能的团队。

根据我们的经验，能够做到这一点的组织平均能够将70%的成本资本化。有些团队变得非常敏捷，我们看到他们能够将90%的成本资本化。可能是一个极端的例子，但它证明了高效的开发团队可以对公司的运营结果产生直接影响。

摊销

一旦成本资本化，它们需要在软件的使用寿命内摊销——通常是三到五年。

在“瀑布”中，一旦项目完成，摊销就开始了。这在敏捷环境中并不完全是这样。一些实践敏捷的公司开始随着每个sprint的发布每月摊销成本。他们可以这样做，因为在每个sprint中，他们都生产出了可工作的、经过测试的软件。因此，如果一个软件解决方案被认为有48个月的有效寿命，那么它的第一个版本将摊销48个月。这是第二次月度发行，在47个月里摊销。这是第3个月发布的版本，超过了46个月——依此类推。

根据高德纳公司2015年5月21日的《运营成本vs资本支出:cio应该与cfo合作，一个好的经验法则是，一个公司的IT折旧和摊销费用的总和不应该超过公司总IT预算的20%。您可以期望看到一个持续的平衡行为，IT和财务团队成员必须一起工作，以确保保持适当的投资水平。

政策和程序

创建适当的会计政策和程序对于你的资本化工作是必要的。重要的是，这些策略和过程必须是简单的和可伸缩的，这样它们才能与您的组织一起成长。如果您能够使用简单的咒语，而不创建带有相关程序的过于繁琐的策略，那么您将获得最大的好处。否则，您可能会影响您试图在敏捷环境中实现的一些好处。

如果您的会计政策变得过于复杂或繁重，您可能因资本化的任何成本节省而且肯定会损失对生产力的不利影响，助理士气的下降，甚至联合转身。

当你在整个敏捷等式的会计元素中冒险时，我希望你能取得成功。