建立统一会计引擎,实现高度业财融合

在今天谈论业务财务一体化的事情已经不是什么新鲜话题了……

所谓的业务财务一体化，往复杂了讲，需要财务能够理解业务，深入的介入到业务前端的管理活动中去，能够为业务部门提供有效的经营决策支持。

但是，我们必须也要看到，业务财务一体化并不是建立在空中的楼阁，要想真的做到这一点，有一个牢靠的地基非常重要。

那么，这个地基是什么呢？

在我们看来，实现业务数据、业务信息向财务信息的高效、自动化、无差错的转换就是这样的一个地基。

但不幸的是，看起来简单的一件事情，要真的做到和实现还存在着不小的挑战和差距。会计引擎的出现，帮助我们有机会去尝试解决这一问题。让我们业财融合的挑战、会计引擎的概念、应用现状以及如何构建统一会计引擎来一步一步的看看这件事情。

业财高度融合的挑战

业务与财务的高度融合一直是业务财务管理领域大家高度关注并期待能够解决的重要研究课题。

如同我们讲到的，要实现这一点，需要打下坚实的数据地基，只有存在这样的基础，财务才有可能使用口径丰富且数据一致的财务信息来向业务部门提出有效的经营决策建议。

在实现这一目标的过程中，我们能够看到三个显著的挑战，业务财务双语言的挑战、业务财务系统集成的挑战和业财数据不一致的挑战。

业务财务双语言的挑战

业财融合的基础

在于业务信息向财务信息的转换。

这如同人们在交流的过程中所进行的语言的转换，一个以英语为母语的人，在没有接受过汉语教育前要和一个讲汉语的人深度交流是非常困难的。

同样的，对于业务信息来说，它更多的伴随着业务系统在进行业务交易处理的过程中所生产的。这些信息在没有经过很好的整理和标准化之前，本身作为一种语言都是很难进行直接的解读和理解的，更不要说转换为财务的语言。

庆幸的是，在交流的另一方财务，由于较早的规范化体系的建立，让我们在这个过程中构建了一天会计语言。基于准则，以会计凭证为记录载体，财务报表为信息展示的载体，我们能够比较轻松的理解财务、会计的信息。起码，一个会计人员在看到其他人编制的会计分录，能够意识到这背后发生了怎样的经济事项。

在这种情况下，挑战的主要来源就在于业务端的信息。如同一门语言一样，如何让业务信息可读，可理解成为摆在我们面前的第一个门槛，而更为重要的是，我们还需要为业务语言和财务语言之间准备一个翻译器，从而让业务信息能够自动的转换为财务信息。

业务财务系统集成的挑战

第二个挑战

来自于信息系统集成的挑战。

我们很难想象如果在一家企业中的业务系统、财务系统都是高度孤立的情况下实现信息的基础。这就如同一个村落里全是自闭症人群，然后我们还要求这些人之间能够做到无缝交流。

还是以语言来举例子，村落里有两群人，一群人讲英语，另一群人讲汉语。要实现整个村落中信息的充分流通不仅要打通英语和汉语之间的语言割裂，在这之前，首选要解决的还包括如何解决讲英语的自闭症业务系统之间如何进行信息交流，讲汉语的财务系统之间如何进行信息交流。

所以，讲到这里，我们能够看到，信息系统之间的额打通是我们构建业财融合的根本，不仅仅是业务系统与财务系统之间的打通，还包括业务系统内部之间的打通和财务系统内部间的打通，而这正是当前我们很多企业不得不面对的另一重大挑战。

业财数据不一致的挑战

第三个挑战来自于业务和财务的数据一致性。即使信息系统之间实现了集成，但仍然不得不面对业务与财务数据是否能够保持一致的问题。

信息系统之间产生

数据不一致的情况很多。

由于业务系统的数据更多的是明细数据，而财务系统的数据则存在合并后记载的情况，这使得业务与财务系统之间出现总分核对的问题。如果缺少有效的数据核对和校验机制，就难免出现业财不一致的情况。

另一些时候，业财一致性的挑战还来自于系统之间的接口可靠性。由于数据的传递过程不可避免的出现掉包或重复等技术问题，如果缺乏有效的数据接口的校验机制，很可能也会导致双方的数据不一致情况出现。

更多的时候，业财的一致性是人为导致的，一种情况是核算系统保留了直接数据录入的入口或存在前置的补录入口，导致缺少支撑的业务凭证直接进入；或者是数据存在台账入口；最复杂的情况是链条的最前端，也就是业务系统并非从源头开始系统化，存在人工数据进入的环节。此外，全链条中任何允许数据人为修改的情况都会导致业财一致性被破坏。

什么是会计引擎

尽管我们很难依靠单一的工具或者手段来彻底的解决业财高度融合以及一致性的问题，但有些工具能够帮助我们从某一环节来加以改善，会计引擎就是其中之一。下面，让我们共同来看一看，什么是会计引擎，以及建立会计引擎有怎样的难点。

1 会计引擎基本原理

会计引擎简单理解起来可以看作是将业务系统语言转换为财务语言的翻译器。要理解会计引擎的概念，不妨从翻译器的原理来看待这个事情。

对于一个翻译器来说，如果要让它运转起来，首先要能够实现语言的输入，基于输入的语言，再通过一系列的语法分析以及规则转换，将其形成新的语言再输出。

当然，我们这里所将的翻译是基于文本信息来讲的，如果是基于语言的处理，最大的难点将转变为在输入环节，如何让计算机能够听懂理解人类的语言，并将这些语音信息转换为文字。

那么对于会计引擎来说，我们可以参考类似的方式来解决问题。

首先我们需要从各个业务系统来获取业务系统数据的输入。在这个过程中，我们必须意识到，会计凭证是企业各类经济活动结果的反映，在这种情况下，能够支撑我们进行财务语言转换的前端业务系统的涉及面也必然是广泛的。

当这些业务系统与会计引擎之间建立了数据接口后，我们就形成了类似翻译器的语言输入过程。

那么接下来，要做的事情是语言的转换。对于会计引擎来说，需要建立起一套类似翻译器中词汇映射和语法映射的规则转换机制。也就是说，要建立起业务数据向会计凭证进行转换的系统规则。

 

 

当然，这里有一点和翻译器是不一样的，对于翻译器来说，我们不管输入是什么，都需要别动的接收这些输入信息，并转换为另一种语言进行输出。

而对于会计引擎来说，我们首先是基于会计凭证的数据构成规范来看我们需要什么输入，对于形成会计凭证无用的数据，我们根本就不会考虑进行业务系统的数据输入。

在这种情况下，业务系统根据会计凭证的数据需求提供数据输入，在经过预先设定的业务语言向会计语言转换的规则处理，形成准凭证。

所谓的准凭证是在会计引擎处理后形成的预制凭证，由于还没有进入总账系统，被称之为准凭证。准凭证进入核算系统后，形成正式的会计凭证，完成语言输出的过程。

2 建立会计引擎的难点

从上面介绍中能够看到，会计引擎基本原理和大逻辑貌似也并不复杂，但是为什么很多企业却没有能够做到这一点呢？实际上，简单的背后往往蕴含着复杂的细节。会计引擎在实际的建设和应用过程中还是存在着一些难点。

难点一 会计凭证场景的梳理

在建立会计引擎的过程中间，最为重要的一点就是将所有需要从业务语言向财务语言翻译的场景系统化。

通过场景梳理，能够针对每一类需要生成会计凭证的业务场景定义转换规则。似乎这是会计引擎的基本要求，但实践中，要做到全面无遗漏的场景梳理相对的不容易。

当然，这种场景的梳理有赖于经验的积累，如果我们无法一次梳理清晰，就必须要考虑如何在会计引擎的设计过程中保留足够的弹性，允许我们能够快速灵活的配置和增加场景规则，从而减少因场景梳理复杂性带来的弊端影响。

难点二 胖瘦的选择和处理

另一个问题，是对于会计引擎转换后的会计凭证的胖瘦的选择。

实际上，对于总账系统胖瘦之争就一直存在。有些企业选择保留原汁原味的业务颗粒度，基于明细业务交易形成会计凭证，并记入总账。

这种模式的优势在于高度的可追溯性，但弊端在于极大的总账数据量带来的性能影响。所以，一些企业选择将业务信息进行合并记账，这就要求会计引擎要能够容纳合并规则，能够基于合并规则将明细业务数据转换为浓缩的会计凭证，就如同直接将英文转换为汉语的文言文，如何选择转换的颗粒度，以及如何在会计引擎中对合并颗粒度的可配置进行设计处理，亦是难点。

而实践中，对于选择瘦总账模式的企业有可能会要求在此基础上再补充设立胖子账，从而兼顾对于性能和明细数据的需求。这都对会计引擎提出了更高的要求。

难点三 逆向流程的处理

在会计引擎中，还有一个难点在于逆向流程的处理。

如同翻译，正向的翻译总是相对简单的，但如果在翻译过程中发生了错误，就需要对翻译错误的结果进行纠正，这就是所谓的逆向处理。

对于会计凭证来说，逆向流程往往是通过红冲以及重新制证的方式来进行处理。在处理过程中，不仅要考虑到什么样的场景会触发逆向流程，还要考虑到逆向流程的凭证规则，以及相匹配的业务流程关系。

在没有考虑会计引擎的逆向处理的规范时，业务系统中往往是不会充分考虑到对逆向流程的数据规范支持的，而在会计引擎模式下，业务系统必须进行相应的改造和规范化的配合。

难点四 能否兼顾财务会计与管理会计

另一个需要考虑的问题是会计引擎在解决了财务会计的问题基础上，是否还可以用来解决管理会计的问题。

解决财务会计的问题是很好理解的。在财务会计角度，核心的逻辑是用会计凭证作为语言来实现信息的转换和记载。但对于管理会计来说，类似于财务会计方法的翻译，更适合解决在管理会计视角下的维度的扩展，无论是收入还是成本支出，将业务信息基于管理会计规则实现多维度的信息转换和记载是没有太大问题的。

但如果要再考虑管理会计中更为复杂的内容，如动因管理、复杂的分摊处理、作业成本管理等等，使用会计引擎的方法来解决就比较困难了，这个时候，更适合采用专业化的管理会计系统来实现。

难点五 可追溯性的保留

对于会计引擎的最后一个难点是对于可追溯性的处理。

如同翻译一样，我们希望对于翻译后的每一句话都能够找到其原始语言下的信息来源，这样便于我们后续在应用过程中的信息核对。

对于会计凭证来说也是如此，无论是业财核对也好、稽核审计也好，总是有各种各样的需求，希望我们能够对于最终形成的会计凭证能够找到清晰的追溯线索，直至业务的源头。

而这种情况对于合并形成会计凭证的会计引擎来说挑战是很大的，由于复杂的合并规则的存在，使得合并后的会计凭证向前的追溯成为难题。如何在会计引擎设计过程中就预留下追溯机制及线索，是我们必须要认真思考的问题。

会计引擎应用现状

当我们了解了会计引擎的原理以及会计引擎的实现难点后，我们再来看一看会计引擎当前在国内财会领域的应用现状优势如何。事实上，会计引擎在我国的发展还处于相对初级的阶段。

可以从两个方面看到这种状况:

一方面，会计引擎分散在各种不同的专业化财务和业务产品中；

另一方面，会计引擎在我国不同的行业中的应用深度也是不同的。

会计引擎分散在各种专业财务和业务产品中

会计引擎到今天能够实现独立产品化的应用还是鲜有见到的。多数会计引擎都还是隐藏在各种各样的专业化的财务信息系统中，甚至很多都是直接内置在业务系统中的。为什么会是这样的一种局面呢？

我们在会计引擎的发展中能够看到，会计引擎的建立很多时候是被动的，首先是财务有了会计核算的要求，在没有建立业财对接的情况下，传统财务是依靠手工录入凭证的方式来进行业务向财务语言转换的。

随后，有人意识到，一些业务系统是有机会直接和财务进行对接的，而在针对某个专业的财务系统（非总账系统）或业务系统对接的过程中，也意识到，使用一个翻译器，也就是会计引擎能够很好的处理这一对接过程。

这就使得在一些专业的财务系统，如费用报销系统、资金系统中以及业务系统中分别各自搭建了会计引擎。这最终形成的局面就是在一个企业内部各种不同的财务业务系统中都或多或少的蕴含着一些形态各异，功能差别较大，成熟度不一的会计引擎模块。

分散在各个专业财务或业务系统中的会计引擎模块往往都是针对差异化的特定场景来开发的，因此，在建设过程中并不需要进行复杂的模型抽象，也因此使得此类会计引擎比较容易实现。

会计引擎行业应用深度不一

在另一个视角上，会计引擎在我国各行业的应用实践中差异还是比较大的，也可以说存在着一些优势行业。

对于大多数的行业来说，会计引擎的应用主要还是简单的集中在费用报销和资金收付的过程中。在过去的十数年的发展中，很多企业都建立了电子报账系统和资金管理系统，而作为标配的系统功能，简单的会计引擎被内置于这两类系统中。

但在某些行业中，除了在专业化的财务系统中引入会计引擎，更为广泛的应用被覆盖到了业务系统中。比较典型的如金融业、零售业、电信运营业中，当然在制造业中的生产制造过程基于ERP的高度集成，也能够理解为是某种意义上的会计引擎。

例如在保险行业中，在核心业务系统里通常会建设有一个“收付费”系统。这样的一个系统本质上就是一个行业化的会计引擎产品。

在保险行业中，客户承保、理赔的各项业务流程的处理所形成的业务信息都将汇集到收付费系统中，收付费系统基于业务信息进行规则转换和合并处理，形成会计凭证。

在保险行业，由于业务交易量庞大，往往很难基于保单级的单位进行明细记账，合并账务处理成为常见的处理模式。

由此可以看到，会计引擎在不同行业的应用往往存在着一定的特色和特定的场景客制。

统一会计引擎

那么，统一会计引擎又是什么？

对于统一会计引擎来说，这一概念又是在怎样的背景下被提出的呢？

让我们从建立统一会计引擎的概念、背景、价值以及建设难点来简单的了解下这个较之传统会计引擎前进了一步的新概念，以及我们如何在智能化下去实现对统一会计引擎的进一步增强。

什么是统一会计引擎

统一会计引擎和传统会计引擎相比，核心就在于“统一”两个字。

如上文所说，多数的会计引擎都是搭建在其他的财务或业务系统中，以一个模块的形式存在的，稍微好一些的，也就是在专业系统中圈下块地盘，形成一个相对独立的子系统。

而我们这里所说的统一会计引擎则是希望能够打破其寄生系统的束缚，能够从各个系统中独立出来，形成一个专业化的系统平台，通过这样的一个平台，形成一个多语言翻译器，也就是说，使用统一会计引擎一端对接企业内所有业务系统和专业财务系统获得信息输入，另一端对接核算系统和管理会计系统，形成会计凭证的生成。

建立统一会计引擎的背景和价值

那么，为什么要建立统一会计引擎，其价值又是如何呢？

多数企业的会计引擎在信息化建设的过程中以叠加的方式一步一步的建立了起来，但到了一定阶段后，我们会发现这种被动建设的多会计引擎模式，对于大型企业集团来说慢慢的会成为一种负担。

很多时候，由于会计引擎建立的时间阶段差异，难以遵循统一规范的技术标准，这使得很难有效的监控这些翻译器的翻译质量，慢慢的，也就在这些会计引擎背后埋下了一些隐患和风险。

而由于多引擎维护的复杂性，科技人员往往并不敢对这样的平台展开深度优化，而随着人员的流失及文档的遗失，长此以往，对会计引擎的维护甚至都成为很大的挑战。

因此，一些企业意识到，如此堆砌优化，不如将分散在不同系统中的会计引擎剥离出来，建立一个具有扩展性的统一会计引擎工具，基于这个工具，

一方面能够更加有效的支撑当前的存量系统和业务单元的业财对接，提升运维质量，降低潜在风险；

另一方面，能够基于统一会计引擎快速服务于新建立的业务或财务信息系统，以及新成立的业务单元。

统一会计引擎的建立难点在哪里？

但我们必须认识到，统一会计引擎的建立是具有一定颠覆性的，无论在设计统一会计引擎还是在后续的推广实施的过程中都存在困难和挑战。

首先，对于统一会计引擎开说，在设计方面的挑战来自于各种不同业务场景的抽象和提炼。

由于我们对统一会计引擎在一开始的定位就是对接所有业务系统的，这就要求，一个好的统一会计引擎，不仅要能够灵活的支持现有的业务场景，还要能够支持未来的潜在业务场景。所以这件事情如果是一个行业或业务场景并不充分的企业来做，很可能在拓展性方面面临很大的风险。

因此，统一会计引擎的实践有可能来自于一个行业覆盖广泛的大型多元化企业集团，或者是来自于一个拥有多行业存量客户的独立财务信息化厂商。

但对于后者来说，还存在一个极大的挑战，财务信息化厂商往往对于不同行业下企业的业务系统的理解是不如前者深入的，要真的做好此事，不妨寄希望于一些大型多元化集团更为可行。

  其次，当我们搭建了这样的一个统一会计引擎后，在实施的过程中必然要面对从存量在用会计引擎向新的统一会计引擎切换的问题。

事实上，人们对于完全新建的事情总是相对放心，而对于从已有向替代品切换的过程反而充满顾虑。

在这个过程中，要说服各个业务系统及相关部门将现有的流程切换至新的平台就必须对如何解释新平台的优势、可靠性以及转换过程中的风险应对做出充分的解释。这往往会演变为一场变革管理。

智能化下的统一会计引擎

尽管我们意识到统一会计引擎的建立可能并不是一帆风顺的事情，但我们同样看到的还有它建立后所带来的价值。

而在今天，随着智能化技术的进步，我们还有可能在建立统一会计引擎的过程中更进一步，借助智能技术，对统一会计引擎实现进一步的能力提升。

如同翻译领域对智能化技术的应用，统一会计引擎可以考虑适当的应用机器学习技术，来辅助完善翻译器的翻译规则。也就是会计引擎的凭证转换规则。

从一个简单且常规的模式出发，我们对于统一会计引擎的建立优先会借助经验的积累来进行规则的建立，但面对多行业以及全场景的复杂性，基于人的经验的穷尽可能会面临挑战。

而应用机器学习技术通过对标签化的业务信息的输入和学习训练后，能够更为高效的提炼转换规则，并提升会计引擎在面对新问题时的处理能力。

另一方面，区块链技术在业务系统、专业财务系统、核算系统之间如果能够搭建分布式底账，将能够帮助我们提升对于会计引擎转换结果的可追溯性带来极大的帮助。

统一会计引擎的建立在我国尚处于探索和尝试的阶段，但在大型多元化集团的落地应用并不遥远，而未来，面向社会提供服务的低成本甚至免费的开放式统一会计引擎平台的出现也并不是梦想。而智能技术在开放统一会计引擎平台之上亦能够发挥更大的价值。