一、概述

我们首先分享了O2O电商支付结算系统，然后分享了如何从0-1搭建计费系统，然后我们分享：钱算完之后如何给各方付款，也就是结算的实操操作平台建设和设计思路。

1.什么是结算？

在讲结算平台之前，我们先来说说业务中的结算概念。 顾名思义，结算就是平台将系统计算出的资金结算给相应的供应商、经销商、工人等交易参与者。 资金结算主要有两种结算方式：

第一个也是最简单的：平台线下向结算对象转账。 业务初期，业务量不大的时候效果还不错。 后期随着业务量的增加，大概率会出现结算周期。 存在全员财务/会计变更、支付错误、下游结算对象催付等一系列问题。

第二种就是我这次要分享的：通过系统手段，可以自动向下游结算对象进行在线支付。 根据实际业务需求，可支持微信、支付宝、银行卡（企业/私人交易）等在线支付。 ）、平台账户，在线结算建立后，结算能力可被各业务线复用。

2、结算平台实施形式

以上解释了业务结算的概念。 从技术上讲，结算系统是根据业务实际需要构建的物理系统设施。 它通过系统化手段在线完成资金的支付和分配。

结算平台和计费系统是清算结算系统的重要组成部分。 计费平台将订单的业务信息流转换为资金信息流，结算平台将资金信息流转换为真正的结算资金流。

在多业务线、多种结算类型的平台中，结算平台可以做成通用的中台系统，简单地作为资金拨付的统一出口。 至于结算到平台账户，还是微信/支付宝找零，或者是银行卡账户。 ，全部依赖于业务方计费系统的通知。 结算平台仅执行结算指令（如上图所示），同时做好资金风险控制，防止资金结算被逆转。

建设结算平台的好处是结算平台可以制定统一的接入规范，所有业务系统都可以统一接入结算平台。 无需连接底层渠道或账户中心，大大减少了系统重复对接开发量。

注：有人可能会说，这种系统架构和平台涉及到“二次清零”问题。 确实会涉及到，但是有牌照的大公司不会有这个问题，其他公司融资也不大，上市概率也不大。 就说到这个问题了。 我个人认为，在公司达到一定水平之前，你不应该太纠结这一点。

未来我们还将分享平台“二次清零”的产品解决方案，敬请期待。

2. 结算平台系统架构

不同的企业根据不同的业务模式和技术组织结构，有不同的结算系统架构。 分享一下我参与过的两个常见的系统架构，具体见下图：

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

注：上图是我们目前使用的结算系统架构。 由于公司有多条业务线，不同业务线完成订单清算后的流程不同，有的要求平台调整/审核结算单据，有的则要求不需要，所以结算调整/审核相关的模块统一在平台上业务方面。 结算系统最终只负责结算和支付的功能。 作为资金拨付的前端通用系统，置于中台系统与各业务系统统一对接结算平台。

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

注：上图是我之前公司经历过的另一个系统架构。 与图1不同的是，除了发票相关模块（灰色）外，结算单据调整/审核相关的功能统一到了结算模块中，因为所有业务条线结算后的流程都是一样的，所以可以抽象成统一的模块，计费模块只是完成费用计算。

当然，上述两种系统架构并不是通用的架构。 这是两种比较常见的设计思路。 但如果公司业务比较简单，可能不需要分成两个系统。 将计费和结算直接放到一个系统中就可以了。 每天阅读此内容。 三遍：系统不重要，业务最重要。

系统交互流程说明：

上述两种系统架构的整体交互过程非常相似。 第一步，各业务系统的计费模块完成各类资金的清算和计费，根据清算结果生成结算单，完成结算单的调整和确认后请求结算。 平台有统一的结算接口。 结算系统根据业务侧所需的结算方式向底层支付平台或账户中心接口请求，完成账户中心入账或通道支付。 这将在下面详细解释。

总结：结算模块整体系统架构类似。 具体采用何种系统架构，必须根据平台本身的业务需求而定。 总体原则是：以满足业务为前提，追求系统通用性，防止重复发明轮子。

3、结算平台系统结算

上面我们分享了结算平台的系统架构。 接下来我们就分享一下如何从0到1搭建一个结算平台。接下来我会针对上面提到的两个系统架构进行展开。 两者可以相互作用。 一起来看看吧。

下面主要从业务流程、系统交互流程、页面原型及核心规则、关键接口描述四个方面进行阐述。

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

1.业务流程

上图为O2O自营B2C电商员工工资结算业务流程。 首先，这个过程并不通用。 各平台可根据其提供服务的标准化程度以及合同履行的复杂程度进行灵活调整。 比如滴滴、外卖都是非常标准的O2O服务，结算流程不需要审核，可以直接结算。 但对于更复杂的家政服务和互联网装修服务，肯定会增加更多的审核和确认步骤。

2. 系统间交互过程

上图展示了各业务系统与结算系统的交互流程。 这里的业务系统包括但不限于各业务条线的计费系统、劳动奖惩系统、配送平台等。

在这种架构下，各业务系统与结算系统之间的交互比较简单。 业务系统只需传输对应金额、结算通道等核心参数，结算系统向下游系统请求。

3. 页面原型及核心规则

基于O2O自营B2C电商系统架构的结算系统，页面原型相对较少，因为主要系统模块已被上游业务计费系统接管。 如果忘记了，可以查看计费系统建设的内容。 回顾一下，原型主要分为2部分：

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

（一）费用类型管理

因为后面分享账户中心的时候也会用到费用类型，所以这次重点介绍一下：

费用种类的含义和作用：从表面上看，费用种类是结算资金的名称。 简单来说，这就是什么样的钱。 往上一层抽象，一种费用类型代表业务的一种计费场景，对应建立具体的计费规则（前提是费用类型粒度必须足够细）。

它们之间的关系如下：

费用类型命名原则：简洁，体现费用的业务属性。 当账务中心记账时，账务流程就会非常清晰，工作人员可以直观地知道钱为什么进来、钱是什么。 为何被扣除如下图所示：

费用类型在系统间的转移流程：当上游业务侧新增计费场景时，结算系统中会添加新的费用类型。 新费用类型的具体操作流程取决于贵公司的要求。 结算系统配置完成后，将费用类型代码同步到业务侧，业务系统需要在系统中维护此代码。

该费用类型资金结算时，需要传递费用类型代码ID。 同时，如果需要向账户中心进行结算，账户中心还需要同时添加费用类型代码，因为账户中心需要根据费用类型代码来确定存入哪个账户。 ，流程如下：

(2)结算规则管理

结算规则说明：添加费用类型后，需要为该费用类型配置结算规则。 结算规则的主要作用是确定该费用类型的结算渠道，即结算到职工微信零钱或银行卡，或者结算到平台账户，如果要结算到平台账户，也可以需要在账户中心配置该费用类型的记账规则和冻结规则，以确定该费用类型记入哪个账户以及是否冻结。 流程如下图所示：

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

需要注意的是，如果平台只有一个资金结算通道，且所有费用类型都只结算到银行卡或平台账户，则无需配置结算规则，直接写入系统即可，或者即使将它们分开构建结算系统也没有任何意义，因为在这种系统架构下，结算单生成/审核/调整已经与计费模块集成在一起，计费系统（不仅仅是计费）可以直接请求底层通道或账户中心。

底线是：考虑平台的真实业务需求，构建相应的系统，避免自我放纵或华而不实。

（三）结算记录

O2O电商结算的一个特点是按订单结算，即当工人完成服务后，工资报酬结算到平台账户，然后各平台设定提现窗口期或根据自身业务需求冻结时间。

上面的原型图中有两个字段需要特别说明：

4、按键界面设计

结算系统的核心是结算接口。 各业务系统都请求该接口来完成资金的支付和结算。 下图显示了该接口所需的参数。 根据结算渠道的不同，业务系统需要传入相应的参数，例如结算等。 转账到微信，结算到银行卡，需要转账银行卡号、开户银行等，这个只是看底层通道需要什么参数，就不详细说了。

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

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

该系统架构与系统架构一（O2O自营B2C）业务流程最大的区别在于，由于业务模式和结算金额（多次合并结算、金额较大）的原因，结算单据审核/调整成为必经流程。 而且有些平台还会涉及到开票流程。

开票流程分为2种：

类型一：先开票后结算（如上图），即商户根据平台推送的结算单开具发票并上传。 平台发票审核通过后，即可进行实际的资金结算流程。 该方案的优点是优先考虑平台。 也降低了结算单与发票金额（结算单金额与发票金额）数据不一致的概率，减轻了后续操作和商户的人力负担。

类型2：开票和结算相互独立，没有明确的流程顺序。 优点是可以保证结算时效，商户侧的资金回收效率和结算体验较好。 缺点是前面流程的好处是可以根据自己的平台需求进行定制。 选择正确的解决方案。

2、结算系统之间的交互流程（类似自营电商B2B）

上图是一个自营B2B电商结算系统的交互流程。 我用计费模块和结算模块来代替系统，因为它们可以放在一个系统中，特别是业务线不多，而且计费模型和结算类型比较单一的平台，绝对没有。需要构建两个系统。

我们单独说一下结算单生成的时间点。 比较常见的解决方案是在计费日凌晨按照约定的记账周期通过定时任务生成该账期的结算报表。

还有一种解决方案：进入下一个会计期间时，会生成结算单。 例如：T月会计期间过后，输入T+1月1时，将生成T+1月的结算单。 数据清算完成后，数据会被填写到结算单中，但该结算单不会推送到商户后台，只会在平台端显示。 但可以向商户端展示总账单数据，以便商户了解其T+1个月的数据概况。

3. 页面原型及核心规则

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

商户侧后台主要有两个功能模块：结算记录和发票管理。 模块中显示的信息与平台侧基本相同。 可以直接看平台端的相关原型内容，无需赘述。

（一）结算单据管理

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

上图中三个状态字段的关系：结算单状态、发票状态、结算状态。 三种状态的依赖关系和顺序如下图所示：

结算单导出内容：由于企业结算多为净额结算，因此结算单将账单明细一一导出，包括正向和反向数据。 最常见的结算形式是第三方支付机构提供的结算对账文件。 ，导出结算单如下图所示。 您可以根据需要添加或删除字段：

结算单生成规则：以商户为纬度，以账户周期为时间范围，将该账户周期内发生的所有费用类型的详细计费数据写入该商户对应的结算单中。

结算风险控制：首先，结算系统必须防止资金逆转，即结算单中每笔订单的累计金额必须大于或等于结算金额，这样才安全。 其次，要防范订单逆流造成的资金损失风险。 比如平台承诺7天无理由退换。 对于退货，如果账期为5天，存在资金已结算给商户的风险，即使扣除商户押金，退款资金仍不够。

解决办法有几种：限制结算期限、限制结算金额（有风险的结算金额不能超过保证金金额）、在结算合同中约定商户资金不足。 平台垫付的资金如何处理可根据平台实际情况而定。 根据情况选择解决方案。

(2) 发票管理

注：结算单审核通过后，商户在后台上传发票图片，财务部门在平台端【发票管理】完成发票审核/核销。 如果没有问题，结算模块请求底层账户中心或支付平台完成资金结算，同时商户方将纸质发票发送至平台。 如果做得更完善的话，平台还可以连接快递接口，后台可以查看快递进度。

4. 按键接口说明

界面部分与上面O2O自营B2C电商的系统架构非常相似。 只看上面的内容，不做详细介绍。

4. 总结

根据平台的业务模式不同，结算系统一般有上述两个设计方向。 总体复杂度是可控的。 重点是保证结算效率和及时性，同时保证资金安全，避免重复结算和资金倒挂问题。