集团企业拥有多家所属企业，如果用一套集团统一建设的ERP系统或者财务系统覆盖所有子企业这是最理想的情况，但实际中，集团企业的构成往往很复杂，多业态、多国别、多产权结构、多管控模式……信息化情况相应的也非常复杂，存在大量异构系统。

而集团层面的合并报表、核算(ERP)一体化、数据分析都对集中全集团的财务数据有着现实需要，例如合并报表，以前以“表级”合并为主，但现在企业都希望实现“凭证级”合并;又例如现在特别强调的数据分析，也需要集中财务领域最小颗粒度的记账凭证数据，那么关于财务凭证及数据的集中，在现在的技术条件下，一般有两种方式。

在开始正文之前，先简要看看统建系统和异构系统。使用集团统建财务系统的子企业，直接在集团统一的会计政策、核算标准、数据标准等体系下(大量规则已被配置在系统中)，在统建系统中记账完成核算工作，统建财务系统又与统建的合并报表、数据分析等系统集成，在技术层面上集团总部能够直接的使用统建系统的数据。

本文指的异构系统，主要是因为管理、技术等多方面原因，子企业在较长的一段时间内无法使用集团统建的系统，而要继续使用的自建系统。而异构，不仅仅是不同软件厂商、不同产品、不同版本的差异，即便是相同版本的同一软件产品，只要是独立部署的多套，在系统集成和数据层面也算异构系统，只是这种情况相对比较容易整合。

对合并报表，只要缺少一家子企业的数据，就不能形成完整的集团合并;对数据分析也是，缺少一家也无法完成对整个集团的数据分析。这就需要把集团内各子企业异构系统中的财务数据集中，与统建系统中的数据整合在一起，从而形成完整的数据集。

下面具体讨论两种方式。

方式一：过账式集中

对没有使用集团统建系统的子企业，子企业在自建财务系统中完成核算后，把记账凭证等数据传给集团统建财务系统并且过账，即在统建系统中也要做同样的一张记账凭证，相当于在统建系统中形成了一套子企业账的“副本”，那么企业自己的系统中有一套完整的账，在集团统建系统中还有一套一模一样的的账。关键是，子企业日常使用的是自建系统中的账，集团统建系统中的只是为了集团的数据集中。

为了向统建财务系统过账，在传记账凭证数据之前，还需要提前把诸如客商、组织人员、物料、项目等相关的档案数据传给统建系统(辅助核算所需要的)，需要提前在统建系统中产生过账所需的各类档案数据，统建系统中缺失这些档案数据过账时就会报错。并且，在集团统建系统与多套子企业异构系统并存的情况下，还必须要做集团层面的主数据治理，例如在没有规范管理时，同一供应商在不同企业很可能有不一样的编码和名称，而在集团不做唯一性管理的情况下，这些供应商及相关数据一股脑传到统建系统中，无论供应商档案数据还是记账凭证数据都会混乱。

子企业向统建系统过账需要有两个保障，第一个是子企业向统建系统传的数据要正确送达，这依赖于网络、企业服务总线(或接口集成平台等)、企业自建系统的发送接口、统建系统的接收接口等技术环境要稳定，一旦数据传送本身因上述内容出现异常就无法在统建系统顺利过账;第二个是诸如档案以及财务系统的一些配置要就绪，否则即便凭证等数据正确送达了统建系统，但过账也会报错。这两点都会产生一定的应用成本，日常需要投入足够的人员和配套技术资源长期运维，一旦出现过账异常，就需要运维人员排查数据收发状态、重新推送数据等。

上一段是技术侧的内容，而在财务侧，如果子企业在自建系统中对凭证做了修改、删除、红冲等操作，那么也需要财务人员同步登录到集团统建系统中，在统建系统中重复做一次相同的操作，以保证两套系统中财务数据的一致性，并且在统建系统的操作要很严谨，一旦误操作，两套核算系统中的数据就不一致了，虽然也可以补救(例如额外做几张凭证更正错误)，但可能是统建系统的凭证数量与子企业的就不一样了。当然也可以开发接口自动的完成上述操作，但这类接口开发相对比较复杂，成本也比较高，如果凭证数量巨大，相应的凭证修改等操作也比较多的时候，更适合开发接口。

在上述技术侧和财务侧工作都到位的情况下，过账式集中可以让统建财务系统中有完整、标准统一的一套全集团的财务数据，后续无论合并报表还是数据分析，都直接对这套数据开展工作即可。

但有一点需要特别关注，对集团统建财务系统而言，使用自建财务系统的子企业并不是统建系统服务的对象，这些子企业并不是实质使用统建系统本身，而只是把自己的核算结果数据传给统建系统。那么对统建系统，为了容纳这些子企业的财务数据，就需要“额外”付出一些成本，例如要维护很多本身与统建系统“无关”的档案等基础数据，也有“额外”的数据存储和备份成本，也要产生相应的“额外”运维工作。当然，如果认为统建系统覆盖全集团时也是差不多的成本时，或许也不用纠结上述问题，但如果很多子企业在很长时间内都不会使用集团统建系统的时候，或许需要评估好统建系统的额外成本是否划算。

方式二：数据式集中

第二种方式不在财务系统中完成数据集中，而是使用一些数据管理类系统集中，例如：财务数据仓、数据中台、大数据平台、数据资源管理平台等(以下统称数据平台)。数据式集中，是按数据管理的思路，在技术层面基本“抛开”财务属性，就是相对纯粹的数据处理工作，包括统建财务系统在内，加上各子企业的异构系统，所有记账凭证数据及相关档案数据都汇总到集团统建的数据平台中处理和管理，数据平台再统一的面向合并报表、数据分析等领域提供数据和服务。

数据式集中有个较为显著的优点是，在很强调数据治理和数据价值的当下，集团统建的数据平台中不仅仅只有财务核算数据，财务领域的还会包括预算、资金等数据，也会包括采购、生产、销售等业务数据，如果仅是以核算数据做分析，可挖掘的空间可能并不大，那么无论从管理会计角度，还是从业财融合等角度，财务多领域的数据与多种业务数据的整合才能更好的用于数据分析，才有更大的数据价值挖掘空间。

数据式集中的数据汇总也有两种方法，第一种是先定义好集团统一的财务数据标准(例如以统建财务系统的记账凭证数据结构为主的标准)，各系统按此标准先把数据基本处理好，然后传给数据平台;第二种则是各系统先不做更多处理，先把数据直接传给数据平台，然后在数据平台上再把数据处理为符合集团的标准。第一种方法，是“以终为始”，较为直接的获得集团需要的、标准的数据，并且数据处理的工作量主要在子企业一端;第二种方法，集团层面则是获得了子企业最完整的原始的数据，一些数据(字段)当前可能用不到，但后续可能被用到(当然后续也可以追加)，但数据处理的工作主要由集团总部层面承担了，即便把一些数据映射和加工的工作也可以交给子企业做，但集团对统建的数据平台仍然需要提供相应的功能、支持和管理，既然要做全集团的数据集中，集团总部必然需要投入相应的资金和资源。

在数据式集中的方式下，如果子企业对记账凭证或者档案数据做了修改(例如凭证的修改、删除等)，也是需要有数据更新机制的，一旦财务人员做了相关操作，就需要技术人员把对应的数据做更新或者删除。在过账式集中时，这类更新操作由财务人员完成财务软件的功能操作就行，虽然要做两次，但仅需财务人员即可;而数据式集中，对集团统建数据平台的操作往往只能由技术人员处理，这需要更好的工作协同，如果财务和技术部门没有协调好，就很可能会导致数据平台中的数据与子企业账上的数据不一致。

此处，仍然不得不再次提及主数据治理，如果集团层面没有做主数据管理，那么子企业的相关主数据(例如会计科目、供应商、客户、项目、物料等)，只能通过映射的方式统一清洗成集团可以统一识别和使用的编码及名称，这首先就需要维护映射表，会计科目的数量相对不大，但客商等主数据的数量往往很大，维护这种映射表的代价就会很高。特别是，因为子企业的数据没有从源头治理，一直是“我行我素”的状态，那么进入集团的数据平台后就需要常年累月的转化和清洗，相当于是一直在用脏水洗手，这样长期下来，此类工作的成本是极高的，而且效果也不太好。在有主数据管理的情况下，如果集团统一编码，那么相关数据基本可以直接使用，部分时候或许也需要维护少量的映射关系和做数据清洗，但数量和影响范围都要小的多，通过主数据管理可以几乎一劳永逸的解决数据映射和大规模清洗的问题。无论是过账式集中还是数据式集中，因为涉及多组织、多系统，主数据治理是绕不开的内容，是刚需。

上述两种方式，在一些集团企业都有应用，从一定意义上来说，两种方式各有特点，只要能满足企业的需求就行。