惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
SegmentFault 最新的问题
爱范儿
爱范儿
博客园 - Franky
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
WordPress大学
WordPress大学
宝玉的分享
宝玉的分享
雷峰网
雷峰网
酷 壳 – CoolShell
酷 壳 – CoolShell
IT之家
IT之家
有赞技术团队
有赞技术团队
美团技术团队
Last Week in AI
Last Week in AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
大猫的无限游戏
大猫的无限游戏
The Cloudflare Blog
Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Engineering at Meta
Engineering at Meta
T
Tailwind CSS Blog
J
Java Code Geeks
Martin Fowler
Martin Fowler
I
InfoQ
小众软件
小众软件
MongoDB | Blog
MongoDB | Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
直播行业中的财务结算有多困难?
Jessica · 2025-05-05 · via 人人都是产品经理

从主播与商家的佣金分配,到各种费用的结算规则,再到对账单的生成与审核,每一个环节都可能因为规则的复杂性、数据的庞大以及业务的多样性而变得异常棘手。本文深入剖析了直播行业财务结算的难点,包括结算规则的多样性、对账单的生成与流转机制,以及在实际操作中容易遇到的坑点。

一、概念图

二、细拆财务结算

财务结算的依据是什么?

财务结算的依据称之为“结算规则”,一般结算规则是在合同里约定的,比如什么时候哪个主播可以卖哪些商品,卖掉之后按什么样的佣金/坑位费结算。

一般直播行业的结算规则会很复杂,不同的商家会有不同的规则,不同的主播的规则会更复杂。

例如,商家的结算规则一般会有以下几类:

那么系统需要有一块「结算规则模型」去承载这么多类型的结算规则。

财务对帐单该如何形成?

要知道对账单如何形成,那么就需要知道对账单包含哪些?

与不同对象结算的对账单包含内容也不一样:

1)商家结算

  • 坑位费
  • 佣金
  • 其他费用:投流推广费、福利品费用、场地搭建费等

2)主播结算

  • 出场费用
  • 佣金费用
  • 激励费用
  • 商业切片费用
  • 短视频费用
  • 其他费用

所以复杂情况下,对账单需要拆分为好几个子业务去结算,如商家结算中,对账单会有常见的几种类型,且不同类型展示的明细均不同:

1)坑位费对账单

明细字段:直播场次、主播名称、坑位费

数据表唯一值:「直播场次+主播名称」

2)佣金对账单

商品明细字段:商品id、商品名称、直播场次、账号id、主播名称、商家信息、成交金额、佣金比例、应付佣金金额

数据表唯一值:「商品id+直播场次+主播名称」

订单明细字段:订单id、商品id、商品名称、直播场次、账号id、主播名称、商家信息、订单金额、佣金比例、应付佣金金额、下单时间

数据表唯一值:「订单id」

3)投流推广对账单

明细字段:直播场次、主播名称、投流费

数据表唯一值:「直播场次+主播名称」

接下来,根据不同企业不同的结算周期的需求,由固定角色的人手动系统选择要结算的明细数据生成对账单即可,对账单的维度会更加聚合,比如佣金对账单,当勾选了一个批次的数据后,按照「主播+商家」维度生成数据。

财务对账单如何流转?

1、正向流转:从对账单生成后,需要经过财务审核,商家审核,商家基于明细数据如果和企业给的数据有出入,则会涉及到反复的拉扯修改核对的过程。当对账单确认结束后,才会到最后企业给商家付钱或者商家给企业付钱的地步。

图为正向流转状态机

2、逆向流转

对账单会因为很多特殊情况发生回退,比如以下情况:

  • 误生成对账单
  • 选错明细数据生成错误的对账单
  • 对账单确认完后发现问题
  • 隔了好久发现历史对账单出现数据错漏
  • …..

因此,对账单的逆向流程也是比较重要的。在对账单没有进入到完结流程时,我们可以提供以下手段保证对账的正常流转:

  • 强校验:针对一些可能导致对账单计算错误的情况,系统采用阻断校验,规范操作者用正确的操作触发对账;
  • 对账单作废:对账单作废后,其明细数据会回到“待结算池”中,这样就可以选择正确的数据再次发起对账;
  • 技术回退:针对对账单完结的情况,由于占据业务比例很少,因此无需额外做产品功能,有需要时申请技术回退即可。

财务结算中的踩坑点?

1、结算模型的抽象化

结算模型跟着业务变化会非常快,所以产品在设计结算模型的时候务必要抽象化,给未来留更多优化的空间,而不是业务一变,模型就要重构。

2、连续性业务和非连续性业务的对账体系是否一样

  • 非连续性业务:比如直播,在直播结束后,就不能下单了,只是订单状态(退款、退货、取消等)会影响订单金额。这种情况的结算周期相对较短,比如30天、60天,就能把上一次直播发生的数据处理好。
  • 连续性业务:比如短视频订单等,短视频发布后产生的订单是持续的,不知道什么时候会结束,所以会不停有数据流入,新流入的数据又可能会对整个规则的激励机制有影响,所以每一次的结算都需要重新考虑多退少补等复杂情况。

三、总结

直播行业,其实底层拼的是供应链,算的效率。

一个简单的耳熟能详的商业,背后需要有一整套复杂的系统去支撑。

尤其是财务结算,因为涉及到的对内对外的对象很多,里面的款项很多,约定的规则模型很复杂,都会成倍放大财务结算的难度。因此,与其说财务对账难,不如说财务同学在对账过程中反复复核找茬是最痛苦的,在海量的数据面前,人脑很难识别数据的正确性,唯一能做的就是「重复校验」。

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

题图来自Unsplash,基于CC0协议

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