我们知道，每一笔支付最终都要进行结算，一般会有众多参与者或利益方，在完成之后，算清相关的利益关系，完成利益分配。本文作者对完成利益分配的“清算系统”进行了详细的阐述分析，一起来看一下吧。
支付完成以后进行履约，履约完成以后就需要清算各方利益并最终进行结算，清结算体系与支付体系并行是支付范畴另一个非常庞大的体系。
我们都知道一笔支付最终都是要进行清算的，业务一般都会有众多参与者或者利益方，事做完以后，算清楚相关的利益关系，完成利益分配。今天我们就来讲一讲这个算清楚账完成利益分配的系统“清算系统”。
我们先看下清算的定义以及银联的清算的含义。
《支付清算组织管理办法》规定：
银联的支付清算包括淸分和资金划拨两个环节：
1）淸分
对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？
2）资金划拨
通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。
从上面的定义可以看出，清算最核心的其实就是清分这个过程，也就是算清楚各方应收应付的这个过程。今天我们重点讲的就是这个过程，以及记账的过程。而承载这个过程的系统，我们称为清算系统。
我们在一张支付小票这篇文章里提出过“311架构模型”，在这里我们可以看到清算系统的位置，在交易系统之后；这样的话我们可以理解为，清算系统在订单，交易，支付之后。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等，如图1所示：
图1 结算系统所处位置
清算系统整个结构由以下几部分组成。之前在O2O清结算实战中我们详细讲过一次，主要包括上游请求系统、商家模型子系统、计算核心、计费子系统、账务前置模块。后面会详细讲解每一个模块的职能以及设计关键点，如图2所示：
图2 清算系统架构
简而言之，有清分需求的业务系统都可以称为清算系统的上游，向清算系统发起清算请求，比如订单、交易、支付。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等。
对象模型就是你算出来的应收应付的债权对象，以及对象之间的关系。比如外卖平台的一个订单，可能会涉及到众多的利益对象，比如外卖平台要抽佣，提供饭餐的商家要餐费，骑士小哥要快递服务费，骑士小哥的保险费，这些需要完成订单的分账；而外卖平台还可能有很多渠道或者合伙人，需要给渠道和合伙人进行分润等。
分账就是将一款项分成多份给多方；而分润其实就是平台将计算所得例如分给多个分润方。
一个公司的业务可能不同的业务会有不同的对象模型，比如单一的商家，有合伙人的商家，有渠道商的商家，还有服务商平台商的商家。所以每一类订单会有不同的商户模型，进行计算时，计算的维度会有不同。
那么我们抽象出常见的集中对象关系模型，如图3所示：
图3 常见对象关系模型
在商家注册时，或者入驻时，在对象模型子系统生成他的对象模型，以及模型对应的对象关系。比如你通过了好友的邀请注册了一个网站，那么好友就成了你的合伙人了，那么你的对象模型就是“合伙人-用户模型”，当你有了消费时，会去计算给你好友作为你的合伙人的分成。
计费子系统核心职能就是维护计费规则，基于算账服务的请求返回计费模式以及参数值。比如单商家模型需要计算平台的信息服务费，那么通过基础参数请求计费子系统获得信息服务费的计费模式（按比例，固定金额，按单笔阶梯还是累计阶梯），拿到计费规则以后便可以计算出信息服务费数值。
所有最核心的就是要基于业务特点抽象出计费规则的模型。
一个是匹配的模式，就是你要用什么方法去到规则池里找到规则，比如条件法，就是一组参数去匹配到规则，这个也是最常用的，那么你就需要为不同的计费类型设置不同的匹配条件组，比如例子中通过“类目+城市”去找规则，这样的话再匹配条件里可以设置灵活的条件组。
然后就是规则的设置，一条规则应该有哪些维度组成，这样我们将每一个费用的计算认为是一个函数。
分成费用=f(x)=g{ j(a) , k(b,c) , l[y,z, p(e,r,u) ] }
那你规则就需要能够使这个符合函数得到f(x)的值。
分成模式：固定金额，固定比例，按单笔阶梯，按累计阶梯，递减等。
下面是在选择了模式以后要配置的规则参数：
看一个计费规则配置的示例，如图4所示：
图4 合伙人分成计费规则配置
基于上面的一个配置器，我们可以配置出非常多的规则，那么基于不同的费用的配置模板我们就可以配置出无穷个计费的规则了，如图5所示：
如图5 合伙人分成计费规则列表
一个清算请求来了以后，不同的清算类型我们的计算任务是不一样，计算的模式也是不一样的，计算的结果也会不一样。所以算账模型我们同样需要设计抽象出来，比如首先是通过清算类型确定清算的模板，基于清算模板我们就知道了应该计算哪些费用以及做什么任务，然后逐个去计算每一个费用即可，对于整个计算流程里如果需要做一些处理的进行处理即可。
关于分润和分账，基于不同的对象模型，我们可以知道哪些是要算分润，哪些是要算分账，我们用下面的这个代理商，商家，分账方来看，如图6所示：
图6 分账与分润
我们在一张小票看透支付清结算架构中讲了清分计费的结果是什么样的了，比如下面，我们算出来这笔外卖单的相关应收应付以及所属主体对象，如表1所示：
表1 清分明细
这是清分明细，那么是不是需要汇总轧差，这个看业务需要，一般情况下我们可以选择单笔入账的，也就是算出一笔入一笔。
清分完成以后，我们就需要做入账处理了，这个我们在账户系统设计从入门到精通讲得比较清楚，大家可以复习一下。
每个月公司要给员工结算工资：陈老师在京东开了一个店铺，定期京东需要给我结算货款；你请了一个保姆，每个月要给阿姨结算服务费….等等，结算场景我们并不陌生，但是怎么设计一个结算系统，你知道么！今天我们就好好聊一聊（最后有原型页面）。
定义：将平台的代收款支付给平台商家的资金转移过程。
展开来讲就是现在有很多平台比如滴滴，货拉拉，京东商城，作为一个服务平台上面有很多商家（我们将滴滴司机也成为商家），用户在平台购买商品或者服务，服务完成后，平台需要按照协议约定将服务款抽取一定费用后的剩余部分结算到商家的平台结算账户中或者直接付款支商家银行账户的资金划转过程。
结算名词解释，如表2所示：
表2 结算常见名词解释
结算我们常见的有2种模式：
像微信支付宝在开通支付产品时都会获得一个商户号，每个商户号会有一套账户用于收款和结算，并且签约绑定一张结算卡，次日会将上一日的结算款先结算之虚拟户在一笔结算之绑定的对公户。当然结算到对公户的比例可以自己设定，可以全额结算也可以部分结算，将一部分资金留在虚拟户里，用于次日的退款或者其他付款需求。
结算产品其实就是指支撑不同类型结算模式的结算能力：
结算功能，用户可以选择系统自动结算，也可以选自主发起结算。
结算签约，商家入驻平台时会进行资质认证以及签约一款适合自己的结算产品。
上面还是比较抽象，我们列举几个容易理解的结算场景：
所以，简而言之，结算就是将属于别人的钱给到别人。
评价结算系统的好和坏一个是站在公司角度，另一个是站在用户角度。
业务完成后，到了结算节点，账务系统按照结算周期将已经入账待结算数据打包后推送给结算系统，结算系统对结算数据进行处理加工后生成结算记录和结算明细；然后请求账务系统进行结算打款，账务系统请求账户中心扣款之后调用打款中心进行打款申请，如图7所示：
图7结算的业务流程
结算系统的产品架构如图8所示：
图8 结算系统的产品架构
对于不同结算产品，需要定时任务的管理去推动结算的进行。
从更小的颗粒度审视结算各信息记录之间的关系以及每个信息单元所记录的内容，便于对结算系统有个更精细的认知。
比如某一日一共结算了100个商家（一次结算请求），其中A商家结算了1000块钱（一条结算记录），其中A商家的快捷支付结算了100笔500块钱，网关支付结算了600笔500块钱（结算明细），如图9所示：
图9 结算单据之间的关系
结算业务的处理流程如图10所示：
图10 结算业务处理流程
结算系统处理时序如图11所示：
图11 结算系统处理时序图
每个处理阶段的详细逻辑流程图，篇幅有限，为了更加易读，简化了流程图，仅绘制了核心的节点，如果有不明白的地方可以加入产品学习群，深度交流。
数据准备过程如图12所示：
图12 结算过程中的数据准备
结算处理过程如图13所示（以T1结算为例）：
图13 结算处理
打款处理如图14所示：
图14 打款处理
结算状态流转如图15所示：
图15 结算状态流转
平台按照结算明细，以不同的维度生成结算账单，商户可以在后台下载结算账单，或者通过接口获取账单，这个大家可以调研一下微信或者支付宝后台，这里不再详述。
很多人在团建或者日常休闲娱乐时都会选择玩一些纸牌游戏；比如我们今天的主人公“诈金花”，它就是一款这样的多人纸牌游戏。游戏过程中需要考验玩家的胆略和智慧，每人三张牌，张张有玄机。三张牌会组成一下情况，相较之下定输赢，
从上到下每类越来越小，同类之下再比：
当然这是一个博弈的过程，因为全程大家不知道对方是什么牌，就跟斗地主一样，开始先在桌面投递基础筹码，然后过程中需要不断地循环下注，以致桌面的筹码越来越多，最终胜者的收益也会越来越诱人。
但是游戏过程中会有人因为担心更大风险选择“不跟”而退出，这个过程可能牌小诈走牌大，是实力、勇气和智谋的较量，是冒险家的游戏；最后胜者通吃，拿走桌面所有的筹码……
不过今天我们不玩游戏，而是玩点不一样的支付，解密一下这个游戏中隐藏的“支付清算思维”。
元旦期间陈老师约了4位朋友一起炸金花，组成了一个“5人金花局”，在我拿出纸牌即将开始的一瞬间，突然眼前一道白光，大脑一阵眩晕，待我清醒后，我竟然到了一个大大的房间里，站在一个白板前，下面做了很多大佬，乔布斯、张小龙、俞军、梁宁等，他们都直勾勾地盯着我……
只见后面显示屏上有一行大字“陈天宇宙‘支付奥妙’全球演讲巡演-深圳站”。
我是见过大世面的，调整懵逼神态以后，在白板上写下了一行字“为诈金花设计一套清算体系”，然后就开始了我的演讲。
一共有5个人参与游戏，为每个人设定一个游戏清算账户，并且设定一个中间待清算账户，如图16：
图16 清算账户设定
玩游戏我们可以选择一些物件作为代理货币，比如花生或者纸牌等，然后约定这些物品短期的货币信用，仅在游戏中有效。并且约定游戏代理货币和真实货币之间的汇率，比如1：10，如图17所示：
图17 游戏币与真实货币汇率
游戏期初陈老师作为央行角色决定发行100个花生作为游戏的全量货币，并且每人发放20个花生作为游戏基础筹码，如图18所示：
图18初始化账户余额
这样我们就为游戏设定了一个桌面的清算系统，该清算系统采用实时多边净额清算模式。
我们下注，追加砝码往桌子上扔花生的过程就是以花生为支付货币，支付筹码并且请求实时清算的过程，经过桌面清算以后我们可以实时看到桌面筹码总数量的变化，这个总数量就是本局当前的待清算总额，游戏每个场景的清算过程如下。
好了这是一个新的开局，每人获得了三张牌，牌的点数如图，并且往桌子上投递1个花生做为期初筹码，此时经过桌面清算系统的实时清算我们可以看到当前待清算筹码总量为5个花生，也就是50元人民币，大家都垂涎欲滴摩拳擦掌，如饿狼一般盯着这笔象征着“一次呷哺呷哺单人套餐还可以加一个鸡腿”的巨大的财富，如图19所示：
图19开局下注后的账户变化
这时桌面每个清算账户放一起我们可以理解为是诈金花游戏的资金池，该资金池总货币体量是100个头寸，而每次花生在不同清算账户之间的流转我们可以理解为是资金的流动性，流动性实现了不同清算账户之间资金的划拨，但并不改变整个资金池的货币体量。
而每次资金的流动也就是支付，我们可以认为是一次支付清算，而每个人的用来投递花生以及数手里或者桌面花生的手可以认为是支付系统。
在这个过程中，大家可以选择追加砝码看不看别人的牌，下一位就需要追加不下于前者的砝码，并且选择看还是不看。如果看牌的话牌小者就会出局，那么本局已经投递的砝码就打水漂了。这个游戏的过程大家可以认为就是我们的经济活动中的交易场景，经过一阵厮杀较量以后筹码分布成了如下局面，但没到最终输赢难分，战事非常胶着，如图20所示：
图20游戏过程中追加砝码
以上过程我们可以称为单局“局中”实时清算过程。
这时候经过一阵厮杀，王八手里没有花生了，也就是没有筹码了，但是此时他战至正酣，不忍退出，就向在座的手里有花生的发起了拆借诉求。最终以60元人民币购买了陈老师6个花生，完成了资产拆借，如图21所示：
图21成员间的拆借
到了陈老师喊牌了，陈老师不忍心让大家都倾家荡产，追加了5砝码后选择开牌，如图22所示：
图22开牌
这时本局以陈老师豹子牌点最大而获胜，获得了桌面全部筹码，不好意思桌面的所有牌都归我了，如图23所示：
图23结束后的桌面清算
天色已晚，大家都困了，这时候协商不玩了，改日再战，这时候开始进行多边清算了，以每个人手里的花生基数为清算依据，每个人需要支付人民币购买他人的花生以获得20枚期初的花生数量，或者卖出手里的花生获得人民币以实现期初的20枚花生，清算后大家手里的花生又回到了期初的20，只不过这次清算是需要进行人民币进行清偿推动的，如图24所示：
图24全局多边净额清算
以上的清算过程存在一些小的错误，感兴趣的可以找出，并在留言处回复讨论，这个过程就是对账的过程，那么就需要对账系统来实现了。
清算系统模型，如果要设计一套支付清算系统，那么从上面我们可以看出至少需要有如下的子系统和元素组成，清算账户、支付系统、交易系统，货币体系，交易场景等。
此时天塌地陷紫金锤，游龙出海惊天变，一阵天动地摇之后，有一道白光……这时候陈老师一个琅跄差点打翻了牌桌上的茶杯……说时迟那时快之间张三上来扶住了我说到“陈老师怎么了，是不是又起早写文章有点低血糖啊”。
此时我稍作镇定，会心一笑“哈哈 哈哈 没事 今日必定大胜 开牌……”新年的钟声敲响了，屋外已经飘起片片雪花，投眼望去依然灯火通明，每一个窗户透出的灯光里白雾下可能都是我们对2022年幸福的期许……
现在很多平台都有个人商家或者说是服务者，就像外卖平台的骑手，货运平台的司机，家政平台的阿姨，这些个人劳动者在平台提供服务，平台进行收入的结算。虽然有很多灵活就业平台都有成熟的解决方案，或是使用标准的清结算平台完成这部分的服务收入结算，这篇文章将介绍可能不常见的设计方法，但是里面的一些设计思路可能会有一些启发。
我们假定为一个货运平台设计司机的收入结算，每个司机按照不同的周期进行结算，特级司机按日进行结算，高级司机按周进行结算，普通司机按月进行结算；结算方式是按照约定周期主动打款给司机签约的银行卡当中，所以我们要有一个基础的结算信息数据，如表3所示：
表3 结算对象信息管理
该结算单跟我们之前讲的账户有点区别，这个单据更像一个工资条，但是其中有些字段具备账户的部分属性，该结算单的信息更加多，而且每个司机每个结算周期会创建一个本周期的结算单据。该结算单据包含一些统计类的字段，用于记录一些金额，就像我们工资条中的公积金，养老保险，税，应付工资等，例如我们筛选出王五近半年结算单据，如表4所示：
表4 结算单记录
实发收入不能为负，但是实际情况肯定有场景出现本期纯负收入的场景，为了保证这个字段不为负，我们设定另外2个字段，一个是本期欠款，来记录本期总实发的负额部分；上期欠款则是结转上期的欠款金额，本期的上期欠款等于上期的“本期欠款+上期欠款”。
司机签约认证以后由司机crm来申请创建该司机的结算账户，也就是我们上面的结算信息，并且为其创建第一条结算单据。
按照司机的结算周期定期的创建本周期的结算单据，并且实时的根据清分结果更新结算单据的相关数据清分司机在完成一单收入时，由订单系统推送订单到清分系统，完成该单据相应费用的计算，比如本单平台佣金，税等，然后计算本单的司机所得，基于计算结果去更新该司机的结算单据；奖金和罚款同理。
因为借宿那单据中有几个字段需要在本期完结以后才能进行统一处理，比如欠款的处理。所以在一个结算周期结束的第二天凌晨，打款之前，我们要完成期末账务的处理，比如汇总生成本期欠款，汇总生成本期实发等等。
到了结算周期结束的第二天凌晨基于结算单据的“实发收入”生成打款订单，请求打款系统进行打款。
我想前面我们有大量的介绍清结算账户等相关的内容，大家现在应该很容易理解任何一种结算手段和方式，学习肯定是越来越轻松，接收内容的效率越来越高。
就像我最近看很多支付类书籍，速度越来越快，因为你单单看到标题，然后扫描一下正文中的关键字眼基本就知道他在讲什么，已经了解的东西，就一扫而过，快速地扫描一下，大脑提取一次同类知识点，补充书中的新内容即可。所以说学习的越多，后面的升级效率越快……量变终会引起质变。
最舒服的工作，可能不是工作本身，而是你对工作的把控力；如果任何一次需求、任何一次沟通，只要对方说出某几个关键字，你已经有了最好的答案，我想这就是最舒服的工作，因为你从不会因为“难度”而痛苦，加油，让自己面对的一切都变得简单，即使在别人眼里，它是巨大的挑战！
我们都知道清结算，因为课堂刚刚完结了这个专栏的20节课；我想我们很多人也都知道中台，因为这个概念活了很长时间。那么什么是“清结算中台”呢？我想也很容易理解，无非就是用“中台的理念”建设“清结算体系”。
那这样的话，要想做好中台，首先就要理解什么是中台，中台的核心是什么？清结算的相关系统如何向中台靠拢，做成中台的样子…..这是这篇文章要介绍的内容。
可以说我们在创造一种事物或者系统建设的理念和方法，那么抽取这个理念和方法首先就需要挖掘其最核心最突出的特征。清结算业务或者相关系统本身跟商品系统、购物车、订单、服务履约等系统，除了功能模块不同以外本质没有实质性差别，都是基于某项业务将功能集成了一个系统。
所以说在系统本身没有最突出的特征，最突出的特征就必然从“中台”这个系统建设理念上去挖掘。
什么是中台呢，中台又有什么最核心的特征？我们常说的抽象通用能力，规避重复建设等这些是中台的目的。而我们分析中台的核心特征可以概括为这样一个模型：三层式。
如果将清结算体系规范成“三层式”去建设，那么就是“清结算中台”，这三层如图25所示：
图25三层式结算清结算中台架构
1）业务层
清结算中台要关注业务场景，为业务场景提供系统服务，多业务线、复杂的业务场景中的清结算业务是清结算中台服务的对象，所以说清结算不再是独立的一个个后台系统，而是一个服务集群，我们要基于“服务”去建设系统。
2）服务层
服务层是基于服务对象抽象出来的服务单元，就像我们去银行办事，大厅的接待员会接待你。传统上来说她是个接待员，但是站在服务的角度，她提供了“接待服务”，虽然她还是她，虽然接待还是接待，但是已经大不同。基于接待服务去思考，我们会更关注服务本身，而不是她这个接待员。
所以清结算中台，我们不再关注清结算体系内单独的系统本身，而是去关注这套系统能向外提供的服务，以服务论影响。既然是“服务层”，那么我们就需要去抽象这些服务，定义这些服务，以及设计这些服务的准入标准、流程、规范，以及这些服务的提供方式，API，MQ，SQL还是……
3）基础层
这一侧就如“接待员”一样，是我们对外提供服务的能力基础，所以我们可以称之为“能力基础层”，这一层是以系统能力为建设对象，比如清算计费的能力、账务记录的能力、账户冻结的能力。这些能力简单的说就是我们曾经的叫“功能”的另一个说法，为了显得我们是一个专业的中台，我们对外宣称，我们这不是简单的功能，而是能力集群。
这三层之间的关系，我们不如用一段描述来定义。公司的业务复杂，为了规避重复建设，搭建通用的系统，可以多业务线复用，未来新业务可以复用；我们基于业务场景进行抽象，抽象出原子化的服务单元；这些服务单元需要一系列的系统功能来支撑，而这些系统功能抽象出通用的系统服务能力，将这些服务能力进行封装，构建成了一个能力集群，所以说清结算中台的未来要关注三个东西，如图26所示：
图26清结算中台三个目标
基于业务场景构建基础能力，反过来将基础能力封装出标准服务，去覆盖更多的业务场景；那么清结算中台其实就是做下面的三件事，如图27所示；
图27清结算中台三重点
对清结算中台的能力集群进行更简洁的表达，将多个能力进行分组，对每一组从业务视角阐述，我们就可以得到清结算中台的几大服务集群，如图28所示:
图28清结算中台服务集群
所以如果大家要做清结算系统，那么就做好系统的架构和功能；如果要做清结算中台，那么就做好“三层式”，定义好每一层以及每一层之间的协同。然后在每一层内做好更细颗粒度的规划和抽象，至少你会是一个合格的“清结算中台”的样子……
思维模型只不过是翻山越岭沧海桑田以后对这段路途最刻骨铭心的归纳和抽象！
专栏作家
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。