结算系统根据平台的业务模式不同，大致有2个设计方向，重点是要保证结算效率与时效，同时保证资金安全，不要出现重复结算及资金结算倒挂的问题。本文从亲身工作实践中，总结了O2O电商结算平台建设的实操与设计思路。

一、概述

我们最开始分享了O2O电商支付清结算体系，接着分享了如何从0-1搭建计费体系，接下来我们分享：各方的钱算完之后怎么付出去，也即结算平台建设的实操与设计思路。

1.什么是结算？

说结算平台之前，先说一下业务上的结算概念，结算顾名思义就是平台把系统计算好的资金结算给对应的供应商、分销员、劳动者等交易参与方，资金结算主要有2种结算方式：

第一种也是看起来最简单的：平台线下转账给被结算对象，业务前期阶段，业务量不大的时候这样运转还行，后续随着业务的起量，极大概率会出现结账周期时全员变财务/核算、打款出错、下游结算对象催打款等一系列问题。

第二种也就是本次要分享的：通过系统手段，线上自动打款给下游结算对象，根据实际业务的需要，线上又可以打款至微信、支付宝、银行卡（对公/对私）、平台账户，线上结算搭建完之后，可以把结算能力放给所有的业务线复用。

2.结算平台的落地形态

上文解释了业务上结算的概念，技术上结算系统就是根据业务实际需要而搭建的实体化系统设施，通过系统化手段在线完成资金的打款发放。

结算平台与计费系统作为清结算体系中重要的组成部分，计费平台把订单的业务信息流转变成转化为资金信息流，结算平台把资金信息流转化成实实在在的结算资金流。

在多业务线、多种结算类型的平台中，结算平台可以做成通用的中台系统，单纯作为资金出款的统一出口，至于结算到平台账户还是微信/支付宝零钱，又或者是银行卡账户，都依赖于业务侧计费系统的通知，结算平台只是执行结算指令（如上图所示），同时做好资金风控兜底，防止资金结算倒挂。

搭建结算平台的优点是结算平台可以制定统一的接入规范，各业务系统统一对接结算平台即可，无需再对接底层通道或账户中心，大大降低系统重复对接开发量。

注：可能会有人会说这种系统架构，平台涉及到“二清”问题，确实会涉及到，但大公司有牌照不会有这个问题，其他公司如果不是大额融资或者上市大概率也不会涉及到这个问题，个人觉得在公司体量没有到达一定级别前，不要太纠结这个点。

后续也会分享平台“二清”的解决产品方案，可以期待下。

二、结算平台系统架构

不同公司根据业务模式与技术组织架构的不同，所适合的结算系统间架构也不同，在这分享自己参与过的也是比较常见的2个系统架构，详见下图：

系统架构1（O2O自营B2C电商）

说明：上图是我们当前正在用的结算系统架构，因为公司存在多条业务线，且不同业务线在完成订单清算后流程不同，有的需要平台进行结算单调整/审核，有的业务线则不需要，所以结算调整/审核相关的模块，统一放到了业务侧，结算系统最终只负责结算打款的职能，作为一个资金出款的前置通用系统，放在中台体系内，各业务系统统一对接结算平台。

系统架构2（类自营B2B电商）

说明：上图是我之前公司经历过另一种系统架构，与图1的区别除了需要发票相关的模块（灰色）之外，最大的区别就是把结算单调整/审核相关的功能，统一放到了结算模块中，因为所有的业务线关于清算之后的流程是相同的，可以抽象为一个统一的模块，计费模块单纯完成费用计算即可。

当然以上2个系统架构也不是万能架构，算是比较通用的2种设计思路，但如果公司业务比较简单，可能都不需要分成2个系统，直接计费与结算放在一个系统就OK，每天念三遍：系统不重要，业务最重要。

系统交互流程说明：

以上2种系统架构，系统间整体交互流程很相近，第一步各业务系统的计费模块完成各种资金类型的清算计费，根据清算结果生成结算单，完成结算单调整确认后，请求结算平台统一结算接口，结算系统根据业务侧所需结算方式，请求底层支付平台或帐户中心接口，完成账户中心入账或通道打款，下文也会详细说明。

小结：结算模块的整体系统架构大同小异，具体采用什么样的系统架构一定要根据平台自身的业务需要，整体原则是：以满足业务为前提，追求系统通用，防止重复造轮子。

三、结算平台系统搭建

上文我们分享了结算平台的系统架构，接下来分享怎么从0到1真正落地搭建起1个结算平台，我接下来会把上文中的2种系统架构，都展开说下，2者可以互相结合着看。

下文主要从4方面展开：业务流程、系统交互流程、页面原型及核心规则、关键接口说明。

系统架构1（O2O自营B2C电商）

1.业务流程

上图为O2O自营B2C电商劳动者薪资报酬结算业务流程，首先说下这个流程不是通用的，各平台可根据自身提供服务的标准化程度及履约复杂度灵活调整，例如滴滴与外卖配送是非常标准的O2O服务，结算环节不需要审核，直接结算即可，但比较复杂的家政服务与互联网装修服务，肯定会加上比较多审核确认环节。

2.系统间交互流程

上图是各业务系统与结算系统间的交互流程，这里的业务系统包括不限于各业务线计费系统、劳动者奖惩系统、分销平台等等。

此架构下，各业务系统与结算系统的交互相对比较简单，业务系统只需要传输对应金额、结算渠道等核心参数，结算系统请求下游系统即可。

3.页面原型及核心规则

以O2O自营B2C电商的系统架构为基础的结算系统，页面原型相对不会太多，因为主要系统模块都已经被上游业务计费系统承担，忘记的可以去看下计费系统搭建的内容回顾下，原型主要分为2部分：

平台侧：费用类型管理、结算规则配置、结算记录如下图：

（1）费用类型管理

因为后续分享账户中心的时候也会用到费用类型，这次先重点说下:

费用类型的含义及作用：费用类型表象上就是结算资金的名称，简单来说这就是是一笔什么钱，再往上抽象一层，1个费用类型代表了业务的1个计费场景，对应了一个具体的计费规则（前提是费用类型颗粒度要足够细化）。

他们之间的关系如下图简单举例：

• 业务场景：费用类型=1：1或1：N
• 费用类型：计费场景/规则=1：1

费用类型的命名原则：简短同时要能反映费用的业务属性，账户中心记账的时候，账务流水就会很清楚，劳动者可以很直观地就知道这笔钱的因为什么进来，这笔钱为什么被扣掉，如下图所示：

费用类型在系统间流转过程：当上游业务侧新增一个计费场景时，结算系统会新增1个费用类型，具体新增费用类型的运营流程，看自己公司要求，结算系统配置完成后，将费用类型编码同步至业务侧，业务系统需要将此编码维护在系统中。

当此费用类型的资金进行结算时，需要传费用类型编码ID，同时如果需要结算到账户中心，则账户中心也需要同步添加费用类型编码，因为账户中心需要根据费用类型编码确定入到哪个账户中，流程如下图：

（2）结算规则管理

结算规则说明：费用类型新增之后，需要为费用类型配置结算规则，结算规则的主要作用是确定此费用类型的结算渠道，即结算到劳动者的微信零钱还是银行卡，亦或是平台账户中，如果要结算到平台账户，还需要在账户中心配置此费用类型的入账规则及冻结规则，确定费用类型入到哪个账户及要不要冻结，流程见下图：

从上图可以看到，一个费用类型可以配置多条结算规则，但业务系统请求结算系统接口时，会根据业务线匹配唯一结算规则，防止重复结算，若结算时未匹配到结算规则，系统会直接报错。

有一个点需要注意的是，如果平台内资金结算渠道只有一种，所有的费用类型都只结算到银行卡或者平台账户，则不需要配置结算规则，直接系统写死即可，甚至可以不要单独做结算系统，没有意义，因为此系统架构下结算单生成/审核/调整都已经与计费模块融合，由计费系统（不仅仅是计费）直接请求底层通道或者账户中心即可。

归根结底一句话：视自己平台真实业务需要，做对应系统建设，忌自嗨、忌华而不实。

（3）结算记录

O2O电商结算有一个特点，都是按订单逐笔结算，即劳动者完成服务，工资报酬即结算至平台账户，然后各平台根据各自业务需要，设置提现窗口期或设置冻结时间。

上述原型图中有两个字段特殊说明下：

• 一是【订单号】，逐笔结算的结算记录一定要加上订单号，运营有问题找过来的时候，大多数只发个订单号过来，同理账户中心也要加订单号（有的话）。
• 二是【结算状态】，要以最底层出款通道或账户中心的最终入账结果为准，不能业务系统请求结算系统接口成功了就返回上游系统结算成功，可以异步通知慢点儿，不然可能会造成上游业务系统显示的结算结果有误。

4.关键接口设计

结算系统最核心的就是结算的接口，各业务系统请求此接口，完成资金的打款结算，下图是接口入参必填参数，根据结算渠道的不同，业务系统需要传对应参数进来，例如结算到微信要传openid、结算到银行卡要传银行卡号、开户行等等，这个直接看底层通道需要什么参数即可，不再赘述。

系统架构2（类自营B2B电商）

1.结算业务流程（类自营电商B2B）

这个系统架构与系统架构一（O2O自营B2C）业务流程比较大的区别在于，因为业务模式与结算金额（多笔合并结算、大额）的原因，结算单审核/调整成为了一个必要流程，并且部分平台还会涉及到开票流程。

开票流程又分为2种：

第1种：先开票后结算（上图），即商户侧根据平台推送的结算单开具发票并上传，平台发票审核通过后，方可进行实际资金结算流程，这个方案的好处是优先保证平台的利益，同时也降低了结算单与发票金额数据不一致的概率（结算单金额与发票金额），降低后续运营与商户的人力负担。

第2种：开票与结算相互独立，无明确先后流程，好处是可以保证结算时效，商户侧的资金回款效率与结算体验更好，坏处就是上个流程中的好处，大家可以根据自身平台需要选择合适的方案。

2.结算系统间交互流程（类自营电商B2B）

上图是类自营B2B电商结算系统交互流程，我用的是计费模块和结算模块，而不是系统，因为他俩可以放在一个系统，特别是业务线不多，计费模式与结算类型都比较单一的平台，完全没有必要做2个系统。

单独说一下结算单生成的时间点，比较常见的方案是：根据约定的账期，在账单日通过凌晨定时任务生成本账期结算单。

还有另一个方案：进入到下一账期即生成结算单，举例：T月账期过去，进入到T+1月1号即生成T+1月的结算单，数据清算完成即填充数据至结算单，只是这个结算单不会推到商户后台，只在平台侧展示，但是账单的总额数据可以展示给商户侧，以便让商户知道自己T+1月的数据概览情况。

3.页面原型及核心规则

此系统架构下，平台侧页面原型主要分为计费管理、结算单管理、发票管理，计费管理主要是完成订单资金计费，生成清算明细数据，上一篇计费系统从0到1搭建已经详细介绍过，不再赘述。

商户侧后台主要有结算记录与发票管理2个功能模块，模块展示的信息和平台侧基本一致，大家可以直接看平台侧相关原型内容，也不再赘述。

（1）结算单管理

关于原型图和规则主要说几个点：

上图中三个状态字段的关系：结算单状态、发票状态、结算状态，3个状态依赖与先后关系如下图所示：

结算单导出内容：因为对公结算多是汇总轧差结算，所以结算单导出后是一条条计费明细，包括正向与逆向数据，最常见的结算单就是三方支付机构给的结算对账文件，结算单导出后如下图所示，可以根据自身需要增删字段：

结算单生成规则：以商户为纬度，以账期为时间范围，把发生在此账期范围的所有费用类型的计费明细数据写入商家对应结算单中。

结算风控：一是结算系统要防止资金倒挂，即结算单中各订单累计金额要大于等于结算金额，做兜底，二是防止订单逆流程带来的资金损失风险，例如平台承诺7天无理由退货，如果账期是5天，会存在资金已经结算至商家，即便扣除商家保证金，退款资金仍然不够的风险。

解决方案有几个方向：限制结算账期、限制结算金额（有风险的结算金额不能超过保证金兜底的金额）、入驻合同中约定好商户资金不足，平台垫资的资金怎么处理，可以根据平台实际情况选择对应方案。

（2）发票管理

说明：结算单审核通过后，商家在后台上传发票图片，财务在平台侧【发票管理】完成发票审核/核销，没问题后结算模块请求底层账户中心或支付平台完成资金结算，同时商家侧快递纸质发票至平台，如果做的再完善些，平台还可以对接快递的接口，可以在后台查看快递进度。

4.关键接口说明

接口部分与上文的O2O自营B2C电商的系统架构很相似，直接看上文即可，不再赘述。

四、总结

结算系统根据平台的业务模式不同，大致有我上文中的2个设计方向，整体复杂度可控，重点要保证结算效率与时效，同时保证资金安全，不要出现重复结算及资金结算倒挂的问题。

未完待续，下一篇分享《从0到1搭建账户中心》。