一文搞懂“支付·清结算·账务”全局

《上帝视角看支付，总架构解析》 对支付的宏观层面做了分析，详解了整个支付体系每一层的架构和业务模型，而每一层的企业内部支付体系建设是什么样的？会涉及到哪些环节和系统？每个系统会涉及到哪些单据和逻辑，是本章的重点。

大家对外卖都很熟悉，因为会经常点外卖，我们以外卖场景为例，分析外卖的整个交易链路，从用户下单、商家接单、分配骑手、骑手取餐、配送到用户取餐，从订单、计价、配送、清分、记账、结算到付款，讲清楚每个环节的逻辑和内容。

从一张外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付细节，最后抽象出一个可通用的支付清结算体系架构出来。

4.1 一张小票

看下面外卖盒上的纸质小票：牛肉拌饭 1 份一共 39 元、餐盒费 1 元，没有配送费，合计 40 元，优惠了 19 元，实付 21，实收 17 元；

再看外卖平台（以下简称 “平台”）APP 中的订单信息：烤肉饭 1 分 39 元、打包费 1 元、配送费原价 7 元现价 2 元、平台会员 15 元；其中红包减 7 元、满减优惠 14 元，总优惠 26 元，订单合计 36 元，如图 4-1 所示：

图 4-1 美团外卖小票（左）和订单信息（右)

图中可以看出来，商家的小票信息和平台的订单信息之间有不少的差异，特别是优惠的明细展示、优惠总额和应付总额之间存在差异。下面我们就顺藤摸瓜，分析背后的玄机。

4.1.1 外卖单据

外卖过程中会产生很多的单据，不同环节的单据会提供给不同的参与者使用，不同单据记载着不同的但又相互关联的信息，我们需要了解这些主要的单据，并知道其用途、相互之间的关联关系和设计方法。这些单据主要包括用户订单、商家小票、商家后台账单、骑手账单、平台内部单据等，接下来逐一分析。

用户订单：在外卖的客户端里，用户的外卖订单信息记录了购买的商品、商品价格、优惠信息、支付信息、配送信息、商家信息等全部内容，这些信息是外卖平台给用户提供的交易记录，如图 4-2 所示。

图 4-2 用户的外卖订单信息

商家小票：用户收到的餐盒上都会附带一个纸质小票，也记载着该单商品的基本信息，这个信息是出餐商家给用户提供的本单餐品的服务内容以及收费情况，如图 4-1（右）所示。

商家账单：是平台提供给商家的在平台上的经营数据，例如卖了多少餐、挣了多少钱、给商家付了多少款等信息，如图 4-3 所示。

图 4-3 商家账单管理

骑手账单：是平台提供给骑手的在平台的上的服务信息，包括接单信息、收入信息、奖惩信息、付款情况等内容，如图 4-4 所示。

图 4-4 骑手账单

平台内部单据：是平台自己内部存在很多业务系统，这些系统协同完成整个外卖业务。例如订单系统记录订单，计费系统记录计费结果，账务系统记录账务信息等，这些系统依赖各种单据完成记录以及推动流程的进行，并通过各种单据互相传递信息，如图 4-5 所示为后台订单管理。

图 4-5 内部订单管理

4.1.2 外卖业务模型

我们先明白一个关系，订外卖的用户跟商家没有直接的关系，平台跟商家是结算关系，也就是平台帮助商家代收餐费，并向商家结算收入。简而言之，用户付钱给平台，平台抽一部分佣金，剩余部分结算给商家，如图 4-6 所示。

图 4-6 交易关系

这个过程大致是这样的，用户先到平台选择喜欢的 “餐品”，然后“下单”，生成交易“账单”，用户选择支付方式进行“支付”，支付成功后平台要履行承诺把餐送到，“履约” 完成以后平台就开始进行各方利益的 “清分”，计算清楚应给谁多少钱，并“记账”，最后将款项“结算” 给商家，这个过程如图 4-7 所示。

图 4-7 外卖交易链条

当然，一次外卖业务会涉及到非常多的参与者和过程，每个参与者都有自己的一个子流程，这些子流程共同串起整个外卖交易。比如用户选品、下单、支付、取餐、评价；商家接单、制作；骑手接单、到店、取餐、配送、确认送达；平台创建订单、计价、支付处理、分配骑手、记账结算等。

将上述的不同角色、不同行为、不同节点所形成的一个复杂的流程绘制出来，以方便我们动态地审视整个交易链条的全部事件，这也将有利于后续我们去设计抽象清结算的业务节点，如图 4-8 所示。

图 4-8 外卖个角色的操作流程

基于上面的业务分析，接下来分析开头那张小票在每个环节是怎么处理的，都生成了什么单据，单据中包含哪些信息。

4.2 用户下单

用户下单是一次外卖旅程的开始，我们对这个过程再熟悉不过了。用户选择菜品，平台计算本单相应的优惠，计算应该支付的金额等内容，用户完成支付。

为了便于分析，我们让订单更加简单一些，仅分析展出最核心的字段，但是所涉及到的订单结构是完整的；本单用户看到的订单信息如图 4-9 所示。

图 4-9 本次下单的订单信息

4.2.1 商品

商品概念广泛应用于电商，在 o2o 领域可能叫 “服务” 多一点，站在吃货的角度来看，订外卖，买了一份商品也可以说的过去；一个简单的商品模型如图 4-10 所示。

图 4-10 商品信息结构

本案例中的这单外卖共有 3 个商品以及配送费，我们将商品信息、商品原价、购买数量、配送费等内容整理到表格中，如表 4-1 所示：

表 4-1：外卖单的商品信息

商品信息	菜品	烤牛肉拌饭	餐盒	美团会员
	原价	39.00	1.00	15.00
	数量	1	1	1
	单品总价	39.00	1.00	15.00
	商品原价	55.00
其他费用	配送费	7.00

这里需要特别说一下平台会员，这是平台推出的一个会员服务，相当于花钱买了多张优惠券，如图 4-11 所示，所以购买平台会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券。

图 4-11 平台会员详情

4.2.2 优惠

选购了商品以后，需要知道这一单有什么优惠，本单的优惠主要有 3 个：配送费 5 元减免、平台红包减 7 元、满减优惠减 14。把优惠信息增加到表 4-1 中得到了包含了优惠信息的表格，该订单的优惠比较简单，都是针对整单的优惠，没有针对单品的优惠，未来完整起见我们将单品优惠也放进去，只不过优惠金额为 0，如表 4-2 所示。

表 4-2 优惠信息

商品信息	菜品	烤牛肉拌饭	餐盒	美团会员
优惠信息	单品优惠	特价菜	满二赠一	立减
	优惠金额	0	0	0
	店铺满减	-14.00
	平台红包	-7.00
	配送费优惠	-5.00
	优惠合计	-26.00

4.2.3 计价

该过程是要计算出本单应该付多少钱，计价包含很多内容，比如计算优惠、计算商品总价、计算配送费、结算优惠后的订单金额、计算用户应付金额等，计算完成以后反馈给交易，常见的计价模块架构如图 4-12 所示。

图 4-12 计价模块架构图

对于例子中订单的计价相对比较简单，有时候点的外卖菜品多，计价会复杂一些，从而计价过程也相对复杂很多，但无论计价场景复杂还是简单，基本原理是一样的。我们将计价结果增加到表格中，如表 4-3 所示。

表 4-3 计价信息

商品信息	菜品	烤牛肉拌饭	餐盒	美团会员
计价信息	订单总价	62.00
	总优惠	-26.00
	合计金额	36.00

用户完成了订单信息的填写和提交，内部系统完成了交易的计价，接下来就是下单了，交易系统请求订单系统完成订单的创建。

4.2.4 订单生成

交易系统请求订单系统创建订单，因为不清楚平台和商家之间的清结算协议，所以暂且认为所有优惠由平台提供给用户，后续平台再基于协议跟商家之间做优惠的分摊，将上述商品、优惠、计价等信息集成到一起，就得到了完成的订单信息了，如表 4-4 所示。

表 4-4：订单集成信息

商品信息	菜品	烤牛肉拌饭	餐盒	美团会员
	原价	39.00	1.00	15.00
	数量	1	1	1
	单品总价	39.00	1.00	15.00
	商品原价	55.00
其他费用	配送费	7.00
优惠信息	单品优惠	特价菜	满二赠一	立减
	优惠金额	0	0	0
	店铺满减	-14.00
	平台红包	-7.00
	配送费优惠	-5.00
	优惠合计	-26.00
计价信息	订单总价	62.00
	总优惠	-26.00
	合计金额	36.00
结算信息	订单应付	36.00

订单信息中平台红包是基于 15 元购买了平台会员以后才能使用的优惠，因此这一单，需要用户先购买会员获得优惠券，然后在本单使用从而获得红包优惠。虽然在用户看来是同一个订单，但在交易处理层，至少需要做 2 次处理，一个是对购买平台会员的交易处理，另一个是对本单整单的交易处理；所以订单需要拆成 2 个子单，一个是外卖单，一个是平台会员购买订单，如表 4-5 所示：

表 4-5：父子订单信息

订单类型	订单号	商品总价	总优惠	应付总价
总订单	111	62	-26	36.00
外卖子单	11101	47	-26	21.00
会员子单	11102	15	0	15.00
合计				36.00

商家的小票中显示商品总价是 40，总优惠是 19；跟订单 11101 之间的 26 元优惠存在 7 元的差额，是什么呢？其实就是平台红包 7 元，本单配送费的 5 元优惠和满减 14 是商家优惠，所以商家总优惠 19 元，而平台红包优惠 7 元，本单总优惠 26 元。

但是，发现商家实收 17 元，那么这 4 元是什么呢？这里有 2 个推断，一是平台抽佣 4 元，另一个可能是商家承担了 7 元平台红包优惠中的 4 元；如果是取中间可能的话，那么实际的清分结果可能是如下模型：

4 元 = x+y

x = 平台抽佣；x∈[0-4] 元

y = 分摊平台红包优惠；y∈[0-4] 元

4.2.5 交易处理

完成了订单创建以后就需要创建支付账单了。根据上述分析，本单的交易处理相对比较复杂，因为要先处理平台会员的购买交易，然后处理外卖订单交易，这个过程如图 4-12 所示。

图 4-12 交易处理过程

因为有 2 个子单，所以我们生成 2 个交易账单，但是在支付的时候进行合并支付，这样做的好处是可以解耦 2 个交易处理流程，账单信息如表 4-6 所示。

表 4-6：账单信息

账单类型	账单号	订单号	账单总额
外卖账单	zd11101	11101	47.00
会员账单	Zd11103	11102	15.00
合计			62.00

有了账单信息以后，基于账单生成支付请求，这里的支付渠道是广义的，其中优惠券、满减等都视为一个支付渠道，也就是在支付信息层都算做一种支付方式，如表 4-7 所示。

表 4-7：账单中的支付信息

账单类型	账单号	账单金额	支付方式	支付金额
外卖账单	Zd11101	47	立减优惠	5.00
			满减优惠	14.00
			美团红包	7.00
			微信	21.00
会员账单	Zd11102	15	微信	15.00
会员账单	Zd11102	15	微信合计	36.00
合计				62.00

4.2.6 支付处理

账单生成以后，请求支付系统生成支付单，用户在客户端上通过收银台发起支付请求，其中微信支付请求支付系统；优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样就完成了整个账单的支付了，此时账单变为已支付，订单支付状态变为已支付，订单的履约状态变为待配送，支付信息如表 4-8 所示。

表 4-8：支付流水信息

支付流水号	支付方式	支付金额
001	立减优惠	5.00
002	满减优惠	14.00
003	平台红包	7.00
004	微信合计	36.00
合计		62.00

4.3 履约过程

用户支付成功以后进入履约过程，整个过程包括了商家的接单出餐、骑手的派单和配送、用户的确认收餐以及整个过程的管控。

4.3.1 商家接单

商家在其后台可以看到该笔订单，然后选择接单，进行菜品的制作和打包，等待骑手来取餐。以下信息不是我们案例中订单的信息，大家可以自行把本单信息填充到以下的商家账单信息中即可。从图中可以看出账单中展示了商品信息和数量、打包费、优惠信息以及优惠的承担方，如图 4-13 所示。

图 4-13 商家接单信息

图 4-14 骑手抢单列表

4.3.2 骑手配送

一个订单可以平台分配给骑手，也可以骑手自己抢单，有很多种方式；这里关于运力的调度和策略不过多赘述。

骑手在骑手端可以看到附近用户下的全部订单，并可以做出决策要不要枪这一单，对于骑手来说距离越短、挣得越多、肯定就越喜欢，抢单页如图 4-14 所示。

如果觉得这一单的配送费很高，还有奖励活动，那么可以点进去看一看，从地图里可以看出这一单的店铺在哪要配送到哪里，肯定是越近越好，目的地的单量越多越好，配送地图如图 4-15 所示。

图 4-15 骑手接单配送路程信息

在抢单详情页，骑手也可以看到这一单涉及到的菜品信息、详细的配送费信息等内容，便于骑手做要不要抢单的决策，如图 4-16 所示。

图 4-16 订单抢单详情页

骑手抢了订单后就可以去店里取餐了，同时用户在客户端也可以看到骑手的实时位置和配送状态，这样可以极大的缓解用户等待的焦虑。

订单变为待配送时，会生成服务订单，也就是配送订单，例如由骑手小王 01 抢单了，此时服务单信息如表 4-9 所示：

表 4-9：服务单信息

外卖单号	服务单号	状态	派单状态	配送员
11101	Fw11101	配送中	已匹配	小王 01

之后的过程包含了取餐、送餐、确认已送达、服务单完成等，服务单完成以后将订单推送至清算中心进行清分计算，以结清各方利益。

4.3.3 管控业务

整个交易过程中会存在各种的突发事件，比如用户把订单取消了、商家拒单了、骑手拒单改派了、骑手把用户的餐弄丢了等等，这时都需要进行一个判责的处理，是谁的责任，要不要罚钱，需不需要封禁等。

4.4 清算

用户下了单，商家制作了餐，骑手完成了配送，用户完成了评价，订单就正式完结了，过程中，如果发生了突发事件会被管控。每个环节都可能需要进行记账，而记账业务之前需要先完成计费和清分，比如完单以后商家佣金的计算、过程中骑手奖惩的计算、商家的结算收入、骑手的结算收入等计费业务，这就是接下来要介绍的清算业务。

4.4.1 费用

费用是业务层信息到账务层信息转换的非常关键的要素。交易过程中不同的节点、不同的对象、不同的菜品或者活动都会产生不同的费用，比如商家卖了一些菜品，属于商家的菜品费；平台为商家提供了交易平台和配送服务，所以平台也会收取商家的佣金，这样就需要一个佣金的费用。

同样，财务需要基于业务做会计记账，那么不能直接用业务数据直接入账，而是以费用视角入账，比如抽商家的佣金费转换为 “平台收入” 计入会计收入类科目。

这样我们就需要建立一个费用体系，业务的新增和变化，都需要针对性的建立相应的费用，每个费用也就有了其依赖的业务场景。而对于这一单外卖来说我们需要到如下的费用，如表 4-4 所示。

表 4-10 费用管理

费用	费用编号	费用名称
	1001	用户支付
	2002	商家菜品
	2003	商家结算收入
	2004	商家优惠补贴
	3005	平台补贴
	4006	骑手配送费
	2007	商家佣金
	4008	骑手奖励

4.4.2 清分

清算系统接收到的清算请求数据包含订单信息、账单信息、支付信息、履约信息等。在计费环节有几个关键的模块以及之间的关系如图 4-17。

图 4-17 计费模型

计费模型就是基于订单业务应该计算出什么样的费用出来，例如本单其实有 2 个业务，一个是外卖业务，一个是平台会员业务。计费模型是平台外卖业务需要计算商家应结算金额、抽佣金额、优惠分摊金额；平台会员计费模型需要计算出平台会员费。再基于业务类型，去查找对应的计费规则，即计费参数、计费基数、计费模式等；本单的计费规则和结果如表 4-11 所示。

表 4-11 计费规则和结果

费用计费结果	费用编号	费用名称	金额	算法
	1001	用户支付	36.00	取用户实付金额
	2002	商家菜品	55.00	取商家菜品原价
	2003	商家结算收入	17.00	商品总价 - 满减优惠 - 平台红包分摊 - 平台抽佣
	2004	商家优惠补贴	19.00	商家优惠总额
	3005	平台补贴	7.00	平台优惠总额
	4006	骑手配送费	7.00	配送费原价
	2007	商家佣金	4.00	商品总价 * 10%
	4008	骑手奖励	0.00	取骑手活动奖励计费结果

4.5 账务

整个交易过程都需要进行账务的记录，无论是用户支付了多少钱、菜品是多少钱还是优惠了多少钱，以及计费得到的应结商家收入和骑手配送收入，甚至是给商家、骑手代扣代缴的税费。

4.5.1 记账场景定义

我们知道记账是在整个交易过程中分多次记录的，用户支付成功以后要记账，商家接单以后要记账，骑手抢单以后要记账，完单以后要记账；这样我们就需要跟业务层约定业务场景的识别，而业务场景就对应了记账的场景。

根据业务的发生流程，这里应该包含正向及逆向、订单类、支付类、管控类、奖惩类、结算类等场景。我们将业务划分成这样的场景并给于定义，并且我们要约定好用什么信息去判定该场景已经发生，比如可以用订单状态，工单流转等标记业务事件，如表 4-12 所示。

表 4-12 业务场景定义

场景定义	场景	场景识别	识别值
	用户支付成功	订单状态	01 支付成功
	商家接单	订单状态	02 商家已接单
	骑手接单	服务单状态	03 骑手已接单
	骑手取餐	服务单状态	04 骑手已取餐
	确认送达	订单状态	05 已送达
	用户取消订单	订单状态	0101 订单取消成功
	骑手改派	运单状态	0203 改派成功
	用户投诉骑手成功	工单状态	0401 投诉判定有效
	骑手申诉成功	工单状态	0501 骑手申诉成功

4.5.2 记账设定

定义好了业务场景以及费用，就需要设定什么场景发生了需要记什么费用，这些费用要记哪些账，因为一个费用的发生不一定只记一笔账，可能要计入多个账户，我们需要设定每个类场景要记什么账。

当然每个场景发生以后记那些账不仅仅由订单状态这个场景决定，还需要其他要素参与，比如 01 支付成功，我们还需要知道这个是什么类型的订单，另外需要不需关注渠道，因为不同渠道的订单可能需要记跟渠道的分成，如表 4-13 所示。

表 4-13 场景与记账设定

场景与记账设定	场景	场景识别	识别值	记账
	用户支付成功	订单状态	01 支付成功	1001 用户支付
				3005 平台补贴
				30010 平台配送补贴
	商家接单	订单状态	02 商家已接单	2002 商家菜品
	商家接单	订单状态	02 商家已接单	2004 商家优惠补贴
	骑手接单	服务单状态	03 骑手已接单	略
	骑手取餐	服务单状态	04 骑手已取餐	略
	确认送达	订单状态	05 已送达	略
	用户取消订单	订单状态	0101 订单取消成功	略
	骑手改派	运单状态	0203 改派成功	略
	用户投诉骑手成功	工单状态	0401 投诉判定有效	略
	骑手申诉成功	工单状态	0501 骑手申诉成功	略

4.5.3 记账交互

业务场景发生以后，后端清分系统需要知道业务发生了，这里需要一个交互信息的方式，可以通过 MQ 的手段，比如订单支付成功了，订单层就发一个 MQ，清分系统监听到该 MQ 以后通过订单状态字段判断订单状态，如果是 “01” 就知道这是 “01 用户支付” 成功发生了。

如果该 MQ 里包含了记账需要的全部信息，则可以以 MQ 为依据生成业务单据，如果 MQ 内没有过多信息，就需要订单业务给一个查询数据的服务，比如查询接口或者 SQL，通过该服务获取记账需要的全部数据，如图 4-18 所示。

图 4-18 记账交互流程

4.5.4 记账规则

每个业务场景发生以后，需要记哪些账在上面已经完成设定。那么这些账怎么记呢？计给哪些对象，计入哪些账户呢？这就是记账规则的职能了，比如我们介绍 “01 支付成功” 以后的记账规则，如表 4-14 所示。

表 4-14 记账规则

记账规则	记账内容		业务记账			会计记账
	记账场景	记账费用	记账账户	金额	方向	分录规则
	01 支付成功	1001 用户支付	用户账户	取实付金额	-	借：科目 1 贷：科目 2
		1001 用户支付	平台账户	取实付金额	+	借：科目 1 贷：科目 2
		3005 平台补贴	补贴账户	略	-	借：科目 1 贷：科目 2
		3005 平台补贴	用户账户	略	+	借：科目 1 贷：科目 2
		30010 配送补贴	补贴账户	略	-	借：科目 1 贷：科目 2
		30010 配送补贴	用户账户	略	+	借：科目 1 贷：科目 2

有了规则以后，业务发生时就可以通过规则判定该场景需要记哪些账，然后获得相应的数据；获得数据以后先生成原始的业务凭证存下来，然后进行清分处理；这里记账单据我们按生成的先后顺序和依赖关系分成三类：业务凭证，清分明细，账户明细，会计凭证。

4.5.5 业务凭证

是业务发生后完成计费以后的最原始的数据，比如订单支付成功以后获得的记账数据存储在清分系统，这笔数据里包含了 “01 用户支付成功” 需要记账的全部信息，如表 4-15 所示。

表 4-15 业务凭证

订单号	订单状态	用户 ID	商品原价	总优惠	配送立减	平台补贴	支付时间
111	01	01212	62.00	-26.00	-5.00	-7.00	t

上面我们介绍了 “01 用户支付成功” 场景发生以后，我们需要记录 3 个费用“1001，,3005，,30010”，这样我们根据业务凭证的数据进行清分，并根据记账规则知道每个清分出的费用、金额、对象就有了，清分结果如表 4-16 所示。

表 4-16 清分明细

清分明细	识别值	费用	取值规则	总优惠	时间
	01 支付成功	1001 用户支付	取用户实付	-36.00	t
		3005 平台补贴	取平台补贴	-7.00	t
		30010 配送补贴	取配送立减金额	-5.00	t

4.5.6 账户流水

有了清分明细以后，我们就可以根据记账规则计入对应账户，更新账户余额，记录账户流水了，如图 4-19 所示。

图 4-19 记账流程

为了简单起见，这里只对商家的结算和骑手的结算进行记账，生成的账户流水，如表 4-17 所示。

表 4-17 账务流水明细

账务流水	费用项	金额	对象	收支	账户
zw01	商家结算款	17	牛小仙	收入	结算户
zw02	配送费	7	小王 01	收入	结算户

入账成功后，更新账户余额，账户余额信息如表 3-13 所示。

表 3-13：账户余额信息

主体	账户类型	余额	冻结	可用
牛小仙	商家结算户	1017.00	17.00	1000.00
小王 01	骑手结算户	2034.00	7.00	2027.00

4.6 结算

结算就是将应付商家和骑手的收入支付出去的过程，可以将商家和骑手的收入直接付款至他们的银行卡中，整个结算过程包括了计税、开票、结算处理、付款处理等过程。

4.6.1 税票

计税模式可以按照每个账务明细进行计税、也可以按照每个结算周期进行一次性计税；计税过程需要知道税种是什么、税基是什么、税率是多少等计税规则。

假如我们按照账务明细进行计税，也就是每入一笔账就需要计税；入账成功以后账务系统将入账明细推送给税务子系统，税务子系统根据税种、税基、税率等配置计算该笔入账的税额，并推送账务系统进行税务的扣除，这里要考虑平台是否需要代扣代缴，如果不需要代扣代缴就不需要进行税务的扣除，可以仅进行计算，提供给商家和骑手进行税务什么用，如图 4-20 所示。

图 4-20 税务流程

4.6.2 结算付款

按照约定我们需要完成给商家和骑手的结算，将商家的应收和骑手的收入打款给他们。不同的城市、不同的商家签订了不同的结算周期，例如日结、周结、月结；结算的依据可以是账户的当期余额，也可以是当期的账户流水；结算的方向可以是指定的平台虚拟账户或者生成结算单付款至指定银行卡。商家和骑手可以在钱包里看到账户余额，然后发起提现；生成提现订单，请求打款中心完成出款，整个清结算的流程框架如图 4-21 所示。