万字：清结算体系，全局方案深度解析
本文分享了头部支付机构是如何做清结算的，在做和带领大家打通支付的底层处理原理，内核中的内核，分享给大家。
支付机构帮助交易平台代收代付交易款，那么就需要先从消费者发卡行把钱拿过来，然后再结算给交易平台；对于交易平台也是一样的道理，要帮店家卖东西，需要帮忙通过支付机构进行收款，从支付机构拿到钱以后要结算给自己的店家。
这是典型的2个不同的清结算场景，一个是支付机构的清结算，一个是交易平台的“清结算”，虽然交易平台没有资质，但其需要在信息层完成清结算业务。
浓缩抽象以后，清结算涉及的资金处理业务如下图，4大清结算环节、3套对账体系、3类在途资金处理：
要做清结算，就得把账算好，交易发生以后，要执行后续的清结算，那么必须完成全员参与者的算账，参与者之间都是什么关系，手续费是多少、分润是多少、应该怎么分账等等。
交易处理成功以后，将交易数据推送至清算中心，清算中心通过商户编号获取到该笔交易的对象模型，以及计费配置（包括费率、分成比例等），然后计算个对象的应入金额、分账金额、分润金额，调用入账服务进行入账，并将结果通知交易核心。
在算账过程中不同的交易会涉及到不同的对象关系，有没有代理商、有没有分账方等，对象关系不同涉及到的算账目标和任务不一样，例如需不需要算分账、需不需要算分润、分给谁等，因此在商户入网时构建该商户的关系模型，在实际算账过程中调用该模型关系，计算对应目标。
分账是商户将交易金额按照设定比例进行多方划分的过程，分润是渠道方将各参与方费率差部分划分给各方的过程，例如给代理商划分“商户手续费-自己手续费”的那一部分手续费差。
接下来，重头戏，深度解析支付机构的清结算体系如何落地。
当然，也非常具有挑战性，可以先收藏慢慢钻研：
机构的业务主要是帮助商户收款付款的收付退业务，为商户结算的打款业务，从中获取商户手续费收入，并支付通道成本，之间形成的价差就是机构的主要利润来源；当然直联时代还有备付金利息，现在没有了。
同时，支付机构作为一家企业还有自有资金，例如注册资本金，后续的利息收入等等，企业自有资金的业务涉及到向商户收取手续费、向通道支付通道成本、员工的工资发放、费用报销、股东分红、缴存注册资本金等，这部分属于自有资金，不过商户手续费和通道成本与支付业务紧密联系在这样的业务背景下就产生了支付机构的核算体系，涉及到支付业务的渠道清算、商户结算、备付金核算、自有资金的会计核算等等。
本文将从交易出发，全链路介绍支付机构的全局核算业务，涉及核算原理、系统链路、数据关系、核算关系、备付金账套设计等。
一、五大业务体系
要先搞明白支付机构的核算业务，要先搞明白支付机构的业务系统和关系。
支付机构开展业务的前提是有完整的业务系统体系，这些业务核心其他文章都介绍过，这里就不做更详细的阐述了，可以先看这张图：
从图中可以看出，支付机构的业务系统主要可以归结为五大体系，支付交易体系、清结算体系、对账体系、账务体系、会计核算体系，其中：
（1）交易支付体系
就是交易核心和支付核心，完成收款、退款、付款等支付业务。可以说交易链接了平台和商户，而支付链接了平台和渠道，交易和支付的链接就是商户和渠道的打通，这也就为什么说三方支付机构是“支付中介”了。
（2）清结算体系
清结算体系就是把收到钱从渠道要过来，然后结算给我们的商户，前者是渠道清算，后者是商户结算，主要涉及到清算体系和结算体系。
（3）对账体系
主要完成机构与渠道基于清算文件的交易对账，和基于渠道结算账单的资金对账，对平平台和渠道的账务，并生成差错在途账务，例如平台或渠道的交易单边账，以及渠道的长短款应收未收或应付未付资金差异账务。
（4）账务体系
交易核心、支付核心、清结算核心驱动账务记账，完成账务明细的记录，以及客户账户余额的更新，记录了收付退、结算等业务的账务明细，以及用户和商户的各类虚拟账户，如支付账户、结算账户、手续费账户、营销账户等等。
（5）会计核算体系
支付机构的会计核算主要包括两部分，一部分是备付金核算，另一部分是自有资金核算，这两者之间存在联系，如商户手续费收入、通道成本这部分资金要从备付金结转至自有资金，因此两套账务之间发生了联系。
二、全局三套账务
基于上述的支付机构业务介绍，结合资金属性来看，可以将支付机构的资金分成三大类，分别是客户平台虚拟资金账套、存储在托管行的备付金清结算业务账套、平台自有资金会计账套。
2.1 三套账
上述的三类资金分别管理在三套账务中，客户账务、备付金账务、自有资金账务。
（1）客户资金账务
平台帮助商户收款，最终结算给商户，付款至商户的银行账户，平台内部也要为商户开通各类虚拟账户，手续费账户、营销账户、结算账户等等，这部分账务一般管理在账务核心中，当然在会计核算中心也应该记录这部分应收应付客户账款。
（2）备付金账务
支付机构帮助商户代收代付款项，收到的钱目前都集中存管在央行的备付金账户中，断直连之前备付金存放在各个签约银行，缴存一部分到央行；断直连以后全部集中到了央行，也就是央行备付金集中存管账户，在平台侧这部分资金通过备付金账套管理，一般由结算部负责。
（3）自有资金账务
同时支付机构也有自有对公账户，也就是存储着自有资金，例如商户手续费收入、通道成本、银行利息收入等，一般管理在会计核算系统，由财务部管理
2.2 账务全局
整个核算体系有3套账务，客户账务（业务账），备付金会计核算账务，平台自有资金会计核算账务，其中客户账务可以在账务核心管理，而备付金账务和平台自有账务在会计核算系统管理。
当然，如果一套账全搞定，也没什么问题。
（1）实体账户
最上层是涉及到的主要实体账户，以及基于支付机构收付业务的资金流动，用户下单付款时，资金从用户银行账户流向机构备付金账户，支付机构结算给商户时，资金从银行备付金存款流向商户的银行账户，这是全局主要的资金流。
（2）平台虚拟户
在平台账务层完成上述整个链路的账务登记，从用户下单到商户结算完成，涉及到渠道待清算、商户待结算、商户结算户以及其他类账户，后面我们会介绍具体的账套设计和账务处理。
（3）会计核算账套
最底部是2套余额，2套账，其中最左侧的虚拟账户即账务核心的各类账户余额，最右侧的是来自渠道存款账户的账单余额，中间就是会计核算系统，有2个账套：一个是备付金核算账套，如备付金存款、渠道清算往来、应付客户款等；另一个是自有资金核算账套，如银行存款、成本、收入、利润等。
三、全局四段数据
全局对账涉及到了三大对账业务，我们主要介绍交易对账和资金对账。
交易对账完成渠道清算文件和平台支付记录的核对，该业务中会产生渠道应收应付数据以及单边差错数据；资金对账业务会产生渠道的实收实付数据和长短款资金差异数据，这些数据将会被推送至会计核算中心形成相应的凭证。
3.1 四段数据
上图中最上层涉及到了四段数据即“账务数据、支付数据、清算数据、结算数据”，这是我们对账的核心数据，以及他们之间形成的相互核对的关系，如，这部分就是我们做对账系统的基础原理和模型。
平台支付数据和渠道清算数据核对，这部分属于交易对账，在对账核心完成，对完账以后，平台支付数据生成2段平台记账数据，渠道清算数据生成3段银行已核对银行应收应付数据。
渠道清算数据和渠道结算数据核对，这部分属于资金对账，在财务处理中心完成，这部分核对的实现比较复杂，另外写文章单独介绍，资金核对完以后生成银行4段实收实付数据：
- 100x：是账务数据
- 200x：是平台支付记录数据，如2001是平台记录收款、2002是平台记录退款；2003是平台记录打款，2004是平台记录打款退回等
- 300x：是银行清算数据，如3001是银行收款清算文件数据、3002是银行退款清算文件数据；3003是银行打款清算文件数据，3004是银行打款退回清算文件数据
- 400x：是银行结算数据
以上这些数据，将推动会计分录的生成，后面会介绍业务数据。
如何推动会计凭证的生成？
3.2 三个在途
中间有三个在途，即是未对平的所产生的各段的差异数据。
- 客户在途是支付记录和账务核心产生的差异，即应该给客户入账而没入的账；
- 支付在途也就是交易对账产生的单边账，平台单边或者银行单边；
- 资金在途就是长短款以及其他差异账，可以理解为各类挂账。
后面会详细介绍这3个在途的生成。
四、系统流转与数据转换
各类数据是如何进入会计核算系统的，依靠会计对接系统，各类数据获取关系如下图所示：
4.1 数据来源
平台数据可以直接推送至数据转换系统，而渠道的清算数据、结算数据、以及核对的差异数据可以由对账系统进行推送至数据转换系统。
- 账务数据：平台记录的支付数据，客户账数据，也就是200x
- 清算数据：银行清算文件数据，也就是300x
- 差错/差错处理数据：可以继续做为300x结算数据：银行结算账单数据，也就是400x
- 长短款/核销数据：可以继续做为400x
最后，需要会计前置系统统一下载相应数据，并按照设定好的规则进行数据的校验和汇总，形成预制凭证，推送至会计核算系统，不同凭证推送至不同的账套，如渠道清算类、备付金存款类推送至备付金核算账套中。
4.2 数据流转
上面我们把业务、账务、核算关系都讲清楚了，那么从系统层面来看，各类系统之间会形成什么样的数据流转关系，业务数据、渠道数据、差异数据是如何进入最终的核算系统的，如下图所示：
（1）要流转的数据
平台的交易数据，包括收款、退款、付款数据等推动账务核心完成客户账的记录。
交易数据和银行清算数据，进入对账中心进行交易对账处理，生成的一对平的平台支付记录、渠道清算记录，以及未对平的平台单边数据和渠道单边数据，未对平数据即“支付在途数据”，对支付在途数据进行差错处理以后，会生成差错处理数据，上述的一对平数据、未对平的支付在途数据、差错处理数据将推送至数据转换中心，前往下一步，直至到会计核算中心生成在途凭证和渠道应收应付凭证。
从银行获取到结算单，与渠道应收应付数据进行资金对账，得到长短款数据，长短款即资金在途数据；渠道结算数据推送至会计中心生成实收实付凭证，长短款生成资金在途凭证。
对长短款进行核销以后生成核销凭证，已抹平资金的在途挂账。
在会计核心，手续费收入、利息收入在期末将结转至相应财务账套，实现备付金账务中涉及到的自有资金的结转。
（2）清算数据绑定渠道实体账户
一个渠道账户可能会有多条通道进行入账，例如网联渠道全部清算入账的央行集中存管户，在直联时代也存在这样的情况。
在计费中心存在一个划付管理模块，可以实现清算数据与收单账户的关系绑定，也就是这份清算数据清算到了那个账户中。下图是计费中心产品架构：
划付规则设定的是一个接口的支付成本、交易本金与渠道的清算规则，涉及从哪个收单账户出、什么时候支付、如何支付等信息，包含交易本金的划付以及手续费成本的划付两部分。
如下图所示：
这样，边实现了对账中心的清算往来数据，在向后流转到财务处理系统过程中，如何绑定上收单银行账户，这是后面要实现“渠道已核银行应收/应付”科目入账的前提条件。
清算数据—收单银行账户—结算日期
五、支付机构科目设计
为了简单起见，我将所有主要科目放到一张图中，并且用什么数据进行记账，每一类数据操作哪些账户，记什么方向，以收款业务为范例进行，全部标记在了图中，付款业务，退款业务原理一样，只不过涉及到的科目不同。
5.1 账户科目设置
科目设置原理就是以下5套科目：虚拟户、三个过渡户、银行存款。
图中的粉色部分就是该收款和付款备付金核算的全链路涉及到的科目
- 商户结算账户：存储商户已结算账户余额
- 待结算商户-收款/付款：存储待结算商户余额
- 渠道清算往来-收款/付款：记录渠道待清算往来账务
- 已核对应收银行-收款/付款：记录已核对应收银行账户
- 银行存款-备付金/自有资金：记录银行存款账户余额
科目编号设置，不是重点，可以采用三层结构“xxxx.xx.xx”，例如“22030.X.0Y预收账款-客户备付金-A商户”，这部分不做详细介绍，后续可以单独介绍支付机构账套设计。
六、账务处理要素及原理
那么有了上述科目以后，要想搞清楚账务处理，需要搞明白账务处理的要素原理和基础原理。
6.1 账务处理要素
账务处理的要素就是你要做账务处理，需要关注那几个维度的信息，主要是5个维度：什么业务、什么时候记、用什么数据记、记账规则是什么。
- 什么业务：收款/退款，打款/打款退回，差错即差错处理，长短款及核销，客户账务调整，结算结转财务等等
- 什么时候记：支付成功，打款成功，退款成功，渠道清算对账成功，资金对账成功，账务记账成功等等
- 用什么数据记：支付数据、账务数据、清算数据、结算数据、差错数据、长短款核销数据等
- 记账规则是什么：包括的借贷方向以及涉及到的账户，如渠道待清算、商户待结算、应核应收渠道，银行存款，商户结算账户等
6.2 账务处理原理
整个账务处理涉及到了4个环节，5套账户，以收款为例，付款和退款类似，如下图
这里面要特别关注差错类的记账，包括交易类差错、资金处理类差错、客户调账了差错。
6.3 三大在途
当过渡户存在余额时，则意味着存在在途，主要有三大在途：客户在途、支付在途、资金在途，
在途可以理解为各类挂账，各类差错处理的记账就是抹平挂账。
（1）支付在途
渠道待清算往来账户余额及是支付在途，清算完成以后余额应该为0，否则平台与渠道清算存在差异。
从原理上看，该账户的余额上是平台支付记录和渠道清算记录的差额，也就是该账户的期末余额就是我们所说的“支付在途”，那么一个清算周期，该账户的余额会存在三种情况：
- 余额在借方：说明平台支付记录多，那么总体来说属于平台挂账
- 余额在贷方：说明银行清算记录多，那么总体来说属于渠道挂账
- 余额为0：说明平台记录和渠道清算数据一致
当出现余额不为零时，则意味着存在平台单边或者银行单边，那么就需要进行相应的差错处理。
如果是银行单边，则要不进行平台补单，要不进行银行退款，或者平台确认收入，这部分处理也会操作该账户。
最后会举例说明在途的账务的产生和差错记账的平账。
（2）资金在途
已核应收银行的账户余额为长短款数据，资金对账完成后，该科目余额应该为0，如果不为0怎存在长短款，具体如下图，余额在借方则存在短款，银行少结钱了，如果余额在贷方，则存在长款，银行多结钱了。
（3）客户在途
待结算商户科目余额意味着没有完全结算，如果余额在借方则说明多结给商户了，如果余额在贷方说明少结给商户了，少结的情况下，可以通过调增客户账户进行补入账，多结的情况下可以通过平台补单进行平账。
七、账务处理规则
先看整个全局核算是是如何做账务处理的规则。
整个收款账务处理涉及到4个环节，3个差错：支付交易环节、渠道清算核算环节、商户结算环节、渠道结算核算环节、客户差错、交易差错、资金差错。
（1）支付交易环节
即用户进行支付，生成平台支付记录，提交渠道支付完成的过程，该过程要完成“渠道待清算”和“商户待结算”的记账。
（2）渠道清算环节
即对账中心获取渠道清算文件与平台交易记录进行核对，该过程会完成“渠道待清算”与“应收银行-渠道已核对”的记账。
（3）交易差错处理
是在与渠道清算过程中清算往来户存在支付在途挂账，需要进行差错处理平账。
（4）商户结算环节
是账务记账完成，该过程要进行“商户待结算”和“商户结算账户（应付客户备付金）”的记账。
（5）商户账差错处理
就是有些交易没有入账成功，导致多结或者少结给客户资金，需要进行调账处理。
（6）渠道结算环节
即资金对账系统获取到渠道结算单，完成资金核对，完成“应收银行-渠道已核对”和“银行存款-备付金”的记账。
（7）长短款核销处理
即在资金对账环节产生了长短款，导致“已核应收/应付银行科目存在余额”，需要通过长短款核销进行平账处理。
八、备付金核算示例
上面基本就讲清楚了备付金核算的整个体系，最后我们根据一个实际收款例子加深对上述核算体系的理解。
假如：平台收了2笔钱，都是10元，渠道T+1结算，给商户也是T+1结算，然后各环节情况如下：
交易对账存在差错：T+1拿到清算文件以后经过对账发现，平台支付记录只成功了1笔，而渠道有2笔清算交易。
差错处理：进行了平台补单操作。
资金对账：假设，渠道结算文件只有1笔，经排查是渠道文件丢失了数据，银行账户完成了资金入账，对短款进行核销处理。
商户实际结算：为0，成功的一笔交易记账失败了。
商户补入账：基于成功的交易执行补入账，补入1笔成功的交易和一笔平台补单交易。
完成全部记账
8.1 支付交易记账
用户支付了2笔，各10元，成功了1笔，另一笔支付处理中，支付核心生成支付数据。
交易驱动账务进行记账，以该数据为记账数据，借记渠道清算往来，贷记待结算商户。
8.2 渠道清算环节
对账中心获取到渠道清算文件以后，与平台记录进行核对，渠道清算成功了2笔。
其中清算文件数据做为渠道清算记账数据，借记“已核对应收银行”，贷记“渠道清算往来”。
可以看出来，清算完成以后，渠道清算往来-收款存在贷方余额，也就是交易对账的渠道单边造成的。
8.3交易差错处理
经排查，是平台的支付系统状态更新异常，在对账中心进行了“平台补单”差错处理。
补单成功的支付记录将驱动账务再次记账。
到此为止，全部账户的记账情况如下：
从图中可以看出来，此时待结算商户20元，与渠道清算成功，应收渠道20元，商户结算户和银行存款户还没有余额。
8.4 商户结算环节
按照案例，支付成功的一笔交易是没有完成账务记账的，而次日对账补单成功的交易假设完成了客户记账，那么也只有补单成功的完成了向商户的结算。
基于补单成功的交易，推动账务完成了记账，在T+1执行结算以后，完成了向商户的结算。
可以看到待结算商户-收款，存在贷方余额，即应结商户的在途资金，这是因为存在交易未入账的情况。
8.5 客户账调账、交易补入账
触发交易发起补入账操作，补入未入账的交易记录，记录如下，状态是未结算。
未结算账务重新执行结算，完成商户结算入账，至此待结商户余额为0，完成客户在途挂账的抹平，也完成了向商户的结算。
到这里以后各账户的记账情况如下：
8.6 渠道结算环节
资金对账模块获取到银行结算账单以后，进行资金对账，渠道结算文件记录只有一笔，因此在资金对账时出现了短款，如下：
基于银行结算单进行记账，实收10元，记账如下：
可以看出来，渠道资金对账以后，已核应收银行存在借方余额，即有短款挂账。
8.7 长短款核销
经人工排查，收单账户已经完成了资金入账，是结算文件数据丢失，因此对短款进行“银行补入账”的核销，数据如下：
该短款核销，执行核销凭证的入账，记账如下：
到这里就完成了全部的收款清结算了。此时，全部账户的记账情况如下：
九、结算结转财务
备付金账务中涉及到的手续费收入、备付金利息等损益类账务，需要在期末结转给财务，这部分就不详细介绍了。
其中结转依赖一个过渡科目：应付账款-内部自有-手续费/利息大家可以自行琢磨一下。
以上就是支付机构清结算实现的全部内容，当然同样适用于普通的交易平台搭建自己的清结算体系。
总结起来就是“1张图、2条线、3在途、4段数、5账户、7环节”。
1张图
就是这样一张极简图，基本阐述了整个清结算所涉及的全量业务：
2条线
就是收支两条线，在做清结算账务处理时，收款和付款独立起来看：
3在途
在整个核算过程，3组核对所产生的3大在途资金，即用户在途、支付在途、资金在途。
4段数
即账务数据、支付数据、渠道清算数据、渠道结数据。
5账户
即实现清结算全链路账务处理所设置的5套账户，分别是商户结算户、待结算户、清算往来户、已核应收付银行户、银行存款。
7环节
即整个清结算涉及到7大环节的账务处理，分别是支付交易环节、渠道清算环节、交易差错环节、商户结算环节、商户差错环节、渠道结算环节、长短款差错环节。
