本文所述的是一套并不复杂的O2O商家薪资结算系统，对于不同的业务类型、不同的业务阶段有一定的适用性。希望能抛砖引玉，带给读者一定的启发。

一个O2O业务涉及到用户、平台和商家（服务提供者）三方。

用户在平台下单后，平台将订单派送给商家，由商家给用户提供服务，服务完成后用户和商家各自进行确认，之后用户将服务款支付到平台并且对服务进行评价/提出售后。

根据商家的服务情况、平台的运营规则等，平台可能会对商家进行一定的惩罚或者奖励。

之后，平台会按照一定的账期给商家结算薪资。

以上均完成，商家才可以从资金池中提现。

01 为什么需要薪资结算系统

从上面的业务流程我们可以看到，平台并不是简单地将用户支付的服务款直接转给商家，也不是将服务费直接和商家分润，而是通过更加复杂的业务逻辑来分蛋糕。通过对服务费的合理分配，平台需要达到以下几点目标：

• C端用户的拉新/维系
• B端商家的拉新/维系
• 平台收入增长
• 对商家服务质量进行管控

对于C端用户的拉新和维系，可以通过一系列运营活动来实现。例如：新客优惠券、老客优惠券、会员卡优惠、活动优惠等。

那么，用户支付的服务费用可能会包含以下成分：

• 优惠券/代金券
• 活动优惠
• 账户余额支付
• 现金/三方支付/银行卡

对于B端商家的拉新和维系，同样是通过平台不定期的运营手段实现，比如：介绍其他商家入职、满单奖励等。而对于商家服务质量进行控制，则是通过奖惩来实现。

这就会导致商家收到的薪资包含或者扣减多种成分：

• 订单支付收入
• 补贴（餐补、交通补贴）
• 奖金
• 罚款
• 信息服务费（由平台收取）
• 保险费（平台收取后代为缴纳）
• 薪资补漏（如前月漏发则补）

平台要盈利，就必须从订单中截留一部分作为信息服务费作为佣金。此外，O2O的商家往往与平台签订劳务合同，平台为了让商家在提供服务过程中更有保障——同时也是为了规避风险——会为商家购买人身安全保险，这部分资金也需要截留。

正常来说，薪资的结算也是资金结算，是应该放到结算系统中实现的（如果业务线少且复杂程度不高，这样处理也是可以的）。

但是结算系统主要是用来给财务打款的，而薪资结算的部分规则是由各条业务线自己进行把控的。如果业务线过多、太复杂，不论是从使用权限上看，还是从系统解耦上看，都不适合将薪资结算和结算系统放在一块。

另一方面，虽然不同的业务线对于上面说的“分蛋糕”有不同的逻辑，而且每条业务线有自身的发展节奏和财务预算，不可能用一个分配逻辑来完成全部的分配，但是考虑到资金的安全性以及避免各条业务重复造轮子，也应该将薪资结算与更靠前的业务系统分离开。

所以，薪资结算系统可以作为一个介于业务侧系统和结算系统中间的系统而存在，根据业务发展的实际情况来决定放在哪一侧或者是独立。

为了保证资金的安全以及打款的规范，在薪资系统完成结算后并不能真正完成打款。薪资结算的请求会通过清结算系统，有需要的话还需要财务进行核对和审批，完成以上步骤后才会经过支付渠道将薪资转入商户的账户中。

02 薪资结算系统的架构

一个简单、通用的薪资结算系统包含这些部分。

• 订单交易：接收来自个业务线的已完成的订单，汇总订单的费用情况，记录商家的待付费用。
• 奖惩管理：记录商家的奖惩信息。在需要手工调整时，由运营人员通过线下导入的方式完成对商家的奖惩。
• 资金池管理：商家资金情况；发起提现操作，财务/运营人员审批，然后通过支付系统付款并从商家账户中扣除已提现金额。
• 薪资统计：按月统计商家的订单收入、补贴收入、扣除费用、奖惩费用等信息。
• 账户流水：记录商家的待付收入(包括订单收入、奖惩、补贴)进账和出账(商家提现等)，记录流水明细。

下图是推送订单进入薪资结算系统的流程图。订单来自于各条业务线的系统，获取到的订单信息主要有：订单id、商家id、城市id、服务类别、服务时间、服务总费用、退款金额、现金支付金额、会员支付金额、三方支付金额（微信支付宝等）、代金券支付金额、优惠券优惠金额、原价、活动价、活动优惠、抽佣比例、抽佣费用、保险费、各项补贴金额（餐补、交通补贴等）、信息费、信息费减免等。其中需要注意保险费是从每一笔订单中提取的（电商的运费险也是绑定到每一笔订单），和常见的人身保险按照时间段投保略有不同。

后台Web页面中的订单管理模块，主要是对薪资系统获取的订单进行展示和查询，参考原型设计如下。

2. 奖惩管理

在互联网各个分类中，O2O业务是很重线下运营的。平台运营人员没法通过系统知道商家在现场服务时到底发生了什么事情。往往需要电话联系用户和商家，由双方分别提供现场照片才能了解情况。特别是在处理用户投诉时，需要进行多次沟通，通过线下协商完成处理。另一方面，在前期业务探索期，对于商家的奖惩可能存在灵活调整的问题，需要运营进行经常性操作。即便业务成熟、奖惩机制固定，部分奖惩可以通过用户/商家申请-运营审批通过的方式实现，也难以避免需要手工调整的情形。所以有必要给平台运营一个导入奖惩的入口。

导入的奖惩字段及校验可以参考以下这些。

3. 资金池管理

资金池管理主要用于查看商家各项汇总金额。此外，因为部分商家非正常离职（比如运营人员在后台操作解约）后有未提现资金，需要运营人员在后台手工操作提现。参考页面如下。

如运营发起提现，则需要对商户状态、提现次数、提现金额、银行卡信息等进行校验。校验通过才能完成申请，之后由财务人员进行审批，如此才能完成提现。

关于可提现金额、押金、标准押金金额需要额外说明。

可提现金额：资金池余额并不等于可提现金额，因为部分资金是有账期的，未到账期则不能提现；因为部分业务存在给商家预支劳动工具的情形（比如家政），需要按月扣除工具的磨损；此外，还有部分资金池余额需要用以补足押金。

押金&标准押金金额：押金的标准在各条业务线、各个城市都可能不同。如果商家因服务问题被投诉，可能会扣除押金；当押金扣减到一定程度（比如低于标准金额的40%），商家会被暂停接单。一旦出现商家实际押金低于标准押金的情况，那么就需要商家自行充值补足；或者是在完成一次服务&服务费度过冻结期后，由系统自动扣减进行补足。如果订单收入还不足以补足押金，在下次结算月薪资时还要继续补。

4. 薪资统计

财务给商家结算薪资前，需要报表统计商家当月的收入、补贴、奖金、出勤天数、好评率等信息，以此作为发薪的依据。对于具体的字段，各条业务可能存在不同（比如出勤及磨损费就不适用于快车专车类的业务）。参考的字段及后台原型如下。

其中，服务项目上接收订单、奖惩等是进行实时统计的; 而上月订单中好评率、出勤天数、保底等无法实时统计，需要进行按月统计。这里提供一个计算的思路：

• 月度收入=补贴+(线上收入+线下收入+订单优惠-信息服务费)+(奖金-罚金+其他)-保险费总计+商家自行充值+订单历史补漏-工具磨损费
• 月底发放金额=月度收入-线下收入-押金本月实交+押金返还。这里需要充分考虑商家押金的缴纳情况，在发放薪资前对押金进行调整。举个例子：如果月收入线下收入+押金上月已交<=押金标准，则押金本月实交=月收入-线下收入，押金返还=0，押金仍需缴纳=押金标准(月收入线下收入)押金上月已交。

账户流水是对商家账户中每一笔订单、奖惩、充值、提现等进行记录形成的，便于在需要时对历史记录进行追溯。在运营后台提供一个展示查询页面即可，主要包含以下字段。

上文有提到过，不同类型的流水有不同的账期。一般而言，商家收入类的账期相对更长，具体时长由业务方提供给薪资系统进行控制。因此会导致部分资金虽然在商家账户里，但是未到期不能提现的情况。

本文由 @霹雳 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务