关于合并报表系统，你有get到关键点吗？

节前，有家单位来参观我们的信息化项目实施情况，作为他们项目的参考，因此有了大概1个小时的交流。或许是新疆较为闭塞吧，感觉很多企业信息化水平还是有很大提升空间。


该公司是一个小型集团企业，大概有约十家分子公司，目前使用的是K3单体帐套，合并报表实现起来较为复杂，也影响了集团分析的效率和质量，所以想要做项目升级实现合并系统。这大概是我们公司十年前的状况，从那之后，从合并账务到一个数据中心再到如今的业务财务全集成，已经是几经更迭。


由财务总监带队，同行的也是以财务部同事为主。合并报表系统的实现是他们的主要关注点，交流过程中发现他们最大的困惑其实在于业务流程如何设计。实施方只从系统功能角度给出了解决方案，并没能结合他们公司的实际业务场景，因此他们才心存疑惑。


这可能是财务信息化项目的共同困惑点，财务有会计准则和财务制度要求，从系统实现角度看单纯的财务系统几乎不会有难度，实施方通常会选用放之四海而皆准的解决方案。项目实施过程中，顾问通常会以梳理报表需求确认科目体系为重点，如果不涉及业务集成，并不会花太多时间去梳理财务流程。毕竟凭证审批、期末结账这些都是很常规的工作，很容易被认为一切OK。


真是这样吗？如果从优化的角度，单纯的财务信息化项目也仍是有很多可以下工夫的地方，比如与合并报表抵消有关的内部往来交易业务，再比如直接反应财务部整体效率的财务月结流程，借这次交流先说说合并报表业务流程的梳理。


报表合并在集团公司仍是很重要的一项工作，操作方法不同所需要花费的时间也完全不在同一个量级，影响合并效率的因素大概可以分为两维度：信息系统所具备的功能，以及集团公司对内部往来交易业务的设计。


就我所知，主流的财务软件在处理合并时的思路相似，通常会提供两大功能：
     * 内部业务发生时的实时对账。比如EAS系统，对于往来业务在总账系统有往来通知单，比如本部给分公司拨款，本部和分子公司之间挂往来，那么在业务发起方本部做凭证时，会自动产生一笔往来通知单发送到分公司的帐套，分公司可以通过这笔通知单生成凭证，或者手工生成凭证然后与本部的通知单确认。而SAP系统可以在本部做凭证的同时生成分公司的往来凭证，但前提是双方挂账用统一的核算规则，科目是非常明确的。


     * 报表合并时的核对抵消。EAS系统的实现方式是，各公司先以报表形式上报往来数据，合并时对数据进行汇总和核对，然后自动生成抵消分录。也有软件不需要上报报表，直接基于各公司账面的往来数进行汇总核对，差别不大具体看公司实际需要。


具备这两项功能的软件，差异就只是操作界面不同而已，熟练后对效率影响不大，所以我觉得真正影响合并效率的是业务设计。


内部交易
集团企业如果开始做上下游供应链整合，大概A买B，B买C，C又买A这样复杂的内部交易业务就不可避免。怎样解决？集团内部交易系统设计是很大的话题，包括定价策略，税务筹划的考虑，甚至利润在产业版间的转移。这是从公司战略层面考虑，如果稍微把范围缩小，从财务维度，我认为可以先梳理这样四件事：
     * 会发生哪些类型的内部交易业务，产品？材料？资产？服务？
     * 都是必须的吗？有没有替代方案？如果是，有没有可能固定在某些公司之间？
     * 有否从整个集团角度统一核算口径？比如计价方式，成本核算方式，存货跌价处理等。
     * 每类业务如何进行财务核算？科目如何设置？ 最简单的核算方式是怎样的？


然后就是基于这些问题的答案确定实现方案了，分享之前的一个案例，大概实现是这样：
     * 全集团统一核算口径，内部交易未实现销售存货，统一按照行业毛利率抵消成本。
     * 划分事业部，跨板块的内部交易，通过事业部本部进行三方交易。
     * 明细数据不体现在抵消分录，抵消分类主反应 收入、成本、存货等大项。
     * 事业部层处理本版块内的抵消业务，跨版块业务汇总到最后一级合并单元集中处理。


内部往来
内部往来相较于内部交易要简单一些，最重要的一点是确定核算规则，比如哪些科目会涉及内部往来业务，双方分别如何挂账。这很关键，如果A挂应收账款，B走其他应付款，或者A用预收账款贷方，B用应付账款借方，最后核对就不那么容易了，以前项目上我通常会会这样建议：
     * 预收、预付不做内部往来核算；
     * 内部购销业务增加单独的二级科目，用应收账款_内部和应付账款_内部核算；
     * 其它往来业务用其他应收款-内部，其他应付款-内部，如果资金管理是收支两条线，资金往来也通过这个科目核算。
     * 避免分子之间直接挂往来，通过本部三方转账；
     * 最后就是让客户确定核算规则。


关于财务信息化，我越来越觉得业务梳理才是关键，也应该是蓝图阶段的核心价值。但实际项目中常常会把上线作为重要衡量目标而忽视了蓝图的质量。在做SAP项目后，最大的感触是之前EAS项目的蓝图阶段太流于形式，流程梳理和核心业务测试做得并不是很到位，当然SAP项目蓝图的质量和价值也取决于实施团队的整体水平。