结算系统根据平台的业务模式不同，大致有2个设计方向，重点是要保证结算效率与时效，同时保证资金安全，不要出现重复结算及资金结算倒挂的问题。本文从亲身工作实践中，总结了O2O电商结算平台建设的实操与设计思路。
一、概述
1.什么是结算？
说结算平台之前，先说一下业务上的结算概念，结算顾名思义就是平台把系统计算好的资金结算给对应的供应商、分销员、劳动者等交易参与方，资金结算主要有2种结算方式：
第一种也是看起来最简单的：平台线下转账给被结算对象，业务前期阶段，业务量不大的时候这样运转还行，后续随着业务的起量，极大概率会出现结账周期时全员变财务/核算、打款出错、下游结算对象催打款等一系列问题。
2.结算平台的落地形态
上文解释了业务上结算的概念，技术上结算系统就是根据业务实际需要而搭建的实体化系统设施，通过系统化手段在线完成资金的打款发放。
结算平台与计费系统作为清结算体系中重要的组成部分，计费平台把订单的业务信息流转变成转化为资金信息流，结算平台把资金信息流转化成实实在在的结算资金流。
搭建结算平台的优点是结算平台可以制定统一的接入规范，各业务系统统一对接结算平台即可，无需再对接底层通道或账户中心，大大降低系统重复对接开发量。
注：可能会有人会说这种系统架构，平台涉及到“二清”问题，确实会涉及到，但大公司有牌照不会有这个问题，其他公司如果不是大额融资或者上市大概率也不会涉及到这个问题，个人觉得在公司体量没有到达一定级别前，不要太纠结这个点。
二、结算平台系统架构
系统架构1（O2O自营B2C电商）
系统架构2（类自营B2B电商）
当然以上2个系统架构也不是万能架构，算是比较通用的2种设计思路，但如果公司业务比较简单，可能都不需要分成2个系统，直接计费与结算放在一个系统就OK，每天念三遍：系统不重要，业务最重要。
系统交互流程说明：
以上2种系统架构，系统间整体交互流程很相近，第一步各业务系统的计费模块完成各种资金类型的清算计费，根据清算结果生成结算单，完成结算单调整确认后，请求结算平台统一结算接口，结算系统根据业务侧所需结算方式，请求底层支付平台或帐户中心接口，完成账户中心入账或通道打款，下文也会详细说明。
小结：结算模块的整体系统架构大同小异，具体采用什么样的系统架构一定要根据平台自身的业务需要，整体原则是：以满足业务为前提，追求系统通用，防止重复造轮子。
三、结算平台系统搭建
下文主要从4方面展开：业务流程、系统交互流程、页面原型及核心规则、关键接口说明。
1.业务流程
上图为O2O自营B2C电商劳动者薪资报酬结算业务流程，首先说下这个流程不是通用的，各平台可根据自身提供服务的标准化程度及履约复杂度灵活调整，例如滴滴与外卖配送是非常标准的O2O服务，结算环节不需要审核，直接结算即可，但比较复杂的家政服务与互联网装修服务，肯定会加上比较多审核确认环节。
2.系统间交互流程
上图是各业务系统与结算系统间的交互流程，这里的业务系统包括不限于各业务线计费系统、劳动者奖惩系统、分销平台等等。
此架构下，各业务系统与结算系统的交互相对比较简单，业务系统只需要传输对应金额、结算渠道等核心参数，结算系统请求下游系统即可。
3.页面原型及核心规则
以O2O自营B2C电商的系统架构为基础的结算系统，页面原型相对不会太多，因为主要系统模块都已经被上游业务计费系统承担，忘记的可以去看下计费系统搭建的内容回顾下，原型主要分为2部分：
平台侧：费用类型管理、结算规则配置、结算记录如下图：
（1）费用类型管理
费用类型的含义及作用：费用类型表象上就是结算资金的名称，简单来说这就是是一笔什么钱，再往上抽象一层，1个费用类型代表了业务的1个计费场景，对应了一个具体的计费规则（前提是费用类型颗粒度要足够细化）。
他们之间的关系如下图简单举例：
费用类型的命名原则：简短同时要能反映费用的业务属性，账户中心记账的时候，账务流水就会很清楚，劳动者可以很直观地就知道这笔钱的因为什么进来，这笔钱为什么被扣掉，如下图所示：
费用类型在系统间流转过程：当上游业务侧新增一个计费场景时，结算系统会新增1个费用类型，具体新增费用类型的运营流程，看自己公司要求，结算系统配置完成后，将费用类型编码同步至业务侧，业务系统需要将此编码维护在系统中。
当此费用类型的资金进行结算时，需要传费用类型编码ID，同时如果需要结算到账户中心，则账户中心也需要同步添加费用类型编码，因为账户中心需要根据费用类型编码确定入到哪个账户中，流程如下图：
（2）结算规则管理
从上图可以看到，一个费用类型可以配置多条结算规则，但业务系统请求结算系统接口时，会根据业务线匹配唯一结算规则，防止重复结算，若结算时未匹配到结算规则，系统会直接报错。
有一个点需要注意的是，如果平台内资金结算渠道只有一种，所有的费用类型都只结算到银行卡或者平台账户，则不需要配置结算规则，直接系统写死即可，甚至可以不要单独做结算系统，没有意义，因为此系统架构下结算单生成/审核/调整都已经与计费模块融合，由计费系统（不仅仅是计费）直接请求底层通道或者账户中心即可。
归根结底一句话：视自己平台真实业务需要，做对应系统建设，忌自嗨、忌华而不实。
（3）结算记录
4.关键接口设计
1.结算业务流程（类自营电商B2B）
这个系统架构与系统架构一（O2O自营B2C）业务流程比较大的区别在于，因为业务模式与结算金额（多笔合并结算、大额）的原因，结算单审核/调整成为了一个必要流程，并且部分平台还会涉及到开票流程。
开票流程又分为2种：
第1种：先开票后结算（上图），即商户侧根据平台推送的结算单开具发票并上传，平台发票审核通过后，方可进行实际资金结算流程，这个方案的好处是优先保证平台的利益，同时也降低了结算单与发票金额数据不一致的概率（结算单金额与发票金额），降低后续运营与商户的人力负担。
第2种：开票与结算相互独立，无明确先后流程，好处是可以保证结算时效，商户侧的资金回款效率与结算体验更好，坏处就是上个流程中的好处，大家可以根据自身平台需要选择合适的方案。
2.结算系统间交互流程（类自营电商B2B）
上图是类自营B2B电商结算系统交互流程，我用的是计费模块和结算模块，而不是系统，因为他俩可以放在一个系统，特别是业务线不多，计费模式与结算类型都比较单一的平台，完全没有必要做2个系统。
还有另一个方案：进入到下一账期即生成结算单，举例：T月账期过去，进入到T+1月1号即生成T+1月的结算单，数据清算完成即填充数据至结算单，只是这个结算单不会推到商户后台，只在平台侧展示，但是账单的总额数据可以展示给商户侧，以便让商户知道自己T+1月的数据概览情况。
此系统架构下，平台侧页面原型主要分为计费管理、结算单管理、发票管理，计费管理主要是完成订单资金计费，生成清算明细数据，上一篇计费系统从0到1搭建已经详细介绍过，不再赘述。
（1）结算单管理
关于原型图和规则主要说几个点：
上图中三个状态字段的关系：结算单状态、发票状态、结算状态，3个状态依赖与先后关系如下图所示：
结算单导出内容：因为对公结算多是汇总轧差结算，所以结算单导出后是一条条计费明细，包括正向与逆向数据，最常见的结算单就是三方支付机构给的结算对账文件，结算单导出后如下图所示，可以根据自身需要增删字段：
结算风控：一是结算系统要防止资金倒挂，即结算单中各订单累计金额要大于等于结算金额，做兜底，二是防止订单逆流程带来的资金损失风险，例如平台承诺7天无理由退货，如果账期是5天，会存在资金已经结算至商家，即便扣除商家保证金，退款资金仍然不够的风险。
解决方案有几个方向：限制结算账期、限制结算金额（有风险的结算金额不能超过保证金兜底的金额）、入驻合同中约定好商户资金不足，平台垫资的资金怎么处理，可以根据平台实际情况选择对应方案。
（2）发票管理
说明：结算单审核通过后，商家在后台上传发票图片，财务在平台侧【发票管理】完成发票审核/核销，没问题后结算模块请求底层账户中心或支付平台完成资金结算，同时商家侧快递纸质发票至平台，如果做的再完善些，平台还可以对接快递的接口，可以在后台查看快递进度。
4.关键接口说明
接口部分与上文的O2O自营B2C电商的系统架构很相似，直接看上文即可，不再赘述。
四、总结
结算系统根据平台的业务模式不同，大致有我上文中的2个设计方向，整体复杂度可控，重点要保证结算效率与时效，同时保证资金安全，不要出现重复结算及资金结算倒挂的问题。
本文由@鲸爷陆原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。