近年来，随着移动化、大数据、互联网、云计算等新技术的快速发展与运用，以蚂蚁金服、建信金融为代表的金融科技产品成为了一股新兴的势力，正在驱动传统商业银行金融互联网化的建设步伐，积极应对互联网金融不断涌现的新业态。在银行IT系统体系中，与之相关的应用系统包括核心账务系统、总账系统、财务会计管理等。
其中账务是银行信息化建设中最根本的关注点之一。因为银行众多的业务都是围绕账务展开的，如批量处理业务流水，进行账务的核对，客户贷款的期次、利息、罚息的计算，还款计划的生成，客户存款的结息等重要功能。所以，要了解现在众多的金融系统（包括互联网金融）就绕不开账务知识。
正好最近接触了不少求职者和同学的咨询和求助，总结了一些最关键的基础知识和一些实际的经验，分享给大家。
银行核心系统账务相关的业务&技术入行并不难，而是你看了太多的知识碎片和缺一个入坑的钩子。

---

1、此文适合人群：
银行业务咨询、架构师、技术leader、开发、产品经理、对账务比较有兴趣的小伙伴，以及经历过会计核算相关项目的小伙伴，如总账系统，或者一些涉及到会计核算的交易类系统，如信贷系统、存贷款核心等。

2、此文解决问题：
对新人来说，学习完后对银行会计账务模型和核心账务处理流程有初步认识，可以应对大部分的面试过程并有针对性的简历调整抓手。
对职场人来说，如果你想转型到支付产品方向或者正在面临改造核心账务系统的烦恼，此文也会对你有些帮助或启示。可以看到一个相对落地的工作实操思路。

对于想了解开放银行、账户体系，产品工厂，银行会计基础，热点账户，分布式微服务等具体业务或复杂设计方案的同学，请移步到我推荐和撰写的其他文章。

3、其他声明：
此文的输出凝聚了我在实际工作过程中遇到无数坑和查阅了各种资料后而得出总结，内容沉淀后脱敏处理，文章会引用业内产品的流程及图片作为课程讲解实例。文章中提到的知识点概念具有模式普适性和可实操复用性。

部分细节知识点的展开我会给出文章索引，方便对某个分支有兴趣的同学，自行索引我的其他文章深入学习。

文章内容不代表公司观点。部分名词解释和内容来自百度或博友分享。欢迎转发。

4、此文分为几部分：
一、核心账务的概述和术语定义
二、账务组织的业务概述
三、银行产品与银行账户的关系
四、银行产品与核算的关系与分离
五、账户与核算科目解析自动化
六、记账核心实现方法和基本思路图
七、浅谈会计分录解析
八、聊聊双边分录
九、结束语

---

1.核心账务的概述和术语定义

账务是记录具体业务经办时各种信息的汇总，指实现会计处理进行原始单证的收集、整理、记载、计算、结报等会计处理的具体事务，它要求规范、准确，保证会计核算，会计监督和会计准则的有效实施。

而会计是对企业经营活动的记录，不同业务的处理根据会计准则有不同的要求，所以先了解业务，才能了解账务。

在进行下面文章前，先抛出三个词和几个问题，产品、账户、科目。

它们之间啥关系？如何设计能适应不断变化的会计核算规则？与其他业务模块如何集成？怎么实现账务数据的自动生成？如何理解核心和总账之间的会计分录生成器（我们叫会计模型）？业务需求或对手情况如何？

而我们下面提到的一些内容，会根据关键词和问题依次展开。聊到账务，经常会遇到一些名词，为便于大家理解一致，我们先做名词解释。
★名词解释
产品：银行产品是指由银行创造、供市场和客户选择、能满足客户进行金融交易和服务的各种需求、银行可从中赚取各种实际、潜在收益的综合金融服务。
账户：银行向客户提供的产品服务有很多，一部分产品在客户购买或享受服务时会引起客户在银行的资产、负债或其它非货币权益类东西的数量变化。银行账户就是记录这些资产、负债或权益类东西的现状与变化历史的电子簿记。
核算：有狭义和广义两种理解，狭义的核算指会计核算，广义理解的核算则包括了会计核算和业务核算两部分内容。
业务核算：指银行在开展自身业务活动时应当执行的各种操作，以及由此而产生的各种原始记录。
会计核算：也称会计反映，以货币为计量尺度，对会计主体的资金运动进行的反映。主要是指对会计主体已经发生或已经完成的经济活动进行的事后核算是会计中记账、算账、报账的总称。
会计核算分录：即会计分录，一般由借方分录和贷方分录组成，借贷金额相等，方向相反，也叫传票。
会计核算引擎：将会计核算从业务处理流程中剥离出来独自形成的一个独立模块，在总账系统中负责会计核算处理和报告的完整过程，即核心系统和外围系统将必须借助于会计核算引擎才能完成相应的会计核算处理。
账套：为了核算的需要，按不同的科目体系设置不同的总账账簿，称之为账套。
记账：传票合并、检查、并更新内部分户账、科目帐的过程。

2.账务组织的业务概述

账务组织又称为会计核算形式，是指账簿的设置、记账程序、账务核对和记账方法相互配合所形成的组织体系。商业银行的账务组织由明细核算和综合核算两部分组成。

明细核算是分户反映科目详细情况的核算系统；综合核算对应总账，是按科目的维度核算，反映各会计科目总括情况的会计核算，由科目日结单、总账、日计表组成。这两个系统的账簿是按照双线核算的原则，根据统一凭证平行登记，分别核算。

每一科目明细核算各账户的发生额、余额之和，一定与综合核算该科目的发生额、余额相一致。明细核算和综合核算两者相互核对、相互制约，构成了一套完整的、科学的、严密的账务组织体系。

（1）科目分级
在综合核算在系统中，一般按需求设计科目层级，也称为“歪脖子树”，对科目进行命名和编号，形成“科目编号表”。细分的项目称为“叶子”，细分的过程称为“科目分级”。

例如，“同业存放款项”下面可以分级为“同业活期存款”和“同业定期存款”。“同业定期存款”可以继续分户到“同业一般定期存款”和“其他定期存款”。

我们可以看到，三级科目是对二级科目的进一步细分。一般来说，科目划分的越详细，越有利于在科目级进行业务统计，实现所有报表都从综合核算层的数据库表中获得数据，实现明细核算和综合核算的相对分离，确保核算体系的相对稳定。

科目分级没有固定的标准，只要是末级科目都可以直接对应分户，非末级科目下不可以对应账户。有3个特点：

◇ 平时记账在叶子上。
◇ 叶子的余额方向向上继承。
◇ 余额向上汇总。

（2）程序设计
科目作为重要的汇总参数，是以采用科目号的形式进行展示。使用这种方法，使得当科目发生变化是，对金融产品的影响最小化，特别针对金融产品的各种重要参数表的调整变得更为简单。如下：

在科目号的组成规则上，通常把一级科目号设计成4位编码，并将旗下的二级科目号设计成6位编码，并且前4位就等于一级科目编号，三级科目号同理。实际编程时也是，在二级科目向上汇总的程序中，通常也会截取二级科目号的前4位作为一级科目。

3.银行产品与银行账户的关系

账户是银行核算中最为细化的层级，能够满足产品核算的需求，而产品是开立账户的前提条件，是银行为客户提供金融服务的载体。

所以，银行创新出为客户想得更多的产品，才能更被客户认可，才更容易挖掘优质账户。

其中，产品就是银行对客户的所有诚意的体现之一。接下来，我们进一步分析产品与分户账的关系：

（1）一个产品对应一个分户账
如：某超级优质客户希望存款收益最大化，行里就新增产品给指定用户专用。

（2）一个产品对应多个分户账
如：这类产品可以对应某一客户的几个不同账户，也可以对应不同客户的不同账户。

（3）一类账户对应多种产品
如：组合产品业务，客户的存款账户除了可以对应存款产品外，还可以对应各种结算产品。

4.银行产品与核算的关系与分离

（1）产品与总账的关系
产品可以按需要与要求进行不同粒度的分类与细分，总账里与产品对应的科目，也可以按需要与要求进行不同粒度的细分，以与产品形成对应关系。

2）产品与核算的分离
从业务上来说，核算与银行客户的关系不大，属于银行内部的管理需要。从技术上来说，要实现核心系统会计核算与产品应用的分离和解耦，尽可能提高整个银行核心系统的核算灵活度。

因为银行产品服务需要秒队日益激烈的市场竞争，产品创新步骤快，产品变化频繁，加上银行系统的综合核算规则也会根据行内的管理水平、不同时期市场与监管的需要，与时俱进、不断调整。

所以为必要避免因产品或核算规则的变化而大量改程序，所以需要将产品与核算分离。

在物理结构上，可以根据实际需要，可以物理分离，也可以采用同一套应用节点，甚至同一数据库实例。但在代码实现层面，核算信息、产品信息应由使用不同的功能组件完成信息的更新处理。

比如：存量账户的利息计算由存款产品负债，贷款账户的利息计算由贷款产品负责。

基于层次化、组件化设计理念，会计核算系统内部同样也可考虑分层架构设计。将影响会计分录的会计事件，按产品、分户账等重要信息进行归纳抽象，构建会计引擎用于核算解析。

当产品账户发生交易时，会计引擎能够根据产品交易事件信息，确定具体的产品，自动提取与会计核算相关的信息，并根据预先设定的核算规则，自动将采集的数据转化为会计分录，完成账务处理。当核算规则发生变化时，只需调整会计引擎中的参数化规则。

上诉方式对外围业务系统来说，相对比较透明，对核心来说，相对可以统一管控对应会计分录的产生，但由于该接口是跟具体的业务场景相关联，因此核心需要开发和维护大量的业务记账接口，而且业务流程其实依旧在外围业务系统中管控，核心仅仅是负责业务记账而已，但又却要关注具体的业务场景，不仅大大增加了核心的负担，扩展性也较差，一旦外围业务系统的相关业务规则有变动，核心也需要跟着改动。

这是会计分录解析的方式之一，下文中会继续介绍，请继续阅读。若有遗漏或不足，还请各位小伙伴们补充和指正，欢迎一起探讨~

5.账户与核算科目解析自动化

建立以客户为中心的统一帐务体系，以客户号为为主导，联系所有与客户相关的帐户信息，所有帐户共用唯一的客户信息。

帐户管理体系采用统一的多分户模式，不论对私对公，均采用客户帐号+核算编码方式，以客户帐号做为面向外部客户的唯一形式，由系统内部管理其下所有的核算编码，使系统从底层基础支持多重帐户的管理，并可为每个核算建立与其他帐户的相关性，实现不同层次类别的帐户管理。

（1）客户账号
客户账号是存储帐户的静态信息，是指面向客户，客户能够实际看到的帐号，也可以称为主帐号。

例如：存折上打印的活期存款帐号、单位客户购买和签发支票时使用的用于结算的支票户帐号、储蓄卡卡号、一本通的主帐号、定期存单的帐号等。

（2）核算编码
核算编码一个固定长度的数字或字母编码，是形成帐户的最基本元素之一，主要用于通过核算编码进一步将核算维度与核算科目进行解耦。

核算编码每个核算编码对应一具体的银行业务产品，组成规则与业务人员制定核算维度有关，是基于大多数的业务交易场景而抽象出来的相关核算属性，比如产品类型、期限等，这是在很多金融业务场景中都存在的共性维度。举例：

在新核心建设过程中，核算编码的使用能大大降低数据移植的难度，使得原系统改动较小，但也不是非迁不可。

因为应用模块的账务处理代码基本都是查到账户有核算编码，则使用核算编码进一步将业务维度与核算科目进行解耦；若查到账户没有核算编号，则通过取账户层的核算维度+余额属性取核算科目。

（3）核算科目解析自动化
解析原理： 业务维度 -> 核算编码 + 余额属性 -> 核算科目。事先配置好以上4者相互之间的映射关系，然后通过业务维度可找到对应的核损编码，再通过核算编码和余额属性的矩阵参数，即可获取到核算科目。

这种方案需要基于相关的业务场景，抽象出通用的业务维度，实现了一定程度的交易与核算相分离，业务交易层不用再关注核算科目。

但该方案本质上属于半自动化的会计分录解析，因为只是实现了分录科目的自动解析，在交易层生成交易流水时，仍需显式的传入记账方向（增加/减少），某些情况下还需要传入一些额外的余额属性，这与一般理解的业务交易流水还是有一定区别的。

该方案下，业务交易层与会计核算还是有一点耦合，只是耦合度相对方案一来说更弱一些；另外，该方案对辅助项的考虑有所缺失，基本不支持辅助项的灵活设置。

（4）内部账户体系
银行自身的帐务做为一类特殊的帐户，客户缺省为银行自身，在此称其为内部帐。内部帐的组成规则为便于记忆，会不同于客户帐号，一般为：机构号＋币种＋科目编号＋顺序号。分类如下：

◇标准户：系统核算需要统一开立的帐户，自动产生会计分录。例如现金帐号、应收利息、应付利息等需要自动记帐的帐户。

◇销帐类帐户：管理逐笔明细，支持部分销帐。例如应解汇款帐户。

◇清算帐户：用于结算不同金融机构之间债权、债务关系的帐户。允许透支，系统自动结息；透支可自动强制拆借；清算帐户为标准户。

◇过渡帐户：基于核算和管理需要设置。如：通存通兑过渡户，电子汇兑过渡户等。

◇凭证帐户：表外管理，分为在库户，在用户，待销毁户。重要空白凭证：记录张数，一张代表一元；有价单证：记载有价单证的余额。余额＝有价单证张数×有价单证面额。

◇手工帐户：手工管理，面向传票记帐。

6.记账核心实现方法和基本思路图

（1）总体设计思路

（2）会计分录接口

（3）总账处理模式

（4）总账汇总口径

（5）账务批量处理

7.浅谈会计分录解析-该章节来源公众号“萌大统领”

在4.2和5.3中我们介绍了两种生产会计分录的方式，分别是交易直接生产会计方式和核算科目解析自动化，接下来我们谈谈方案三，科目与金额解析自动化：

◇解析原理：
会计核算平台接收上游各个业务系统产生的通用交易流水，并根据会计场景的匹配条件，筛选出符合条件的会计场景，从而获取到该交易流水对应的会计分录配置，最后根据会计分录各配置项的取值规则，即可生成对应的会计分录。

◇关键词：通用交易流水、会计场景、匹配条件、会计分录配置

◇先对以上关键词做一个简要说明：
通用交易流水：指会计核算平台与上游的各个业务交易系统，按照约定的字段结构，生成的交易流水，一般来说，会尽量让上游生成的交易流水结构保持一致，即各业务交易系统都是按相同的字段结构生成交易流水，所以才称之为“通用交易流水”。

而会计核算平台原则上只处理该通用交易流水，这样可以使得会计核算平台的职责更为专注清晰，从而更为通用， 提升会计核算平台的扩展性。即使未来有新的业务交易系统需要接入，则该新系统只需要按照相同的字段结构生成通用交易流水即可，对于会计核算平台来说是完全透明的，无需改动，因为对于会计核算平台来说，接收处理该新系统的交易流水，与接收处理其他系统的交易流水，都是相同的流水结构。

当然，由于上游的业务交易系统众多， 一份通用交易流水结构可能不一定都能适用满足，当现有的这份通用交易流水字段套用在这不同上游系统中，若存在流水字段的复用率较低时，则要重新审视通用交易流水结构的设计。

比如通用交易流水共包含了10个字段，有2类系统用到的相同字段还不到3个，即字段复用率还不到30%时，此时再强制要求这2类系统使用同一份流水结构时，可能就与“通用”二字的初衷相背离了。

造成这种情况一般有2种原因：
1、对于通用交易流水的各个属性没有抽象好，这是属于设计缺陷。
2、这2类系统业务差异实在太大，共性的业务维度太少，比如只有一两个共性维度在这2类系统中才都存在，剩余维度都不相同。

◇应对办法：
针对前者，建议进一步梳理分析现有业务场景，识别出其共性维度。流水字段复用率不求百分百，但建议要达到70%以上。

针对后者，可能需要考虑新抽象出另一种通用交易流水结构，以满足这类业务交易的特点，也即需要2套通用交易流水结构，例如支付类的交易数据与业务类交易数据，在共性维度上是比较少的，此时可考虑设计2套通用流水结构：

1、通用业务交易流水，包括产品类型、产品码、交易资金类型等；
2、通用支付交易流水，包括转入账号、转出账号等；

当然，建议控制好通用交易流水的种类数目，不要设计太多种类的“通用交易流水”，这会导致系统的复杂度直线上升，尤其是对系统的可维护性和扩展性造成挑战。原则上建议尽量复用同一套流水结构。

◇会计场景
在会计核算平台中需配置好各个会计场景，一个会计场景主要由3部分构成：
1、基本信息，如场景码、场景名称等
2、匹配条件，即满足哪些条件，才算是属于本会计场景
3、会计分录，包括核算科目、借贷方向、分录金额、辅助项等

以上3部分，只有“匹配条件”与交易流水直接相关，即匹配条件的设计依赖于交易流水的设计。

下面对会计场景的关键点做进一步的说明：

（1）会计场景的匹配条件
匹配条件是连接 通用交易流水与会计分录的桥梁，因此会计场景的匹配条件的设计是会计分录解析中的关键。

由于会计核算平台只面向通用交易流水进行会计分录的解析，因此，匹配条件也只能来自于通用交易流水中。

事实上，这里的匹配条件与方案二中的“业务维度”是类似的思路，本质上都是对已知业务场景的通用业务属性的抽象，只不过方案二在业务维度的基础上，还抽象出了一个“业务编码”，使业务维度与余额属性得以解耦，使得即使在没有共性业务维度的场景下也能复用。当然方案二的“业务维度”，也可以进一步拆分为“业务维度串 + 业务事件”。但无论是如何拆解，匹配条件都必须源自通用交易流水。

（2）会计分录配置
只要确定了会计场景的匹配条件，则会计分录的配置就很简单了，剩下的就是会计分录各个配置项的取值规则的设计。

会计分录的主要配置项，或者说主要的构成有 核算科目、借贷反向、记账金额、辅助项 这4个属性。

其中，核算科目与借贷方向可直接按照财务会计同事确认的会计分录来配置，记账金额可以基于交易流水中的交易金额设置，辅助项则可结合科目配置与交易流水来设置。

（3）会计分录配置
可考虑为每条分录中的记账金额配置一个取值表达式，该取值表达式为固定值、操作符、数值3者的组合：

1、固定值：一般默认为交易流水中的交易金额，也可以为金额属性名；
2、操作符：如：加减乘除、括号、负号等；
3、数值：也可称为系数，是个自然数；

以上3者通过操作符自由组合，比如：
1、固定值1.50.1 或
2、(金额字段A-金额表字段B1.5)0.1

这里说下“固定值”的设计，一般是默认为通用交易流水中的交易金额，但如果通用交易流水中有多个金额属性字段时，可考虑使用金额属性名的方式来设置固定值，当然该方式会造成分录配置与通用交易流水部分属性的过于耦合，即需要在配置中绑定通用交易流水的部分属性名，采用这种方式需考虑维护性与扩展性上的成本。

（4）会计分录的辅助项设置
可基于会计科目配置的科目辅助项与通用交易流水的相关字段的矩阵来生成，可使用Java的反射来实现。该方式同样也需要在科目配置中耦合通用交易流水的部分属性。

（5）小结
以上第3点与第4点都提到需要在配置(分录配置、科目配置)中绑定通用交易流水的部分属性，虽然也可以再拆出一层配置来衔接两者，让两者解耦，但本质上依旧是相当于要在配置中绑定DB表字段名，一旦DB表结构有变化，则会影响到解析规则的稳定性。

当然了，一般来说，系统设计开发好后，核心实体模型一般可视为稳定的，所以核心的DB表的变化还是很少的(不考虑系统重构情况)，因此将核心实体的部分属性直接放在配置中也可接受。总之，是否应该采用这种方式见仁见智，还请各位小伙伴提出更好的思路。

（6）方案3总结
该方案从分录科目、借贷方向、记账金额、辅助项上都完全实现了彻底的配置化，配置化程度较高，尤其是对会计分录配置可统一管理，维护性较好；同时也使得上游业务交易系统与会计核算平的各自职责更为清晰单一，更加符合“低耦合高内聚”的设计原则。

该方案下大致可分为如下3步进行：

1.同步交易流水：即外围业务系统只需要按照约定的结构，生成对应的通用交易流水，并同步至会计核算平台
2.确定会计场景：即会计核算平台针对接收到的通用交易流水，与所配置的会计场景进行匹配筛选，获取到对应的会计分录配置
3.生成会计分录：在获取到分录配置后，根据会计分录各配置项的取值规则，即可生成会计分录。

但该方案对通用交易流水的抽象要求较高，因为接入的外围业务系统众多，可能需要抽象出多个通用交易流水结构（比如信贷核心产生的业务交易流水与 支付平台产生的 网银收付款流水 差异巨大，复用的业务属性很少，很难归类到同一种通用交易流水结构），且后续可能会不断有新的业务场景或者新系统接入。

在设计之初，要确定一个较为稳定的流水结构，难度会比较大，非常考验架构师或产品经理对目前自己所在公司的所有业务场景的熟悉理解程度以及抽象分析能力，因此，如何保证通用交易流水的通用性与扩展性是一个不小的挑战。

8.聊聊双边分录

系统中除了表外科目可以使用单边分录外，所有记帐都使用双边分录，达到每笔交易的自平衡。如果存在业务上的交易动作分离情况，将使用系统统一的机构挂帐户进行过渡处理，在进行过渡处理时，系统除了记录该账户的分录，还需记录柜员临时存欠登记簿，登记簿采用销账方式管理。

与丁种帐不同之处在于，该账户的销账允许部分销账，解决一借多贷或一贷多借情况，如果存在多借多贷情况，原则上必须自平衡或通过中间临时存欠账户管理，转换为上述两种情况。

机构挂帐户记账规则：
1、采用机构挂帐户进行处理。

2、在正常交易情况下，每日账户余额应为0，但在特殊情况下，如：机构网络中断情况，该账户有可能存在余额不为0的情况。

3、为避免虚增对机构挂帐户的发生额，规定对该账户的记账为转账、借贷标志只为借，也即交易时可能的分录为借方蓝字或借方红字。

4、在记录机构挂账户时需要同时进行柜员临时存欠登记簿的登记。

5、柜员在签退时，除了上缴尾箱、进行柜员轧帐外，还需检查柜员临时存欠登记簿，检查柜员有无关联交易未完成。

6、在交易进行抹帐处理时，必须首先检查该交易是否已被核销，若已被核销，首先对核销交易进行抹帐处理，或通过冲正交易完成对交易的调整。

9. 结束语

银行核心系统作为银行IT系统中的“心脏”系统，起着对整个银行的运行支撑的作用，而其中的账务处理，更是银行的血脉，融会贯通整个银行的核心系统。再回到我们最开始提到的三个关键词：产品、账户、科目，层层深入，每一层都有很多细节上的关注点，每深入一层都能有新的收获，每一层都值得深究，每一层都需要一整篇章来介绍。因为只有这样的深入分析和总结，业务才会更严谨，系统才会更完善。所以作为一个初步的梳理，可能还有更关键点有遗漏，欢迎各位小伙伴补充，一起探讨。

参考文献及注释：
1.《银行会计记账新应用设计》
2.《银行信息系统架构 》
3.《银行简明会计 》
4.《浅谈会计分录解析》—萌大统领
5.《银行核心系统之十四账务》
6.《银行会计账务核算基础》