（一）多口径归集概述

1.应用场景

多口径归集包括以下应用场景：

不同费用项目，有不同的归集口径。例如水电费，可能按公司归集；办公费，可能按部门归集；工资，可能按员工归集。如图4-4所示。

图4-4 费用的多口径归集

同一费用项目，在不同时期可能有不同的归集口径。例如业务招待费，一个时期可能按部门归集，另一个时期可能改为按员工或按客户归集。

同一费用项目，在同一时期不同场景，可能有不同的归集口径。例如运输费用，在运输一种产品时，可能按"部门+产品"口径归集；在运输多种产品时，只能按部门归集。

2.数据来源

费用归集包括以下数据来源：

（1）账务系统。例如，通过费用类科目的辅助核算，如客户、产品、作业、部门、员工、项目等辅助核算归集费用。

（2）业务系统。多维组合成本主要的数据来源不是账务系统，而是业务系统。例如材料费来源于存货核算模块，人工费来源于薪资管理模块，折旧费来源于资产管理模块，业务招待费来源于费用报销模块等。

3.取数方式

多维组合成本无论是基于独立系统开发还是现有系统实现，取数均有三种方式。

（1）录，即由用户将费用数据手工录入。

（2）导，即用户将费用数据从其他系统导出到Excel表或手工填写Excel表，再通过预置的Excel表模板导入。

（3）取，即开发与现有账务系统或业务系统的接口，通过接口自动取费用数据。

（二）多口径归集的场景

1.归集与分摊的关系

成本计算过程就是费用的归集与分摊过程，传统成本计算是如此，作业成本计算是如此，多维组合成本计算也是如此。作业成本法区分"追溯"、"动因分配"和"分摊"三种方式，其实"追溯"就是归集，"动因分配"就是成本动因明确的分摊，"分摊"就是成本动因不明确的强制分摊，所以它的计算过程仍然是归集与分摊。

成本计算的准确性，取决于归集与分摊，归集影响水源，分摊影响水流，具体如下：

（1）费用归集的口径大小。例如，业务招待费以往按部门归集，现在按订单归集。归集口径变小了，数据就更准确了。如果费用归集口径足够小，直接归集到成本对象，那就不用分摊了，此时的成本数据就是最准确的了。

（2）费用分摊的准确性高低。例如，以往各部门没有安装电表，电费按产量分摊；现在各部门安装了电表，电费按用电量分摊。现在的分摊标准更合理，因此数据更准确。

可能有人会说，将全部费用都直接归集到成本对象，那不是最好吗？如果能做到，那当然是最好，但这是无法做到的。原因包括：

（1）成本对象太多。例如，一家企业的客户、产品、作业、部门分别有10个。此时，多维组合的成本对象理论上将有1万个。

（2）信息载体太多。费用归集到成本对象需要有相应的信息载体。如果以细化的成本中心为载体，发生的费用直接归集到可关联多个维度的成本中心，则这样的成本中心理论上需要1万个。信息载体之多，是任何企业都无法承受之重。

（3）颗粒度太粗。为了解决信息载体太多的问题，有人认为可以简化处理，例如将客户、产品、作业、部门分别合并为3个，此时成本中心理论上只需要81个，就比较可行了。但这样做的本质是为了关联多维度而牺牲每个维度的颗粒度。按照这种思路，如果客户、产品、作业、部门均合并成了一个，那就最好了，成本中心就1个，归集到成本中心的费用天生就是多维的。不过颗粒度之粗，是任何企业管理都无法承受之痛。

顺便指出，成本对象用客户类型或产品类型或作业类型等，取代客户或产品或作业，类似于颗粒度变粗。例如有1000位客户，分8种客户类型，如果成本对象是客户类型而不是客户，则只知每类客户而不知每个客户的成本，或只能千人一面地平摊。从粗到细的"分"难，从细到粗的"合"易，如果成本对象是客户，则可知具体客户成本，且只需简单汇总就可知客户类型成本。

（4）权限控制和职责分工问题。例如，某车间工人领用材料，业务发生时只知道是用于哪个产品哪项作业，并不知道相应的客户，不仅不可能知道，而且不应该知道，因此无法在业务发生环节直接归集，只能交由财务月底分摊。

可以看到，希望将全部费用直接归集到成本对象而避开分摊，是在回避现实，而不是正视现实，它只能转移问题，不能解决问题。对费用归集口径应取的态度是：

（1）要求而不强求。归集口径能细化则细化，不可细化则不细化。细化归集口径，是且仅是成本计算的有益补充，不是且不可能是必须前提。

（2）依靠而不依赖。如果费用能有一个共同的归集口径，那么分摊将有一个共同的起点；如果费用能有一个细化的归集口径，那么分摊将有一个较高的起点。但不能指望所有费用均能有统一的细化的归集口径。

业务口径与成本对象的关系，如图4-5所示。

图4-5 归集与分摊的关系

（1）归集与分摊并没有明确的概念区别。例如一个人吃饭，费用是向一个人归集；两个人吃饭，费用是向两个人分摊，也可以说，费用是向两个人分别归集。

（2）归集与分摊并没有清晰的应用界限。归集或分摊，均是记录的费用事实指向隐藏的成本真相的方式，均是业务口径通往成本对象的手段。记录的事实不变，隐藏的真相不变，方式可变；业务口径不变，成本对象不变，手段可变。在成本计算过程中，归集与分摊经常是交叉使用的方式和手段。

2.单口径的归集

归集到某口径的费用并不是该维度的成本。

例如，某费用归集到产品A为150元，归集到作业1为200元，如表4-1所示。不能认为产品成本是150元，作业成本是200元。

表4-1 费用的归集

归集到产品A的费用应向作业分摊，如图4-6所示。

图4-6归集到产品的费用向作业分摊

归集到作业1的费用应向产品分摊，如图4-7所示。

图4-7 归集到作业的费用向产品分摊

分摊完成后，向不同方向汇总，才是各个维度的成本。例如，产品和作业维度的成本均为350元，如表4-2所示。

表4-2 分摊结果

从以上计算结果可以看到以下几点：

（1）归集到产品A的150元，是专属于产品A的费用，不向其他产品分摊；归集到作业1的200元，是专属于作业1的费用，不向其他作业分摊。

（2）归集到产品A的150元，是作业1和作业2的共耗费用，需向作业1和作业2分摊；归集到作业1的200元，是产品A和产品B的共耗费用，需向产品A和产品B分摊。

（3）产品A的成本，是归集的150元，与分摊共耗费用而来的120元之和；作业1的成本，是归集的200元，与分摊共耗费用而来的100元之和。

（4）只有将各个口径归集的费用，全部向维度组合进行分摊，计算出维度组合的成本，然后才能由维度组合的成本，向不同方向汇总，得到各个维度的成本。即欲将取之，必先予之，如图4-8所示。

图4-8 费用与成本的先予后取关系

3.多口径的归集

归集到多个口径组合的费用并不是该多维组合的成本。

例如，费用1归集到"客户甲+部门1"为80元，费用2归集到"产品1+作业1"为100元，如图表4-3所示。不能认为客户、部门、"客户+部门"的成本为80元，不能认为产品、作业、"产品+作业"的成本为100元。

表4-3 费用的归集

归集到"客户甲+部门1"的费用应进行分摊，如图4-9所示。

图4-9 费用分摊

归集到"产品1+作业1"的费用应进行分摊，如图4-10所示。

图4-10 费用分摊

分摊完成后，向不同方向汇总，才是各个维度的成本。例如，客户、部门、产品、作业维度的成本，均为180元，如表4-4所示。

表4-4 分摊结果

分摊完成后，向各维度组合方向汇总，才是各维度组合的成本。例如，"客户+部门"维度的组合成本为180元，如图表4-5所示。

表4-5 "客户+部门"的组合成本

例如，"产品+作业"维度组合的成本为180元，如表4-6所示。

表4-6 "作业+产品"的多维成本

从计算结果可以看到以下几点：

（1）归集到"客户甲+部门1"的80元，是专属于"客户甲+部门1"的费用，不向相同维度组合的其他任何成员分摊；归集到"产品1+作业1"的100元，是专属于"产品1+作业1"的费用，不向相同维度组合的其他任何成员分摊。

（2）归集到"客户甲+部门1"的80元，是各产品各作业的共耗费用，需向各产品各作业分摊；归集到"产品1+作业1"的100元，是各部门各客户的共耗费用，需向各部门各客户分摊。

（3）"客户甲+部门1"的成本，是归集的80元，与分摊共耗费用而来的10元之和。"产品1+作业1"的成本，是归集的100元，与分摊共耗费用而来的10元之和。

（4）只有将各个口径组合归集的费用，全部向维度组合进行分摊，计算出维度组合的成本，然后才能由维度组合的成本，向不同方向汇总，得到各个维度及其组合的成本。即欲将取之，必先予之，如图4-11所示。

图4-11 费用与成本的先予后取关系

很多公司开展财务分析项目，基于科目的辅助核算进行多维分析，往往归于失败，原因就在于没有对不同辅助核算归集的费用进行分摊。

看到这里可能有人认为，既然如此，那就丰富科目的辅助核算，通过分摊以反映完整的一致的多维成本信息。这种认识还是错的，这里需要澄清两个容易混淆的认识。

​ 科目的辅助核算与成本的多维组合不应混淆。科目的辅助核算如果足够明细，费用归集口径足够小，则不用进行多维成本计算。而正是因为多维组合的指数级海量数据，使科目的辅助核算不可能足够明细，费用归集口径不可能足够小，因此必须进行多维成本计算。

​ 成本核算精益化与会计核算精益化并不是相辅相成，而是此消彼长的。成本核算越是精益化，会计核算的成本类会计科目越是简化。成本核算精益化的极致，就是所有成本类信息全部到成本管理系统查询，会计核算的成本类会计科目只设一个或少数几个，辅助核算可全部取消。这与财务业务一体化对会计核算的影响是类似的，它使总账回到了它的名称所体现的本来含义，即仅仅是汇总的账，不用再设置五六个科目层级，不用再设置几百上千个明细科目，不用再做几十上百行会计分录，因为科目再多、核算再细，也不可能比业务系统提供的信息更丰富。例如要查库存商品，总账就一个总数，明细到存货核算模块去查；要查营业收入，总账就一个总数，明细到销售管理模块去查。无需会计核算的精益，会计就能掌握更准确更及时更全面更详细的信息，那还有必要追求会计核算的精益吗？当然，这并不意味财务部门就没事可做了，相反更重要了，它的工作重心应从后端账务转移到前端业务，主要职能应从财务会计转移到管理会计。

最完全的辅助核算，即没有缺漏的、真正意义的多维组合，其数据量之大已经超出了科目辅助核算范畴，不是会计核算模块能够解决的，而需要独立的成本管理模块，由这个独立的模块去处理费用归集与分摊，实现多维组合，提供所有成本数据。然后，类似于财务业务一体化，由成本管理模块生成汇总的成本类会计凭证，传递到总账。

基于失败的财务分析项目，如果我们深入分析，同样可以产生多维组合成本的思想火花，从而打开全新视界。当然，从精益生产管理，从数据质量管理等深入下去，也是可以产生的，正所谓条条道路通罗马。有价值的火花处处有，我们曾经路过却没有看到，或虽然看到却没有捕捉。

同样是进行多维分析，多维组合成本与商务智能项目有着质与量的双重区别。从数据的角度可以看到，多维组合成本不是简单的数据搬家，不是简单的将分散查询转化为集中查询，不是简单的将平面二维查询转化为立体多维查询，而是通过分摊模型，让原本孤立的数据面向应用关联，让原本静止的数据基于规则流动，在关联中聚合，在流动中碰撞，在聚合与碰撞中裂变，在裂变中产生多维组合的海量数据，进而丰富数据资产。