支付完成后的清结算体系：详细阐述与分析

支付完成后就要履行合同，履行完成后还要解决各方利益问题，最后结清账目。清结算体系和支付体系并行，是支付领域的另一个非常庞大的系统。

1. 清算系统设计

我们都知道，一笔钱最后都要结算。生意一般会涉及很多参与者或者利益相关方，生意做完之后就要结算相关利益，分配利益。今天我们就来聊聊“结算制”，一个结算账目、分配利益的制度。

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所示：

表一：清算详情

这个就是清算明细，所以是否需要汇总和抵扣差额，根据业务需要而定。一般我们可以选择单独入账，也就是每笔交易都计算进去就行。

9.簿记服务

清算完成后，我们需要进行会计处理，这个我们在科目体系设计从入门到精通里面已经讲清楚了，大家可以复习一下。

2. 结算系统设计

公司每个月都需要给员工结算工资：陈先生在京东开了一家店，京东需要定期帮我结算工资；你请了一个保姆，每个月都需要帮她结算服务费……等等。结算场景我们并不陌生，但你知道该如何设计一个结算系统吗？今天就来聊聊吧（最后有原型页面）。

1. 什么是结算？

定义：平台代收支付将资金转移到平台商户的过程。

具体来说，现在有很多平台，比如滴滴、货拉拉、京东等，作为一个服务平台，上面有很多商家（我们也叫滴滴司机商家），用户在平台上购买商品或者服务，服务完成后，平台需要按照约定在扣除一定的费用后，将剩余的服务费结算到商家的平台结算账户，或者直接打到商家的银行账户。

结算条款解释如表2所示：

表2 结算中常见术语解释

2. 结算模式

常见的结算方式有两种：

结算到银行卡：将结算款直接支付到商户签约的结算银行卡账户中 结算到虚拟账户：将虚拟结算款存入商户在平台开设的结算账户中，商户后期可提现

微信、支付宝开通支付产品时，都会获得一个商户号，每个商户号都会有一套收款结算的账户，并签订绑定结算卡，第二天会先把前一天的结算金额结算到虚拟账户，再结算到绑定的对公账户。当然结算到对公账户的比例可以自己设定，可以全部结算也可以部分结算，把部分资金留在虚拟账户，用于第二天退款或其他支付需要。

3. 关于结算产品

结算产品实际上是指支持不同类型结算模式的结算能力：

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

入驻签订合同：商户入驻平台时，会进行资质认证，签订适合自己的入驻产品。

4. 结算场景

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

所以，简而言之，和解就是把属于别人的钱交给别人。

5. 如何评估结算产品质量

评价一个结算系统的好坏，可以从两个角度来判断：一是从公司的角度，二是从用户的角度。

6.结算业务结构

业务完成后，在结算节点，会计系统将需要结算的数据按照结算周期打包推送到结算系统，结算系统处理结算数据，生成结算记录和结算明细，然后请求会计系统进行付款结算，会计系统请求账户中心扣款，然后调用支付中心申请付款，如图7所示：

图7 结算业务流程

7. 结算系统架构

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

图8 结算系统产品架构

针对不同的结算产品，需要通过计划任务管理来推动结算流程。

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

从更小的粒度去考察结算信息记录之间的关系以及每个信息单元所记录的内容，将有助于您对结算体系有更加细致的了解。

例如某日共结算100笔商户（1笔结算请求），其中商户A结算1000元（1条结算记录），其中商户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：《扎金花》中的清算思维

很多人在团建或者日常休闲娱乐的时候，都会选择玩一些卡牌游戏；比如我们今天的主角“查金花”就是这样一款多人卡牌游戏。游戏过程需要考验玩家的胆量和智慧，每个人手上有三张牌，每张牌都有一个谜团，三张牌会形成如下局面，通过比对来决定胜负。

从上到下，每个类别越来越小，然后与同一类别进行比较：

当然，这是一个博弈过程，因为整个过程中，没有人知道对方有什么牌。就像玩斗地主一样，你从桌面上放基础筹码开始，然后你需要不断循环下注，让桌面上的筹码越来越多，最终获胜者的利润也会越来越丰厚。

然而在游戏过程中，有些人可能会因为担心更大的风险而选择不跟进、退出。在这个过程中，有可能用小牌作弊，赢得大牌。这是一场力量、勇气和智慧的较量，是一场冒险者的游戏。最终，胜利者拿走桌上所有的筹码......

但今天我们不是来玩游戏的，而是来和支付玩点不一样的东西，解密这场游戏中隐藏的“支付结算思维”。

1. 陈先生的“金花游戏”

大年初一的时候，陈先生邀请了4个朋友一起打扑克，组成了“5人扑克局”。当我拿出牌，准备开始的时候，突然眼前一片白光，脑子一阵眩晕。等我醒来的时候，我已经在一个大房间里，站在一块白板前，下面站着很多大佬，有乔布斯、张小龙、于军、梁宁等等，他们都盯着我看……

后面的显示屏上，写着一行大字：“陈天宇‘支付的秘密’全球巡回演讲——深圳站”。

我见识过很多世间事，调整了一下迷茫的表情后，在白板上写下一行字：“设计一个针对欺诈的清算系统”，然后开始了我的演讲。

2.设立清算账户

参加游戏人数为5人，每人设置一个游戏结算账户，并设置中间结算账户，如图16所示：

图16 清除账户设置

3. 结算货币

在玩游戏时，我们可以选择一些对象作为代理货币，比如花生或者扑克牌，然后约定这些对象的短期货币信用，只在游戏中有效。并约定游戏代理货币与现实货币的兑换率，比如1:10，如图17所示：

图17 游戏币与现实货币的兑换率

4.游戏币的发行与分配

游戏开始时，陈先生作为央行，决定发行100枚花生作为游戏的全部货币，并给每人发放20枚花生作为游戏的基础筹码，如图18所示：

图18 初始化账户余额

这样，我们为游戏搭建了桌面清算系统，采用实时多边净清算模式。

桌面下注、加重、扔花生的过程就是用花生作为支付货币，支付筹码并请求实时结算的过程。桌面结算后，我们可以实时看到桌面上筹码总数的变化，这个总数就是本局当前需要结算的总金额。游戏各个场景的结算流程如下。

5. 开盘投注结算

好了，这是一个新的开始。每个人拿到三张如图所示的点数牌，在桌上扔一颗花生作为初始筹码。此时，经过桌面结算系统实时结算，我们可以看到总共需要清算的筹码是5颗花生，也就是50元。大家都垂涎欲滴、摩拳擦掌，像饿狼一样盯着这笔巨额财富，象征着“呷哺呷哺单餐还可以加个鸡腿”，如图19所示：

图19 开仓后账户变化

此时我们可以理解桌面上的每一个清算账户都是金花游戏的资金池，资金池总币量为100仓位，每一次花生在不同的清算账户之间的流通都可以理解为资金的流动性，流动性实现了资金在不同清算账户之间的调配，但不会改变整个资金池的币量。

每一笔资金的流动，也就是支付，都可以看作一次支付结算，每个人用来递花生的手，以及清点手里或者桌子上的花生，都可以看作一个支付系统。

6. 附加重量结算

在这个过程中，你可以选择加权或者不看别人的牌，下一位玩家需要加权不小于前一位的牌，并选择看牌或者不看牌。如果看牌，那么牌较小的玩家就会被淘汰，而本局已经交出的权值就浪费了。你可以把这个博弈过程看成是我们经济活动中的交易场景。经过一番激烈的战斗，筹码分配如下，但最后谁胜谁负并不难分。战斗非常胶着，如图20所示：

图20 游戏过程中添加权重

我们可以将上述过程称为单个游戏的实时结算过程。

7.个人间借贷及结算

一番激战之后，王八已经没有花生了，也就是没有筹码了，但他正处于激战之中，不忍心退出，便向有花生的人发起了借贷请求，最终他以60元的价格从陈先生手中购得6颗花生，完成了资产借贷，如图21所示：

图 21：成员国之间的借贷

8. 单场比赛结束后多边净胜球结算

轮到陈先生叫牌了，陈先生不忍心让大家都破产，就加了5个权重，选择开牌，如图22所示：

图 22 打开卡片

此时陈先生以豹子牌点数最高获胜，得到桌面上全部筹码，不好意思，桌面上的牌都是我的，如图23：

图23 完成后桌面清理

9. 全球多边净额结算

天色渐晚，大家都有些困了，谈判结束，改日再战。这时，多边结算开始了。结算是按照每个人手里的花生数量来算的，每个人需要支付人民币去买别人的花生，得到最初的20颗花生，或者卖掉自己的花生换取人民币，实现最初的20颗花生。结算之后，每个人手里的花生又回到了最初的20颗，不过这次结算需要通过人民币结算来驱动，如图24所示：

图 24 全球多边净额结算

上面的清算流程有些小错误，有兴趣的可以自己找找，在评论里回复讨论，这个过程就是对账的过程，所以需要一个对账系统来实现。

10. 比赛概要

清算体系模型。如果我们要设计一个支付清算系统，那么从上面我们可以看出它至少需要由以下几个子系统和要素组成：清算账户、支付系统、交易系统、货币系统、交易场景等。

11.梦醒时分会心一笑

就在这时，紫金锤一锤砸下，天塌地陷，一条蛟龙从海中冒出，引起惊天异变，地天一震后，白光四起……这时，陈老师一个趔趄，差点把牌桌上的茶杯打翻……一瞬间，张三上来扶住我，说：“陈老师，怎么了？又早起写文章，血糖低了？”

这时我稍稍平复了心情，会心一笑：“哈哈哈上面一个日下面一个非是什么字，没事，今天一定中大奖……”新年的钟声响起，屋外已是雪花纷纷扬扬，放眼望去，灯火依旧明亮，白雾笼罩下，透过每一扇窗户透进来的灯光，或许就是我们对2022年幸福的期盼……

延伸阅读2：工资结算可以这样进行

现在很多平台都有个体商户或者服务提供者，比如外卖平台的骑手、货运平台的司机、家政平台的阿姨等。这些个体劳动者在平台上提供服务，平台结算收入。虽然很多灵活就业平台都有成熟的解决方案，或者使用标准的清结算平台来完成这部分服务收入结算，但本文将介绍的设计方法可能并不常见，但其中的一些设计思路或许能有所启发。

1. 结算信息

我们假设某货运平台正在设计司机收入结算系统，每个司机按照不同的周期进行结算，特级司机按日结算，高级司机按周结算，普通司机按月结算。结算方式是按照约定的周期主动打款到司机签约的银行卡上，所以我们需要有一个基本的结算信息数据，如表3所示：

表3 安置对象信息管理

2. 结算单

这个结算单跟我们之前讲的账户有点不一样，这个单据更像是一张工资单，但是它的一些字段具备账户的一些属性。这个结算单包含的信息比较多，每个司机每个结算周期都会创建一张结算单。这个结算单包含一些统计字段，用来记录一些金额，就好比我们工资单里的公积金、养老保险、税金、应付工资等。比如我们筛选出王武近半年的结算单据，如表4所示：

表 4 结算记录

实际收入不能为负数，但现实中肯定存在本期收入纯负数的情况。为了保证该字段不为负数，我们设置了另外两个字段。一个是本期欠款，用于记录本期总实际收入的负数；上期欠款是上期欠款结转的金额。本期上期欠款等于上期的“本期欠款+上期欠款”。

3. 结算信息创建

当司机签订合同并且通过身份验证之后，司机的CRM会申请创建司机的结算账户，也就是上面的结算信息，并为其创建第一份结算文件。

4. 生成结算文件

根据司机结算周期定期生成本周期结算单，并根据结算结果实时更新结算单相关数据。当结算司机完成一笔收入订单时，订单系统将订单推送至结算系统，完成该单据相应费用的计算，如该订单的平台佣金、税金等，并计算该订单司机的收益，根据计算结果更新司机结算单；奖金、罚款亦同。

5. 期末会计

因为借款单据中有几个字段需要在本期结束后统一处理，比如欠款的处理等。所以，在一个结算周期结束后的第二天凌晨，付款前，一定要完成期末账务的处理，比如汇总本期欠款，汇总本期实际付款等。

6.付款

在结算周期结束后的第二天凌晨，根据结算单的“实际收入”生成支付指令，请求支付系统进行支付。

7. 学习将变得更加高效

我想前面我们已经介绍了很多关于清结算账的内容，现在大家应该都很容易理解任何结算手段和方法，学习肯定会变得更加轻松，接收内容的效率也会越来越高。

就像我最近看了不少付费书，速度越来越快，因为你只要看标题，然后扫一眼文中的关键词，基本就能知道他在讲什么。已经知道的东西，就直接扫一眼，快速一扫，把相同的知识点提取一遍，再补充书中新的内容。所以学得越多，后面升级效率就越快……量变最终会带来质变。

最舒服的工作，或许不是工作本身，而是你对工作的掌控力；如果对于任何需求，任何沟通，只要对方说几个关键词，你就已经有了最好的答案，我想这就是最舒服的工作，因为你永远不会因为“难”而吃亏。加油，让你面对的一切变得简单，哪怕在别人眼里是一个巨大的挑战！

延伸阅读3：“三层”清算结算平台

我们都知道清理和解决方案，因为我认为许多人都知道了中间平台的20次课程，因为这个概念已经存在了很长时间。

在这种情况下，如果您想在中间平台上做好工作，则必须首先了解中间平台是什么，而中间平台的核心是什么？

我们可以说，我们正在创建一个概念和方法来提取此概念和方法，我们首先需要探索其最重要的和相关的系统本身，而商品系统，购物车，订单，服务实现和其他系统基本上是相同的功能。

因此，系统本身没有最突出的功能。

什么是中间平台，中间平台的核心功能是什么？

如果清算和结算系统标准化为“三层”结构，则是“清除和结算中间平台”。

图25三层和解平台体系结构

1）业务层

清算和和解中间的工作人员应该为他们提供多个业务的清算和和解业务，而复杂的业务方案是清算和和解中间办公室的对象。

2）服务层

服务层是从服务对象抽象的，就像我们去银行开展业务一样，大厅的接待员传统上是接待员，但是从服务的角度来看，她仍然提供“接待处”。

因此，在清算和解决中间平台中，我们不再关注清算和和解系统中的各个系统，而是该系统可以为外界提供的服务，并且我们使用服务来影响它，因为它是“服务层”，我们需要抽象这些服务，定义这些服务，并设计这些服务的服务，以及这些服务的规格，以及SAP，以及它是否是ST ...

3）基层

这是一个“接待员”，这是我们向外部世界提供服务的基础，因此我们可以将其称为“能力基础层”，例如清除计费的能力，记录帐户的能力，以及我们用来冻结我们的 of Under of Under of Under of我们的职业。一群功能。

我们可能会使用描述来定义这三层的关系清算和结算平台的未来应集中在三件事上，如图26所示：

图26清算和解决平台的三个目标

基于业务方案建立基本功能，然后将基本功能封装到标准服务中，以涵盖更多的业务方案；然后，清算和结算平台实际上做了以下三件事，如图27所示；

图27清算和结算平台的三个关键点

通过更简洁地表达清算和结算平台的能力群集，分组多个功能并从业务角度进行解释，我们可以获得清算和解决平台的几个主要服务集群，如图28：图28：

图28清算和结算服务集群

因此，如果您想建立一个清除和结算系统，那么您应该在系统体系结构和功能上做好工作；

思维模型不过是越过山脉和河流之后最令人难忘的摘要和旅程的抽象，并经历了巨大的变化！

专栏作家

Chen ，《微信》公共帐户：Chen 是每个人的专栏作家。

标题图像来自CC0协议

本文中表达的观点仅代表作者本人，而产品经理平台仅提供信息存储空间服务。

收集的{{。}}喜欢{{。