橡果文库

【IFRS风向标】新型无形资产案例之初探

9.国外准则
摘要

安永解读IASB针对IAS 38启动的研究项目，选取云计算与敏捷软件开发作为测试案例。文章剖析了现行准则在确认标准上的局限，提出基于知识产权许可模型的会计处理建议及计量单元优化方案，旨在提升无形资产披露的经济实质反映能力。

安永《IFRS风向标》介绍国际财务报告会计准则（IFRS会计准则）最新进展，包括国际会计准则理事会（IASB）准则制定项目状态更新、IASB讨论重点、拟议中的准则或修订的潜在影响等，助您掌握IFRS会计准则的未来风向。

本期主题：新型无形资产案例之初探

项目背景

2025年5月，IASB启动了《国际会计准则第38号——无形资产》（IAS 38）的研究项目并确定了两个工作流：1）了解报表使用者对已确认和未确认的无形资产的信息需求；2）检验无形资产的定义和确认标准是否需要更新。为了推进后者，IASB决定选取与新型无形资产及其新型使用方式相关的应用问题作为测试案例，以识别IAS 38中可改进的原则，并基于《财务报告概念框架》中的更新概念为起点制定可能的解决方案。

工作人员评估比较云计算安排、敏捷软件开发、数据资源及人工智能等潜在案例，综合考量利益相关者的普遍关切度、财务报告影响的重要性及底层问题和潜在解决方案对更广泛的无形资产的相关度，选择了云计算和敏捷软件开发作为测试案例。数据资源和人工智能的相关问题虽然重要，但其所涉及的应用问题与事实情况较为成熟的云计算安排和敏捷开发案例相类似。

下文对云计算安排及敏捷软件开发测试案例的分析，均来源于工作人员的初步探索性研究，旨在为IASB公开会议讨论提供分析基础，并不代表IASB的观点。编制的目的是就工作人员的分析、潜在改进方案及下一步工作征求IASB成员的意见和问题，并不要求IASB在会议上作出任何决策。

云计算安排测试案例：

一、应用问题

在云计算安排中，云计算的供应商通过云端向众多企业同时授予软件访问权，企业并不控制底层软件代码，亦不拥有排他性复制权。现行IAS 38制定时，数字访问知识产权尚未成为常态，未嵌入后续《财务报告概念框架》及《国际财务报告准则第15号——客户合同收入》（IFRS 15）所发展的控制权概念。解释委员会于2019年及2021年虽然提供了指引，但利益相关方反馈现行准则要求配置与定制成本在发生时即被费用化，这造成了盈利指标的剧烈波动，无法反映交易的经济实质。

二、建议的模型

为了解决上述问题，工作人员基于《财务报告概念框架》和IFRS 15提出适用知识产权许可合同的模型，该模型核心包含三个步骤：

01识别底层项目

工作人员认为，知识产权许可合同中的底层项目应是知识产权本身，而非其某一副本。知识产权的功能和价值蕴含于底层智力成果之中（如软件代码、产品设计），访问模式（如实体副本、下载或云端访问）并不改变知识产权的性质或者企业从其中获益的能力。对于包含多项交付物（如软件访问、基础设施使用、数据存储、更新维护）的合同，可借鉴IFRS 15中关于识别单独履约义务的原则，从客户视角判断各项供应商的交付物是否构成独立的底层项目。

02识别企业所获权利

在知识产权许可合同中，各方可能对同一底层项目享有不同权利：

使用权 访问权 接收服务的权利
由供应商保留，包括决定软件如何部署、向谁授权、在何处使用等 企业通过合同获得，可在约定范围内直接使用软件而获益，并可通过用户名/密码等方式防止他人使用该权利，但无权决定软件的底层使用方式 若供应商利用其软件为企业执行特定任务（如外包薪资处理），企业仅获得服务产出，不直接接触软件本身

在典型云计算安排中，企业获得的是访问权，而非使用权或接收服务的权利。尽管云计算供应商可能同时向众多企业授予访问权，但每项访问权均源于独立合同，企业仅控制其自身的权利。

03判断是否构成资产

访问权符合《财务报告概念框架》对资产的定义，属于无形资产。工作人员根据权利交付的时间模式区分了两类情形：传统软件许可属于时点获得的访问权，确认为无形资产并按使用寿命摊销。云计算安排属于期间获得的访问权，在整个合同期内持续获得并即时消耗一系列访问权，每一时刻的权利均符合资产定义，但其获得即消耗，也无单独使用寿命。

三、会计处理建议

情况 会计处理
云计算安排的访问权 云计算安排访问权符合无形资产定义，亦符合《国际财务报告准则第18号——财务报表的列示和披露》（IFRS 18）下的流动资产特征，工作人员建议将相关支出在发生时确认为经营费用，而非通过确认再立即摊销的循环处理。此种处理更能如实反映经济实质，并为使用者提供更具成本效益的信息。
预付款 若企业在获得访问权之前预先支付订阅费，此时企业拥有的并非访问权本身，而是未来获得访问权的权利。该权利属于营运资本中的预付款，随着企业访问权的实际获得与消耗，相应转为经营费用。
配置与定制成本 若配置与定制代码与软件及基础设施高度关联，企业无法单独获益，且其目标是获得组合产出，则这些权利应与软件访问权合并为单一会计单元，在合同期内随着各项权利的获得与消耗逐步确认为经营费用，而非在发生时一次性费用化。
多供应商安排 当企业与多个供应商分别签订合同以获取软件访问权、配置定制服务或基础设施时，工作人员建议这些权利高度关联且必须合并才能达到预定可使用状态，且目的是获取组合产出，则即使权利来源于不同合同，也应合并为单一会计单元进行会计处理。该计量单元包含的权利整体在合同期内被持续获得并即时消耗，相关成本统一计入经营费用。

敏捷软件开发测试案例

一、应用问题

过去十余年来敏捷软件开发逐步成为软件行业的主流开发模式，与传统瀑布式开发不同，敏捷软件开发以迭代周期、加速交付和高度适应性为特征。敏捷软件开发在初期通常较为模糊，随开发进程逐步细化，技术可行性往往在开发后期才得以确立，每次迭代均产出具有一定功能的代码片段，研究活动与开发活动交替出现，而非按顺序发生，这导致了难以确定计量单元、难以区分研究阶段与开发阶段、也难以判断IAS 38第57段开发产生的无形资产的六项确认标准。实务中，部分企业选择全部费用化，也有部分企业尽可能资本化，降低了财务报表的可比性。

二、计量单元的确定

工作人员认为，尽管敏捷软件开发以迭代代码为交付物，但计量单元不应局限于单次迭代的产出，而应基于预期产生未来经济利益的功能聚合。通过电子游戏开发的相关示例，工作人员提出了确定计量单元的三种观点，初步倾向于观点3：

观点内容 特点
观点1 将管理层批准的一个项目所包含的全部功能作为一个计量单元。 操作较简单，与项目审批和资金配置方式一致；可能因将技术不确定性较低的功能与技术不确定性较高的功能捆绑在一起，导致单元过于宽泛，从而延迟确认并提供相关性较低的信息。
观点2 将每项独立功能作为独立计量单元。 允许在不确定性逐项消解时分别进行确认评估；可能过度割裂，忽视了多项功能需协同才能产生经济利益的实质。
观点3 将计量单元与管理层的经济意图挂钩，界定为管理层预期从中产生未来经济利益的最小功能聚合。 避免了项目整体的过度聚合，又防止了单一功能的过度拆分；更能如实反映管理层的经济意图。

三、研究阶段与开发阶段的区分

针对研究阶段与开发阶段的区分，工作人员分析了三种可能方案，初步倾向于方案C：

方案内容 特点
方案A 不再以时间性阶段为标准，而是要求识别每项支出的活动属于研究还是开发性质，仅开发支出在满足六项确认标准时资本化。即使在开发活动已经启动后，迭代过程中又出现研究性质的活动，也需要将相关支出识别出来并费用化。 不以项目进度作为确认门槛，保留了“研究费用化、开发可资本化”的现有结果；持续识别和归集每项活动成本在实际操作中可能非常复杂且成本高；若企业仍无法可靠区分研究与开发活动，则该方案难以落地。
方案B 维持现行研究与开发的时间性阶段划分，但为敏捷软件开发提供何时进入开发阶段的额外指引。将进入开发阶段后的所有支出均视为开发支出，即使实质含研究活动。 接近现有规定，对传统开发方法的企业干扰最小，也减少了持续判断的操作复杂性；可能无法充分回应判断项目何时进入开发阶段存在困难的反馈；可能导致研究性质的支出被资本化。
方案C 彻底取消研究阶段与开发阶段的划分，仅以六项确认标准作为资本化的唯一标准。 贴合敏捷开发中活动迭代交织、不存在清晰可识别阶段的现实；资本化的最终标准是六项确认标准，取消阶段区分未必会导致传统瀑布式开发的会计结果发生根本性变化；取消了研究阶段的明确标识，可能增加过早资本化的风险。

四、六项确认标准

工作人员认为许多应用问题实际上源于计量单元确定不当，从而导致了判断六项确认标准中技术可行性的困难。若明确计量单元，评估资产能否完成在敏捷软件开发情况下未必比传统瀑布式开发更困难。不过，敏捷软件开发的特征反映了较高的不确定性，这可能支持将相关支出费用化。工作人员提出了三种潜在改进方案：

增加应用指标：补充示例性的判断指标（如借鉴美国会计准则的概念）帮助编制者判断何时满足确认门槛；

针对性修订标准：重新表述技术可行性和未来经济利益等具体标准，引入重大技术与商业不确定性、预期功能、项目成熟度等概念；

重组六项标准：将现有六项标准重新归类为核心确认标准（未来经济利益、可靠计量）与用于评估核心标准是否满足的条件，帮助编制者理解各项标准的概念目的及其在整体确认框架中的作用。

下一步行动

云计算与敏捷软件开发两个测试案例的研究表明，IAS 38在定义、确认及计量层面均存在改进的机会。下一步，工作人员将继续与咨询组沟通，检验上述测试案例建议对更广泛无形资产类型的影响，并预计在2027年初提请IASB就相关改进作出决策。

我们将持续关注该项目的发展，敬请期待后续进展。

相关文章