支付完成以后进行履约，履约完成以后就需要清算各方利益并最终进行结算，清结算体系与支付体系并行是支付范畴另一个非常庞大的体系。

一、清算系统设计

我们都知道一笔支付最终都是要进行清算的，业务一般都会有众多参与者或者利益方，事做完以后，算清楚相关的利益关系，完成利益分配。今天我们就来讲一讲这个算清楚账完成利益分配的系统“清算系统”。

1. 清算系统概述

我们先看下清算的定义以及银联的清算的含义。

《支付清算组织管理办法》规定：

支付清算：支付指令的交换和计算
支付指令：参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令
支付指令的交换：提供专用的支付指令传输路径，用于支付指令的接收、清分和发送
支付指令的计算：对支付指令进行汇总和轧差
参与者：接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构

银联的支付清算包括淸分和资金划拨两个环节：

1）淸分

对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？

2）资金划拨

通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。

从上面的定义可以看出，清算最核心的其实就是清分这个过程，也就是算清楚各方应收应付的这个过程。今天我们重点讲的就是这个过程，以及记账的过程。而承载这个过程的系统，我们称为清算系统。

2. 清算系统的位置

我们在一张支付小票这篇文章里提出过“311架构模型”，在这里我们可以看到清算系统的位置，在交易系统之后；这样的话我们可以理解为，清算系统在订单，交易，支付之后。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等，如图1所示：

图1 结算系统所处位置

3. 清算业务架构

清算系统整个结构由以下几部分组成。之前在O2O清结算实战中我们详细讲过一次，主要包括上游请求系统、商家模型子系统、计算核心、计费子系统、账务前置模块。后面会详细讲解每一个模块的职能以及设计关键点，如图2所示：

图2 清算系统架构

4. 上游请求系统

简而言之，有清分需求的业务系统都可以称为清算系统的上游，向清算系统发起清算请求，比如订单、交易、支付。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等。

5. 对象模型

对象模型就是你算出来的应收应付的债权对象，以及对象之间的关系。比如外卖平台的一个订单，可能会涉及到众多的利益对象，比如外卖平台要抽佣，提供饭餐的商家要餐费，骑士小哥要快递服务费，骑士小哥的保险费，这些需要完成订单的分账；而外卖平台还可能有很多渠道或者合伙人，需要给渠道和合伙人进行分润等。

分账就是将一款项分成多份给多方；而分润其实就是平台将计算所得例如分给多个分润方。

一个公司的业务可能不同的业务会有不同的对象模型，比如单一的商家，有合伙人的商家，有渠道商的商家，还有服务商平台商的商家。所以每一类订单会有不同的商户模型，进行计算时，计算的维度会有不同。

那么我们抽象出常见的集中对象关系模型，如图3所示：

图3 常见对象关系模型

在商家注册时，或者入驻时，在对象模型子系统生成他的对象模型，以及模型对应的对象关系。比如你通过了好友的邀请注册了一个网站，那么好友就成了你的合伙人了，那么你的对象模型就是“合伙人-用户模型”，当你有了消费时，会去计算给你好友作为你的合伙人的分成。

6. 计费规则子系统

计费子系统核心职能就是维护计费规则，基于算账服务的请求返回计费模式以及参数值。比如单商家模型需要计算平台的信息服务费，那么通过基础参数请求计费子系统获得信息服务费的计费模式（按比例，固定金额，按单笔阶梯还是累计阶梯），拿到计费规则以后便可以计算出信息服务费数值。

所有最核心的就是要基于业务特点抽象出计费规则的模型。

一个是匹配的模式，就是你要用什么方法去到规则池里找到规则，比如条件法，就是一组参数去匹配到规则，这个也是最常用的，那么你就需要为不同的计费类型设置不同的匹配条件组，比如例子中通过“类目+城市”去找规则，这样的话再匹配条件里可以设置灵活的条件组。

然后就是规则的设置，一条规则应该有哪些维度组成，这样我们将每一个费用的计算认为是一个函数。

分成费用=f(x)=g{ j(a) , k(b,c) , l[y,z, p(e,r,u) ] }

那你规则就需要能够使这个符合函数得到f(x)的值。

分成模式：固定金额，固定比例，按单笔阶梯，按累计阶梯，递减等。

下面是在选择了模式以后要配置的规则参数：

频率：就是在递减时，递减的频率是按月还是按日还是按年
首月：我们设定一个首月的数值，也就是递减的期初值
递减金额：每次减多少
最低金额：减到多少就固定下来了

看一个计费规则配置的示例，如图4所示：

图4 合伙人分成计费规则配置

基于上面的一个配置器，我们可以配置出非常多的规则，那么基于不同的费用的配置模板我们就可以配置出无穷个计费的规则了，如图5所示：

如图5 合伙人分成计费规则列表

7. 算账服务

一个清算请求来了以后，不同的清算类型我们的计算任务是不一样，计算的模式也是不一样的，计算的结果也会不一样。所以算账模型我们同样需要设计抽象出来，比如首先是通过清算类型确定清算的模板，基于清算模板我们就知道了应该计算哪些费用以及做什么任务，然后逐个去计算每一个费用即可，对于整个计算流程里如果需要做一些处理的进行处理即可。

关于分润和分账，基于不同的对象模型，我们可以知道哪些是要算分润，哪些是要算分账，我们用下面的这个代理商，商家，分账方来看，如图6所示：

图6 分账与分润

8. 清分结果

我们在一张小票看透支付清结算架构中讲了清分计费的结果是什么样的了，比如下面，我们算出来这笔外卖单的相关应收应付以及所属主体对象，如表1所示：

表1 清分明细

这是清分明细，那么是不是需要汇总轧差，这个看业务需要，一般情况下我们可以选择单笔入账的，也就是算出一笔入一笔。

9. 记账服务

清分完成以后，我们就需要做入账处理了，这个我们在账户系统设计从入门到精通讲得比较清楚，大家可以复习一下。

二、结算系统设计

每个月公司要给员工结算工资：陈老师在京东开了一个店铺，定期京东需要给我结算货款；你请了一个保姆，每个月要给阿姨结算服务费….等等，结算场景我们并不陌生，但是怎么设计一个结算系统，你知道么！今天我们就好好聊一聊（最后有原型页面）。

1. 什么是结算

定义：将平台的代收款支付给平台商家的资金转移过程。

展开来讲就是现在有很多平台比如滴滴，货拉拉，京东商城，作为一个服务平台上面有很多商家（我们将滴滴司机也成为商家），用户在平台购买商品或者服务，服务完成后，平台需要按照协议约定将服务款抽取一定费用后的剩余部分结算到商家的平台结算账户中或者直接付款支商家银行账户的资金划转过程。

结算名词解释，如表2所示：

转存失败重新上传取消

表2 结算常见名词解释

2. 结算的模式

结算我们常见的有2种模式：

结算到银行卡：直接将结算款项直接付款到商家签约的结算银行卡账户中
结算到虚拟户：将虚拟结算款结算入账到商家在平台开通的结算户中，后续可以商家自主提现

像微信支付宝在开通支付产品时都会获得一个商户号，每个商户号会有一套账户用于收款和结算，并且签约绑定一张结算卡，次日会将上一日的结算款先结算之虚拟户在一笔结算之绑定的对公户。当然结算到对公户的比例可以自己设定，可以全额结算也可以部分结算，将一部分资金留在虚拟户里，用于次日的退款或者其他付款需求。

3. 关于结算产品

结算产品其实就是指支撑不同类型结算模式的结算能力：

T1结算：工作日结算，当天的服务款，在下一个工作日结算
D1结算：日然日结算，当天的服务款，在下一个自然日结算
D0结算：日然日结算，当天的服务款，在当天结算
S0结算：交易完成后即可结算，按照订单号逐笔进行结算，像借贷的还款，一般逐笔

结算功能，用户可以选择系统自动结算，也可以选自主发起结算。

自动：系统按照结算协议，在约定时间自动将服务款支付给结算卡
自助：商家需要自主的在服务平台完成可结算周期内的款项的结算申请

结算签约，商家入驻平台时会进行资质认证以及签约一款适合自己的结算产品。

4. 结算场景

上面还是比较抽象，我们列举几个容易理解的结算场景：

支付公司将收单款结算给商户
电商平台将交易款结算给商家
滴滴平台将打车钱结算给司机
电影院将票房结算给各方
公司将工资结算给员工

所以，简而言之，结算就是将属于别人的钱给到别人。

5. 如何评价结算产品的好坏

评价结算系统的好和坏一个是站在公司角度，另一个是站在用户角度。

站在公司角度：准确率高，资金安全，能容用户满意，投诉少
站在用户角度：支持银行多，服务好就是后台好用，到账快，成本低

6. 结算的业务架构

业务完成后，到了结算节点，账务系统按照结算周期将已经入账待结算数据打包后推送给结算系统，结算系统对结算数据进行处理加工后生成结算记录和结算明细；然后请求账务系统进行结算打款，账务系统请求账户中心扣款之后调用打款中心进行打款申请，如图7所示：

转存失败重新上传取消

图7结算的业务流程

7. 结算系统系统架构

结算系统的产品架构如图8所示：

转存失败重新上传取消

图8 结算系统的产品架构

对于不同结算产品，需要定时任务的管理去推动结算的进行。

商户后台：商家自主发起结算，查询结算信息，变更信息的后台
运营后台：公司内部运营的操作台
账务系统：为结算系统提供结算数据，接受打款申请以及反馈出款通知
垫资系统：针对D0,S0的结算请求申请垫资的受理方
计费系统：计算结算时商家需要支付的费用，比如一笔2元
商家系统：用于查询商家的相关结算需要的信息

8. 结算系统业务实体结构

从更小的颗粒度审视结算各信息记录之间的关系以及每个信息单元所记录的内容，便于对结算系统有个更精细的认知。

结算请求：一次同时结算所有可以结算的商家，记录多少个商家
结算记录：一个商家生成一条结算记录，本次结算多少钱，以及打款状态
结算明细：按照商家结算的支付产品类型记录每个支付产品结算多少笔，多少钱
结算信息：记录这个商家签约了什么结算产品，结算的时间管理等

比如某一日一共结算了100个商家（一次结算请求），其中A商家结算了1000块钱（一条结算记录），其中A商家的快捷支付结算了100笔500块钱，网关支付结算了600笔500块钱（结算明细），如图9所示：

转存失败重新上传取消

图9 结算单据之间的关系

9. 业务流程

结算业务的处理流程如图10所示：

转存失败重新上传取消

图10 结算业务处理流程

10. 系统交互时序图

结算系统处理时序如图11所示：

转存失败重新上传取消

图11 结算系统处理时序图

11. 详细流程图

每个处理阶段的详细逻辑流程图，篇幅有限，为了更加易读，简化了流程图，仅绘制了核心的节点，如果有不明白的地方可以加入产品学习群，深度交流。

数据准备过程如图12所示：

转存失败重新上传取消

图12 结算过程中的数据准备

结算处理过程如图13所示（以T1结算为例）：

转存失败重新上传取消

图13 结算处理

打款处理如图14所示：

转存失败重新上传取消

图14 打款处理

结算状态流转如图15所示：

转存失败重新上传取消

图15 结算状态流转

12. 结算账单

平台按照结算明细，以不同的维度生成结算账单，商户可以在后台下载结算账单，或者通过接口获取账单，这个大家可以调研一下微信或者支付宝后台，这里不再详述。

拓展阅读：工资结算可以这么做

现在很多平台都有个人商家或者说是服务者，就像外卖平台的骑手，货运平台的司机，家政平台的阿姨，这些个人劳动者在平台提供服务，平台进行收入的结算。虽然有很多灵活就业平台都有成熟的解决方案，或是使用标准的清结算平台完成这部分的服务收入结算，这篇文章将介绍可能不常见的设计方法，但是里面的一些设计思路可能会有一些启发。

1. 结算信息

我们假定为一个货运平台设计司机的收入结算，每个司机按照不同的周期进行结算，特级司机按日进行结算，高级司机按周进行结算，普通司机按月进行结算；结算方式是按照约定周期主动打款给司机签约的银行卡当中，所以我们要有一个基础的结算信息数据，如表3所示：

表3 结算对象信息管理

2. 结算单

该结算单跟我们之前讲的账户有点区别，这个单据更像一个工资条，但是其中有些字段具备账户的部分属性，该结算单的信息更加多，而且每个司机每个结算周期会创建一个本周期的结算单据。该结算单据包含一些统计类的字段，用于记录一些金额，就像我们工资条中的公积金，养老保险，税，应付工资等，例如我们筛选出王五近半年结算单据，如表4所示：

表4 结算单记录

实发收入不能为负，但是实际情况肯定有场景出现本期纯负收入的场景，为了保证这个字段不为负，我们设定另外2个字段，一个是本期欠款，来记录本期总实发的负额部分；上期欠款则是结转上期的欠款金额，本期的上期欠款等于上期的“本期欠款+上期欠款”。

3. 结算信息创建

司机签约认证以后由司机crm来申请创建该司机的结算账户，也就是我们上面的结算信息，并且为其创建第一条结算单据。

4. 结算单据的生成

按照司机的结算周期定期的创建本周期的结算单据，并且实时的根据清分结果更新结算单据的相关数据清分司机在完成一单收入时，由订单系统推送订单到清分系统，完成该单据相应费用的计算，比如本单平台佣金，税等，然后计算本单的司机所得，基于计算结果去更新该司机的结算单据；奖金和罚款同理。

5. 期末账务处理

因为借宿那单据中有几个字段需要在本期完结以后才能进行统一处理，比如欠款的处理。所以在一个结算周期结束的第二天凌晨，打款之前，我们要完成期末账务的处理，比如汇总生成本期欠款，汇总生成本期实发等等。

6.打款

到了结算周期结束的第二天凌晨基于结算单据的“实发收入”生成打款订单，请求打款系统进行打款。

7. 学习会越来越有效率

我想前面我们有大量的介绍清结算账户等相关的内容，大家现在应该很容易理解任何一种结算手段和方式，学习肯定是越来越轻松，接收内容的效率越来越高。

就像我最近看很多支付类书籍，速度越来越快，因为你单单看到标题，然后扫描一下正文中的关键字眼基本就知道他在讲什么，已经了解的东西，就一扫而过，快速地扫描一下，大脑提取一次同类知识点，补充书中的新内容即可。所以说学习的越多，后面的升级效率越快……量变终会引起质变。

最舒服的工作，可能不是工作本身，而是你对工作的把控力；如果任何一次需求、任何一次沟通，只要对方说出某几个关键字，你已经有了最好的答案，我想这就是最舒服的工作，因为你从不会因为“难度”而痛苦，加油，让自己面对的一切都变得简单，即使在别人眼里，它是巨大的挑战！

拓展阅读2：“三层式”清结算中台

我们都知道清结算，因为课堂刚刚完结了这个专栏的20节课；我想我们很多人也都知道中台，因为这个概念活了很长时间。那么什么是“清结算中台”呢？我想也很容易理解，无非就是用“中台的理念”建设“清结算体系”。

那这样的话，要想做好中台，首先就要理解什么是中台，中台的核心是什么？清结算的相关系统如何向中台靠拢，做成中台的样子…..这是这篇文章要介绍的内容。

可以说我们在创造一种事物或者系统建设的理念和方法，那么抽取这个理念和方法首先就需要挖掘其最核心最突出的特征。清结算业务或者相关系统本身跟商品系统、购物车、订单、服务履约等系统，除了功能模块不同以外本质没有实质性差别，都是基于某项业务将功能集成了一个系统。

所以说在系统本身没有最突出的特征，最突出的特征就必然从“中台”这个系统建设理念上去挖掘。

什么是中台呢，中台又有什么最核心的特征？我们常说的抽象通用能力，规避重复建设等这些是中台的目的。而我们分析中台的核心特征可以概括为这样一个模型：三层式。

如果将清结算体系规范成“三层式”去建设，那么就是“清结算中台”，这三层如图25所示：

转存失败重新上传取消

图25三层式结算清结算中台架构

1）业务层

清结算中台要关注业务场景，为业务场景提供系统服务，多业务线、复杂的业务场景中的清结算业务是清结算中台服务的对象，所以说清结算不再是独立的一个个后台系统，而是一个服务集群，我们要基于“服务”去建设系统。

2）服务层

服务层是基于服务对象抽象出来的服务单元，就像我们去银行办事，大厅的接待员会接待你。传统上来说她是个接待员，但是站在服务的角度，她提供了“接待服务”，虽然她还是她，虽然接待还是接待，但是已经大不同。基于接待服务去思考，我们会更关注服务本身，而不是她这个接待员。

所以清结算中台，我们不再关注清结算体系内单独的系统本身，而是去关注这套系统能向外提供的服务，以服务论影响。既然是“服务层”，那么我们就需要去抽象这些服务，定义这些服务，以及设计这些服务的准入标准、流程、规范，以及这些服务的提供方式，API，MQ，SQL还是……

3）基础层

这一侧就如“接待员”一样，是我们对外提供服务的能力基础，所以我们可以称之为“能力基础层”，这一层是以系统能力为建设对象，比如清算计费的能力、账务记录的能力、账户冻结的能力。这些能力简单的说就是我们曾经的叫“功能”的另一个说法，为了显得我们是一个专业的中台，我们对外宣称，我们这不是简单的功能，而是能力集群。

这三层之间的关系，我们不如用一段描述来定义。公司的业务复杂，为了规避重复建设，搭建通用的系统，可以多业务线复用，未来新业务可以复用；我们基于业务场景进行抽象，抽象出原子化的服务单元；这些服务单元需要一系列的系统功能来支撑，而这些系统功能抽象出通用的系统服务能力，将这些服务能力进行封装，构建成了一个能力集群，所以说清结算中台的未来要关注三个东西，如图26所示：