在企业信息化大的背景下，业财融合成为了大的趋势，企业的信息化建设做的好不好，关键还在于财务的信息化建设做的怎么样，财务的信息化能直观的体现出公司的经营状况，未来发展趋势。这就需要企业提高对于财务的管控能力。
但是要实现业财融合，首要解决的是业务信息化，然后将沉淀下的业务数据能高效、及时、自动、无差别的向财务数据转换，要实现这一点，就需要有统一的数据统计口径、完备的数据地基，这样才有可能为业务提供有效的经营决策。
当前大多数企业的信息化工作，业务板块和财务板块的信息化均是割裂的、孤立存在的、要实现业财的融合，首先需要实现从各个业务系统获取业务系统数据,然后经过转换形成统一的财务语言,在此背景，会计引擎就孕育而生，也就是说会计引擎就是将业务语言通过规则映射转换成为财务可理解的会计凭证
构建会计引擎的难点
一、业务和财务语言的不统一
业财融合的基础在于业务的数据向财务数据进行转换，而企业在信息化建设时，往往缺乏长远的规划和思考，而业务的数据也是伴随着业务系统进行业务处理产生的，这些数据缺乏统一的口径以及一致的基础数据，在未经过清洗和整理形成标准化的数据之前，很难转换成为财务语言数据
幸运的是，传统的财务经过多年的发展，已经形成了统一且规范的会计语言。基于准则，以会计凭证为记录载体，财务报表为信息展示的载体，能够比较轻松的理解财务、会计的信息。起码，一个会计人员在看到其他人编制的会计分录，能够意识到这背后发生了怎样的经济事项。
在这情况下，挑战的主要来源在于业务端的信息，如何让信息可读、统一成为了第一个门槛。
二、会计凭证场景的梳理
在建立会计引擎的过程中间，最为重要的一点就是将所有需要从业务语言向财务语言翻译的业务场景系统化。通过场景梳理，能够针对每一类需要生成会计凭证的业务场景定义转换规则。似乎这是会计引擎的基本要求，但实践中，要做到全面无遗漏的场景梳理相当不容易。
当然，这种场景的梳理又非常依赖于经验的积累，如果我们无法一次梳理清晰，就必须要考虑如何在会计引擎的设计过程中保留足够的弹性，允许我们能够快速灵活的配置和增加场景规则，从而减少因场景梳理复杂性带来的影响。
三、会计凭证颗粒度的选择
另一个问题，是对于会计引擎转换后的会计凭证的颗粒度的选择。实际上，对于总账系统颗粒度之争就一直存在。有些选择保留原汁原味的业务颗粒度，基于明细业务交易形成会计凭证，并记入总账。这种模式的优势在于高度的可追溯性，但弊端在于极大的总账数据量带来的性能影响。所以，另外一些选择将业务信息进行合并记账，这就要求会计引擎要能够设计出灵活的合并规则，能够基于合并规则将明细业务数据转换为浓缩的会计凭证，如何选择凭证的颗粒度，以及如何在会计引擎中对合并颗粒度的可配置进行设计处理，又是另一个难点。
四、逆向流程的处理
在会计引擎中，还有一个难点在于逆向流程的处理。正向的转换总是相对简单的，但如果在转换过程中发生了错误，就需要对转换错误的结果进行纠正，这就是所谓的逆向处理。
对于会计凭证来说，逆向流程往往是通过红冲以及重新制证的方式来进行处理。在处理过程中，不仅要考虑到什么样的场景会触发逆向流程，还要考虑到逆向流程的凭证规则，以及相匹配的业务流程关系。
五、财务会计与管理会计的兼顾
另一个需要考虑的问题是会计引擎在解决了财务会计的问题基础上，是否还可以用来解决管理会计的问题。
解决财务会计的问题是很好理解的。在财务会计角度，核心的逻辑是用会计凭证作为语言来实现信息的转换和记载。但对于管理会计来说，类似于财务会计方法的翻译，更适合解决在管理会计视角下的维度的扩展，无论是收入还是成本支出，将业务信息基于管理会计规则实现多维度的信息转换和记载是没有太大问题的。
但如果要再考虑管理会计中更为复杂的内容，如业务成本分析、分摊处理等等，使用会计引擎的方法来解决就比较困难了，这个时候，更适合采用专业化的管理会计系统来实现。
六、业财数据的不一致性
首先，由于业务系统的数据更多的是明细数据，而财务系统的数据则存在合并后记录的情况，这使得业务与财务系统之间出现总分核对的问题，信息系统之间产生数据不一致的情况很多，如果缺少有效的数据核对和校验机制，就难免出现业财不一致的情况；
其次，数据一致性的挑战还来自于系统之间的接口可靠性，数据的传递过程不可避免的出现少数、多数、重复等问题，如缺乏有效的校验机制，很可能会导致双方的数据不一致情况出现；
再次，各个系统经过多年的信息化建设，系统之间本身就存在很多的业务和技术债务，基础数据的不一致性、系统组织架构的不一致性、数据字典的不一致等等成为了数据转换的拦路虎。
最后，由于部分业务实现的是半系统化，存在着诸多线下业务，财务只能继续保留直接数据录入入口，导致缺少关联的业务数据，因此在整个业务链条中均存在着人为修改的情况，导致业务数据与财务数据的不一致性。
七、业财数据的可追溯性
业财融合的基础是将业务数据转换为财务语言的数据，如同翻译一样，希望对于翻译后的每一句话都能够找到其原始语言下的信息来源，这样便于后续在应用过程中的信息核对。对于会计凭证来说也是如此，无论是业财核对也好、审计也好，总是有各种各样的需求，希望能够对于最终形成的会计凭证能够找到清晰的追溯线索，直至业务的源头。而这种情况对于合并形成会计凭证的会计引擎来说挑战是很大的，由于复杂的合并规则的存在，使得合并后的会计凭证向前的追溯成为难题。
会计引擎的构建
借助会计引擎，我们可以实现“业”与“财”在数据无缝对接的同时保持自身系统的独立性，并且专注于各自专业化领域的发展，会计引擎就是在业务系统与财务系统之间嫁接起一座桥梁，对接业务系统与财务系统，完成从业务数据到财务数据的转换，最终形成统一的会计凭证输出，在此基础上能最大程度把财务从基础的财务会计工作中解放出来，去专注于管理会计领域的工作，最终通过财务驱动业务的发展。
如何设计一套完整的、多维度字段、任意场景下的会计凭证生成引擎，成为了业财融合的关键。
会计引擎作为将业务语言转换为财务语言，其主要包含以下步骤：
第一，按照来源系统定义业务表，每个来源系统对应一个业务表，便于将来源系统的数据进行分类存放。业务表是指对业务内容和数据做统计分析的表格，根据不同企业不同业务的需要，会产生多种形式的业务表。
第二，定义组织映射，便于来源系统数据传输到会计凭证后能够区分出对应的财务组织。
第三，准备核算基础资料。按照核算系统的账套、会计结构、汇率表等在会计引擎中维护对应数据，具体包括：账套、财务组织（成本中心）、科目体系（科目）、会计结构、辅助核算、汇率方案、特殊总账标识、现金流、记账代码、特殊总账类型、凭证类型（新增）、维度、币别、计量单位等。
第四，设置凭证方案，包括选择凭证方案使用的来源系统、选择来源系统中的业务分类，方便定位到业务表、选择凭证方案使用的账套和与之相匹配的凭证模板、设置凭证状态（暂存凭证、已提交凭证）以及生成时效（实时生成、事后生成、调度生成）。
第五，基于凭证方案定义映射表，根据目标值及业务、财务两大影响，配置对应的取值规则。
第六，配置凭证模板，即设置凭证头和凭证行的取值规则。凭证头包括核算主体、账套、摘要、凭证编码、凭证类型、业务日期、记账日期等；凭证行包括行类型、借贷方向、会计科目、辅助核算、现金流、计量单位、数量等。
第七，生成凭证，并对生成过程进行运营监控，以便使用者能根据来源系统、核算组织等字段信息进行凭证查询。
第八，会计引擎与相关系统的对接及后续操作。对接共享运营系统，将需要审核的分录传递到共享运营系统，共享运营系统需要回传审核后的状态；对接外围核算系统，传输已经通过共享运营系统审核的会计分录；对接来源系统，返回凭证生成的结果，防止重复生成凭证。
最后
会计引擎的建设不是一蹴而蹴的事情，是通过长时间的业务沉淀和积累的一个过程，在很多企业，财务作为业务的最末端，在业务设计之初，就较少的顾及到财务的需求，因此在这个建设的过程中有一个阵痛期，而同时懂财务、经营、信息化建设的复合型人才极度缺乏，使得在整个建设过程中，难免会走很多弯路，只有脚踏实地，才能避免半途而废。
