摘要：从主播与商家的佣金分配，到各种费用的结算规则，再到对账单的生成与审核，每一个环节都可能因为规则的复杂性、数据的庞大以及业务的多样性而变得异常棘手。本文深入剖析了直播行业财务结算的难点，包括结算规则的多样性、对账单的生成与流转机制，以及在实际操作中容易遇到的坑点
从主播与商家的佣金分配，到各种费用的结算规则，再到对账单的生成与审核，每一个环节都可能因为规则的复杂性、数据的庞大以及业务的多样性而变得异常棘手。本文深入剖析了直播行业财务结算的难点，包括结算规则的多样性、对账单的生成与流转机制，以及在实际操作中容易遇到的坑点。
财务结算的依据称之为“结算规则”，一般结算规则是在合同里约定的，比如什么时候哪个主播可以卖哪些商品，卖掉之后按什么样的佣金/坑位费结算。
一般直播行业的结算规则会很复杂，不同的商家会有不同的规则，不同的主播的规则会更复杂。
例如，商家的结算规则一般会有以下几类：
那么系统需要有一块「结算规则模型」去承载这么多类型的结算规则。
要知道对账单如何形成，那么就需要知道对账单包含哪些？
与不同对象结算的对账单包含内容也不一样：
1）商家结算
坑位费佣金其他费用：投流推广费、福利品费用、场地搭建费等2）主播结算
出场费用佣金费用激励费用商业切片费用短视频费用其他费用所以复杂情况下，对账单需要拆分为好几个子业务去结算，如商家结算中，对账单会有常见的几种类型，且不同类型展示的明细均不同：
1）坑位费对账单
明细字段：直播场次、主播名称、坑位费
数据表唯一值：「直播场次+主播名称」
2）佣金对账单
商品明细字段：商品id、商品名称、直播场次、账号id、主播名称、商家信息、成交金额、佣金比例、应付佣金金额
数据表唯一值：「商品id+直播场次+主播名称」
订单明细字段：订单id、商品id、商品名称、直播场次、账号id、主播名称、商家信息、订单金额、佣金比例、应付佣金金额、下单时间
数据表唯一值：「订单id」
3）投流推广对账单
明细字段：直播场次、主播名称、投流费
数据表唯一值：「直播场次+主播名称」
接下来，根据不同企业不同的结算周期的需求，由固定角色的人手动系统选择要结算的明细数据生成对账单即可，对账单的维度会更加聚合，比如佣金对账单，当勾选了一个批次的数据后，按照「主播+商家」维度生成数据。
财务对账单如何流转？1、正向流转：从对账单生成后，需要经过财务审核，商家审核，商家基于明细数据如果和企业给的数据有出入，则会涉及到反复的拉扯修改核对的过程。当对账单确认结束后，才会到最后企业给商家付钱或者商家给企业付钱的地步。
图为正向流转状态机
2、逆向流转
对账单会因为很多特殊情况发生回退，比如以下情况：
误生成对账单选错明细数据生成错误的对账单对账单确认完后发现问题隔了好久发现历史对账单出现数据错漏…..因此，对账单的逆向流程也是比较重要的。在对账单没有进入到完结流程时，我们可以提供以下手段保证对账的正常流转：
强校验：针对一些可能导致对账单计算错误的情况，系统采用阻断校验，规范操作者用正确的操作触发对账；对账单作废：对账单作废后，其明细数据会回到“待结算池”中，这样就可以选择正确的数据再次发起对账；技术回退：针对对账单完结的情况，由于占据业务比例很少，因此无需额外做产品功能，有需要时申请技术回退即可。财务结算中的踩坑点？1、结算模型的抽象化
结算模型跟着业务变化会非常快，所以产品在设计结算模型的时候务必要抽象化，给未来留更多优化的空间，而不是业务一变，模型就要重构。
2、连续性业务和非连续性业务的对账体系是否一样
非连续性业务：比如直播，在直播结束后，就不能下单了，只是订单状态（退款、退货、取消等）会影响订单金额。这种情况的结算周期相对较短，比如30天、60天，就能把上一次直播发生的数据处理好。连续性业务：比如短视频订单等，短视频发布后产生的订单是持续的，不知道什么时候会结束，所以会不停有数据流入，新流入的数据又可能会对整个规则的激励机制有影响，所以每一次的结算都需要重新考虑多退少补等复杂情况。直播行业，其实底层拼的是供应链，算的效率。
一个简单的耳熟能详的商业，背后需要有一整套复杂的系统去支撑。
尤其是财务结算，因为涉及到的对内对外的对象很多，里面的款项很多，约定的规则模型很复杂，都会成倍放大财务结算的难度。因此，与其说财务对账难，不如说财务同学在对账过程中反复复核找茬是最痛苦的，在海量的数据面前，人脑很难识别数据的正确性，唯一能做的就是「重复校验」。
本文由 @Jessica 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
来源：人人都是产品经理一点号