我们知道，每一笔支付最终都要进行结算，一般会有众多参与者或利益方，在完成之后，算清相关的利益关系，完成利益分配。本文作者对完成利益分配的“清算系统”进行了详细的阐述分析，一起来看一下吧。
支付完成以后进行履约，履约完成以后就需要清算各方利益并最终进行结算，清结算体系与支付体系并行是支付范畴另一个非常庞大的体系。
一、清算系统设计我们都知道一笔支付最终都是要进行清算的，业务一般都会有众多参与者或者利益方，事做完以后，算清楚相关的利益关系，完成利益分配。今天我们就来讲一讲这个算清楚账完成利益分配的系统“清算系统”。
1. 清算系统概述
我们先看下清算的定义以及银联的清算的含义。
《支付清算组织管理办法》规定：
- 支付清算：支付指令的交换和计算
- 支付指令：参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令
- 支付指令的交换：提供专用的支付指令传输路径，用于支付指令的接收、清分和发送
- 支付指令的计算：对支付指令进行汇总和轧差
- 参与者：接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构
银联的支付清算包括淸分和资金划拨两个环节：
1）淸分
对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？
2）资金划拨
通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。
从上面的定义可以看出，清算最核心的其实就是清分这个过程，也就是算清楚各方应收应付的这个过程。今天我们重点讲的就是这个过程，以及记账的过程。而承载这个过程的系统，我们称为清算系统。
2. 清算系统的位置
我们在一张支付小票这篇文章里提出过“311架构模型”，在这里我们可以看到清算系统的位置，在交易系统之后；这样的话我们可以理解为，清算系统在订单，交易，支付之后。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等，如图1所示：
图1 结算系统所处位置
3. 清算业务架构
清算系统整个结构由以下几部分组成。之前在O2O清结算实战中我们详细讲过一次，主要包括上游请求系统、商家模型子系统、计算核心、计费子系统、账务前置模块。后面会详细讲解每一个模块的职能以及设计关键点，如图2所示：
图2 清算系统架构
4. 上游请求系统
简而言之，有清分需求的业务系统都可以称为清算系统的上游，向清算系统发起清算请求，比如订单、交易、支付。上述三者都有可能基于本身的业务来请求清算，比如基于订单清算商家结算款，基于交易计算卡券营销等成本，基于支付计算通道成本等。
5. 对象模型
对象模型就是你算出来的应收应付的债权对象，以及对象之间的关系。比如外卖平台的一个订单，可能会涉及到众多的利益对象，比如外卖平台要抽佣，提供饭餐的商家要餐费，骑士小哥要快递服务费，骑士小哥的保险费，这些需要完成订单的分账；而外卖平台还可能有很多渠道或者合伙人，需要给渠道和合伙人进行分润等。
分账就是将一款项分成多份给多方；而分润其实就是平台将计算所得例如分给多个分润方。
一个公司的业务可能不同的业务会有不同的对象模型，比如单一的商家，有合伙人的商家，有渠道商的商家，还有服务商平台商的商家。所以每一类订单会有不同的商户模型，进行计算时，计算的维度会有不同。
那么我们抽象出常见的集中对象关系模型，如图3所示：
