软件大写：云和敏捷时代的软件开发成本核算IT 创新正在大显身手。对于大多数行业，德勤预计到 2022 年，对创新和业务增长的投资将恢复到疫情前的水平。1似乎是为了强调这种情绪，Gartner 最近预计 2021 年全球 IT 支出将增长 9%。2在此过程中，许多技术公司正在向敏捷转型开发和云交付模型。两者都有优势这使组织能够更有效地运作。
同时时间，但是，考虑软件开发成本可以在敏捷或云环境中更加棘手，增加了财务报表错误或未能资本化足够成本的风险（这对报告的净收入产生直接影响）。
云和敏捷之间挑战的细微差别是不同的。以下是一些关键的考虑：敏捷开发技术要了解与敏捷开发相关的问题，请考虑软件资本化的会计标准是为组织过去开发软件的方式编写的。较早的所谓瀑布式开发方法是线性的。他们对各个阶段（从前期计划到发布和持续维护）进行了清晰的划分，其中内部会计政策和系统可以很容易地反映。然后公司转向更敏捷的软件开发方法。
敏捷开发团队是按产品和任务组织的，而不是按整个项目组织的。此外，各队他们自己可能是高度流动的，人们通常只停留很长时间因为他们的技能是必需的。这些和其他流程创新帮助软件开发人员以更快、更灵活的方式生产功能。但同样的流程让敏捷开发团队更高效还可能使确定资本化成本变得更加困难。更具体地说，由于敏捷工作是流动的，因此很难将开发与规划和维护区分开来，因为敏捷团队通常会很快经历所有三个阶段冲刺。此外，很难确定包含符合资本化条件的努力的冲刺。如果整个产品团队都致力于应用程序开发，这会有所帮助。然而，如果产品团队或Scrum是多学科的——这在敏捷世界中并不少见——会计团队将不得不了解每个团队成员的习惯做，然后相应地分配成本（例如，通过在特定时间范围内将团队成本的一定百分比资本化）。
然后是故事遗弃。将成本资本化的标准之一是管理层已批准项目并且资金已用于完成开发。但如果该组织有在将它们投入生产之前放弃冲刺或故事的历史，那么就会质疑这些成本是否真的用于开发，因此是否有资格被资本化。组织在确定相关成本时也可能遇到障碍确定的增强功能。当敏捷团队开发功能时投入生产时，他们可能已经或可能没有创建组织应该开始摊销的新资产。这取决于团队是否打算在随后的 sprint 中继续他们的工作。如果新资产真的是完整的，这意味着其他成本可能不得不放弃或减损，而且并不总是清楚哪些成本得到了什么样的处理。
所有这些都使得在敏捷环境中正确识别和资本化成本变得困难。云交付模型向云交付模式的转变意味着公司正在开发提供服务的软件，而不是要销售或销售的软件。作为产品出售（如作为本地解决方案出售的传统软件许可证）。区别很重要，因为软件大写两者的要求不同。对于组织旨在销售或营销的软件，大多数（如果不是全部）开发成本在发生时计入费用。对于软件，组织将作为服务提供，另一方面，大部分开发成本可能必须资本化。尽管这些指导方针看起来很简单，但从本地交付到云交付的时间可能并不总是很明确。当组织通过混合云和本地基础设施交付软件时，会计变得特别复杂。
这是因为实体需要确定专门用于云环境的开发活动，这可能需要与活动不同的会计处理增强本地技术。最重要的是，会计团队可能缺乏对正确识别和说明所需的一些重要信息的可见性开发成本。其中之一是当功能不存在时更长时间可用于本地部署（新功能仅在云中可用时可能会出现这种情况）。其他哪些规划、应用程序开发和维护成本是云功能独有的，哪些成本与本地功能相关。
