不同行业的计费结算模式——以电商和云服务为例

3 评论 8921 浏览 72 收藏 9 分钟

编辑导读:在很多行业,尤其是电商和云服务行业,因为其提供的服务种类多,结算方式多,所以计费结算模式很复杂。本文作者就以这两个行业为例,对它们计费结算模式的差异展开了分析,与大家分享。

笔者近期和不同行业负责结算的朋友做了些交流,对各行业的计费结算模式有了些新的认识,在此做个梳理总结。

下面以电商和云服务为例,讲讲两个行业计费结算模式的差异。

一、相同点

不管是电商还是云服务的计费结算,都有如下的核心系统:

1. 计费系统

计费核心:按一定的规则触发计费,生成计费明细

上游系统:价格管理、订单系统或计量系统、用户信息

下游系统:结算系统

核心功能:计费触发规则、计费账单查询、账单聚合、差异调整

关于『差异调整』,都是为了满足非标准计费或计费差异的需求,由业务人员增加账单项的产品功能。

2. 结算系统

结算核心:按一定的规则对已生成的计费明细触发结算,在钱包系统生成结算明细

上游系统:计费系统

下游系统:钱包系统(或称账户系统)

核心功能:结算触发规则、差异调整

注意:如果商家没有二清资格,那么只能结算到第三方的账户内。

3. 价格管理

上游系统:合同管理、报价单或佣金规则

下游系统:计费系统

核心功能:价格的增删改查

一般而言电商的计费规则会简单点,支持阶梯的服务费率或返利费率即可。云服务的相对会复杂很多,计费周期、计费点、阶梯算法都灵活支持。

4. 资金系统

电商结算系统的下游是资金系统,平台将钱结算给商家后,商家在平台的账户内发起提现,将钱提到绑定的银行卡上。财务人员审核好提现申请后,发起打款申请,通过银企直联划拨资金。一般来说,平台会有多种支付方式,视打款金额、银行费率、到账时间选择最优的支付方式,

以上情况仅存在于有支付牌照的电商平台。如果平台没有支付牌照、无法进行二清,就不能在平台内进行结算,只能通过第三方分账,分好后,直接转到商家在第三方的账户内或在第三方绑定的银行卡内。

虽然资金系统不是云服务的结算下游,但是云服务同样有用户提现的场景——用户将预存在平台上的现金提现到外部的支付账户。

上游系统:钱包系统

核心功能:实名校验(检查持卡人和实名认证一致)、银行卡绑定、原路退回。

涉及到资金变动的流程要十分谨慎,可能一不小心就变成他人wash money的工具,因此要尽量做到核实用户实名信息,可以的话要保持资金原路退回。

二、差异点

1. 计费对象

电商:以订单金额(平台)或采购单(自营)为计费对象

云服务:以用户的使用量为计费对象

2. 计费触发规则

电商:根据订单交易状态或采购单账期而定

平台型电商一般是订单支付成功触发计费;自营型电商则根据采购单的账期触发计费

云服务:根据所用产品的计费频率,按(自然)小时、日、月计费。

3. 结算触发规则

电商:根据订单交易状态或采购单账期而定。平台型电商一般是等订单确认收货(且无售后),触发结算。结算后商家需要在平台确认结算单,自营性电商还需要商家向平台提供发票后,才能申请打款。

云服务:计费后实时结算扣款,毕竟是扣款交易,不会让用户提前确认才操作。

4. 计费目的

电商:计费主要是与商家分账结算,其次有返利、处罚、促销等目的。

云服务:主要是向用户收款

5. 计费的方向

电商:由于订单存在逆向流程,即售后单,因此生成的计费明细存在收款、付款两种类型。

云服务:计费的对象是用户的使用量,是数量而不是矢量,并不存在方向(但也有错账的处理流程,处理起来还是会有区别)。

6. 系统交互和算法

电商:一般是上游订单系统主动向计费系统推数据,触发计费。所用的计费法是正算法,即根据计量找价格。

云服务:一般是计费系统主动从上游业务线拉计量数据;由于云服务的计量数据分流量和带宽类型,同时还需要将计量数据按计费规则(如计费周期、计费算法)进行加工,才能得到计费值,因此是反算法,即通过价格找对应的计量。

7. 发票管理

电商:平台型电商是平台向商家提供技术服务,平台开具销项发票;自营性电商则是平台向商家采购商品,由商家向平台提供销项发票。

云服务:云服务公司向客户提供服务,都是公司提供销项发票。由于发票开具后,相当于是认可了费用,因此会要求用户先确认账单,才能开票,避免用户开票后不认可账单带来的退票纠纷。

8. 欠费兜底方案

其实不管是云服务还是电商,都存在扣款的交易类型,也就会产生欠费问题。针对这个问题,不同行业有不同的解决方案。

电商:保证金制度

商家入驻平台时,电商会要求商家缴纳一定的保证金,用于商家违约扣款的资金池。当发生逆向交易单,以致于结算倒挂时,如果结算货款的账户内余额不足,平台可以将保证金账户的资金转移到货款结算账户,进行垫付。如果保证金不足,平台会采取停止服务的策略,比如关店。

云服务:实时计费+预冻结金额

由于云服务提供的是按需计费的计费策略,用户先使用后计费,计费始终滞后于使用,这就是欠费产生的根因。通常的解决办法,就是提高计费的实时性,甚至会根据用户的历史消费金额按一定比例预先冻结账户的资金(一般只有大厂敢这么干)。

综上,就是我个人总结下来的两个行业计费结算的异同点,如果大家有更多看法,欢迎在评论区与我交流。

 

本文由 @大肥兔 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 文中应该是一个比较简化的计费系统,但实际中可能会更复杂些,以下几个点应该也是需要的:
    1、计费规则的管理说明,云服务的计费,不是单纯的使用量*单价,可能会涉及一些简单的计算,需要另外做使用量的配置规则管理
    2、计费触发规则:不一定是自然月,服务可能是从中间某一天开始,服务周期非自然月或自然年。另外可能会存在不满计费周期的折算问题。
    3、结算触发规则中,实时的定义是怎样的?云服务中不同产品的定义是否一致,如果不一致,是定制开发还是针对不同计费项做配置?
    4、不同计费项之间可能会存在关联关系,需要有另外的管理。

    来自福建 回复
    1. 是的 实际情况做的我头痛死了

      来自上海 回复
  2. 老兄,可否加个微信交流?

    来自浙江 回复