一场直播的钱，为什么总也算不清
做直播带货的品牌方和代运营公司，几乎都在同一种状态里运转：排期在微信群，坑位费在转账截图里，佣金在某个人的私账表格里。 单场、双场还能扛，一个月排十几场、同时对接十几个达人和机构，问题就集中爆发：
- 同一场直播算了两遍钱。 商务在群里说"这场已经结过了"，财务翻到的却是另一张表；达人那边催第二遍，最后为了让对方继续合作，就再付一次。多付的钱往往没人回头查。
- 坑位费和佣金混在一笔转账里。 坑位费是"上不上播"的固定支出，佣金是"卖了多少"的结果支出，两者性质完全不同。混着付，事后想算"这个达人到底值不值"就没有数据基础：不知道是选品问题还是达人带不动。
- 退货一冲，账就散了。 直播的成交额（GMV，即直播间下单商品的总成交金额）里含着大量待发货、待收货的订单，七天无理由退货期过完，真实成交才落地。但佣金常常在发货后就按当时的成交额结了，等退货潮过去，多付的佣金没人去冲减。
- 报价和佣金比例记在不同人的聊天记录里。 同一个达人上半年谈的是一个数、下半年谈了另一个数，中间换过对接人，新来的人只能凭记忆报价，谈低了是公司损失，谈高了是成本超标。
- 复盘做不出来。 想知道"哪类达人、哪个价位带的货最划算"，得把三张表拼起来手工对，拼完这个月已经过去了。
这些问题的根子不是缺一套专业系统，而是四件事没有分开存：合作对象是谁、这场直播是什么、这场直播卖了什么、钱按什么口径结。压在一张表里，任何一次退货、换人、补结，都会把历史数据覆盖掉，覆掉之后再也回不到原始记录。
这篇方案讲的是用 Inkwell Engine 的 AI 构建器把这件事搭成一个能持续跑的小系统：合作对象建档 → 场次排期 → 商品与报价 → 费用与结算 → 冲减与付款，几张表加几条规则，电脑与手机都能用。文中的比例、金额、时限都是字段位置，具体数值按企业与达人的约定填。
数据怎么建：三层分开，先定口径
在构建器里描述需求时，把"表之间的关系"讲清楚，比罗列功能有用得多。这套账建议至少分三层：对象层（谁）— 事件层（哪场）— 金额层（算多少、付多少）。
第一层：合作对象主档（达人 / 机构）
很多团队在这一步就埋了坑：把"出镜的达人"和"收钱的机构"当成同一条记录。现实里这两者经常分开——MCN 机构签的约，实际出镜的是它旗下的达人；也可能是达人本人签约，由机构代收款。所以主档里要同时有"合作主体"和"出镜达人"两个概念。
可行的做法是建一张主档，用主体类型区分：
- 主体类型：个人达人 / MCN 机构
- 主体名称、对接人、联系方式、所在平台与账号（一个主体可能有多个平台账号，账号信息放子表一行一个）
- 收款信息（收款主体名称、开户信息）、是否已签合作合同
- 合作状态（在谈 / 合作中 / 暂停 / 终止）、首次合作日期、负责商务
- 默认结算口径（按支付成交 / 按确认收货 / 按退货后有效成交）、默认佣金比例
两个要在建表时说死的约定：
一是主体名称设唯一性校验。 同一个达人在系统里只能有一个身份。否则 A 商务建了"某某"，B 运营建了"某某（抖音）"，同一个人的两套场次与两套付款永远不会被合并统计，达人自己也搞不清哪个账号在结算。
二是"默认结算口径"必须在主档上定一次。 佣金按哪个数算，是这个模块里最容易被扯皮的地方。按支付成交算，达人开心但公司承担退货风险；按确认收货算，公司安全但达人会觉得周期长；按退货后有效成交算，最公平，但必须等到退货期结束。 主档上写默认口径，具体场次可以覆盖，覆盖时必须填理由——这样半年后回看，能看出这个达人当初是按什么条件谈的。
主档上还要挂合同：合作合同、报价单、结算协议用附件上传（图片与 PDF 都能直接传），附件挂在主档或场次行上，能按主体反查到所有历史文件。合同本身的到期与续签提醒，可以交给合同台账类的模块管，两类模块的分工这里不展开。
第二层：场次主表（一场直播一行）
这是整套系统的中枢。一次直播（无论是达人专场、混场还是要约自播）就是一行记录：
- 场次编号（系统生成，对外报单也用这个号）、场次名称
- 开播日期与时段、直播平台、承载账号（品牌自播号 / 达人号）
- 场次类型：达人专场 / 达人混场 / 品牌自播 / 代运营代播
- 合作主体（引用主档）、出镜达人（可能与主体不同，单独存字段）
- 坑位费约定金额、佣金比例约定、佣金计算口径（继承主档默认值或覆盖并填理由）
- 是否有保底要求（例如约定最低成交额，未达成时的处理方式记在备注里，不写进计算规则）
- 场次状态：待排期 / 已排期 / 已开播 / 已播完 / 待结算 / 已结算 / 已归档
- 负责商务、负责运营
关键设计决定一：场次状态不要当"万能字段"用。 状态只表示这场直播走到哪一步；"钱结没结"由结算单的存在与状态回答。如果把"已结算"硬塞成场次状态的最后一档，一旦出现部分结算、延迟付款、退货冲减，状态就没法表达了。
关键设计决定二：坑位费与佣金在场次表上只记"约定"，不记"实付"。 约定是商务谈下来的条件，实付是财务的动作，两者中间隔着对账、审批、付款。场次表只存约定值，实付全部落在金额层的单据上。这样任何一次对账纠纷，都能看到"当初谈的是什么"和"实际付了多少"两个独立的数。
关键设计决定三：排期冲突由规则拦，不靠人记。 同一个承载账号在同一时段不能排两场，这是硬冲突。在保存时做一次校验：账号相同、时段重叠就拒绝保存并提示冲突场次编号。达人本人同日排两场属于软冲突（现实中允许，但要提醒），做法是保存时提示、由商务确认后放行——软冲突提示，硬冲突拦截，这条区分很关键，否则运营会觉得系统处处拦人而不愿用。
第三层：金额层——商品明细行、费用行、结算单、调整行
这一层要拆成四张表，各有各的口径，混在一起必错。
（1）场次商品明细行：一场直播上几个品，就几行。字段是商品编码与名称、备注的直播间报价、本场直播价、本场佣金比例、佣金计算基数（成交额 / 销量口径）、实际成交件数与成交额（开播后回填）。商品行必须挂在场次下，不能挂到主档上——因为同一个品在不同场次可能完全不同的价格和佣金条件。
（2）费用行：一场直播可能产生坑位费、投流费（付费流量投放的支出）、样品费、达人差旅补贴等多种费用。不要做成"一行多个金额字段"，要做成"一行一笔费用"。 一行记：费用类型（走数据字典，选项集中维护，见 数据字典）、金额、承担方、发生日期、凭证附件、是否含税。理由很实际：费用类型是会增加的，做成固定字段以后每多一种就得改表；做成行，永远只是多一条记录。费用行只增不改，金额填错就红冲一行、新增一行正确值，原始记录留着。
（3）结算单（核心）：一行 = 一次"场次 × 合作主体 × 结算周期"的应付汇总。为什么不是"一场一结"？因为现实中常常约定按月合并结算，多场一起付。结算单上记：结算对象（主体）、包含哪几场（明细行引用场次）、佣金计算基数合计、佣金应付、坑位费应付、其他费用合计、扣减合计、应付合计、结算状态（待对账 / 待审批 / 已审批 / 已付款 / 部分冲减）。
这里必须加一条唯一约束：同一主体、同一结算周期只能有一张进行中的结算单。 缺了这条约束，两个财务各自导一次数据，同一批场次就会被结两次——这是最常见也最贵的错误。约束在保存时拦截，提示"该主体本期结算单已存在，请在其上追加场次明细"。
（4）结算调整行（冲减行）：结算单付款之后发生的退货、补结、费用退回，全部以"调整"的形式新增一行：调整类型（退货冲减 / 补结佣金 / 费用退回）、关联原结算单与场次、调整金额（可正可负）、原因、生效日期。绝不回到原结算单上去改数字。 已付款的单据永远不动，这样任何一期对账都能回答"这笔钱当时为什么这么付、后来为什么又退回来"。
四张表的关系一句话说清：场次是事件，商品行与费用行是这场事件的明细，结算单把多个事件的明细按主体和周期汇总成一次付款，调整行在不触碰历史的前提下修正结果。这就是全部。
页面怎么用：四个角色，四种视角
表建好之后，页面不是"一个列表加一个表单"，而是按谁在用、用来干什么来分。同一个模块里做四组页面，每个角色打开只看到自己关心的那一屏。
商务/媒介：达人库 + 排期看板。 达人库是主档的列表页，按合作状态、平台、负责商务筛，点进去是"一达一页"：基本信息、历史场次、累计坑位费与佣金、复盘指标。排期看板是场次列表的日历视图，按周看，每场显示主体、平台、状态。商务最需要的判断是"这个达人上次带得怎么样"，所以达人详情页要能把历史场次的成交与费用摊在一起看，而不是让人再去翻结算单。
运营/直播助理：场次执行页。 这是开播当天用最多的一屏：本场商品清单、直播价与佣金比例、库存与链接、话术要点。开播后回填实际成交件数与成交额；播完把后台数据导出来核对一遍。数据来源这一层要说清：平台后台的数据不自动进系统，靠人工录入或导入，所以页面要做得让人愿意在现场填——字段少、默认值合理、能保存草稿。批量回填可以用平台的表格导入能力（做法见 用 Excel 一步建模块），把平台导出的明细表整理成一列一字段的表头导进来，比一条条敲快得多。
财务：结算对账台 + 付款登记。 对账台的核心不是"看清单据"，而是"核出差异"：系统按结算单自动汇总应付，财务只需逐项确认——场次是否都结进来了、退货冲减有没有漏、费用凭证是否齐全。差异原因必填，不填不让提交审批。付款登记只记事实：付款日期、付款方式、金额、流水号、凭证附件，不在这里改应付金额。
负责人：月度汇总页。 一屏回答三个问题：这个月坑位费花了多少、佣金结了多少、哪个主体与哪个品类的投入产出最值得继续。汇总页只读，不改数据，避免"老板顺手改数"破坏账。
给外部对接人开账号要受限。 达人或机构的对接人有时需要自己看结算进度，用平台的角色与权限开一个受限账号：只给"本主体相关场次与结算单"的查看权限，不给报价、成本、其他达人的任何数据。权限按角色配，不按人逐个点，人员变动时换角色即可。
规则怎么配：四类自动化，把口径变成拦截
台账类模块真正省人的地方，不在页面好看，而在规则替人做判断。这个模块建议配四类规则。
第一类：数据流规则（保存时校验与计算）。 数据流规则是"条件满足就自动改数据或拦下保存"的规则引擎，不需要写代码。这套账里至少要配这几条：
- 金额算式：应付合计 = 坑位费 + 佣金应付 + 其他费用 − 扣减合计；佣金应付 = 佣金计算基数 × 佣金比例。基数口径已在场次上定死，规则按口径取数，不给人手工填总额的机会。
- 唯一性拦截：同一主体同一结算周期只允许一张进行中的结算单；同一场次不允许出现在两张结算单里。
- 冲突拦截：同一承载账号时段重叠拒绝保存；达人同日多场做提示。
- 前置条件拦截：场次未回填成交数据不允许提交结算；结算单里所有场次状态必须是"已播完"；费用行没有凭证附件不允许进入待审批。
- 状态推进：结算单全部场次核完、差异原因已填，才允许从"待对账"进入"待审批"。
把校验做成拦截而不是提醒，是这套系统值不值得用的分水岭。 只发提醒的规则，用两周就没人看了；保存即拦截、且提示里写清"哪一场、哪个数不对"，才会被当作工具用。
第二类：审批流（按金额与风险分档）。 不必所有单据都走审批——全量审批会让人绕开系统私下推进。建议分三档：
- 场次立项：坑位费超过企业设定的阈值时走审批，阈值在系统配置里填（具体数值按企业预算制度定，不给默认值）；阈值以下由商务直接排期。
- 结算单：全部结算单走审批（这是付款前最后一道闸），审批人看得到场次明细、费用凭证与差异说明。
- 调整行：退货冲减与补结都要审批，尤其是负向金额，必须有原因。
审批节点用可视化编辑器配，节点、条件与抄送都能改，无需重建模块（节点配法见工作流可视化编辑器）。
第三类：定时任务（让该来的提醒自己来）。 定时任务按时间自动跑，把"到点该做的事"变成系统推送：
- 开播前提醒：场次前若干天，推给商务与运营，附带"商品清单是否齐、样品是否寄出、合同是否签"的检查项。天数按企业习惯配。
- 结算周期生成：按结算周期（周结 / 半月结 / 月结）自动把已播完未结算的场次按主体汇总，生成待对账的结算草稿，财务只需核对。这一步替代了全月手工拉表的动作。
- 付款到期提醒：结算单审批通过后超过约定付款天数仍未登记付款的，推给财务与负责人。
- 退货期收口提醒：按约定口径，退货期结束后提醒运营回填冲减，避免"多付的佣金永远没人追"。
- 月度汇总：每月初把上月坑位费、佣金、场次数量与主体排名生成一份汇总，推给负责人。
配置方式见工作流与定时任务，支持按 Cron 表达式设频率，并保留每次执行记录，跑没跑、跑成功没有都能查。
第四类：审计留痕。 结算单、调整行、费用金额的每一次修改都记操作人、时间与前后值。这类账的纠纷经常发生在三个月后，谁改的、改成多少必须查得到。审计日志本身是平台能力，不需要为它单独建表。
移动端怎么配合：三个现场场景
这套账的现场不在办公室，而在直播间和微信群里，所以手机端不是"电脑版的缩小版"，它只需要覆盖三件事：
一、商务在路上查与填。 谈合作时最常被问到"你们上次跟谁合作、什么条件"，手机端打开达人详情就能看历史场次与约定条件，不用回公司查电脑。谈完当场建一条场次草稿，回公司再补细。这就是移动端页面的价值：把记录的动作放到发生的现场，而不是等回办公室靠记忆补。
二、运营在开播现场填数。 开播当天用手机打开本场执行页，逐品回填成交件数与成交额，播完拍照上传后台数据截图作为凭证。附件直接挂在场次或结算单明细上，事后能按单据反查截图——比"截图存在某个人手机相册里"可靠得多。
三、负责人随时批。 审批在手机上完成，重点看三样：场次明细是否齐全、费用凭证有没有、差异原因写没写清。手机上不提供改数的入口，只能批或退回。
需要说明的边界：移动端页面不做离线保存，网络不稳定时请先在纸上或本地记录、恢复网络后再录入，系统不承诺"断网也能填、联网自动同步"。这个场景需要在上线培训里讲清楚，否则现场会以为数据丢了。
双端关系是：在电脑上用 AI 构建器建好的模块，页面会自动出现在手机端的对应入口，不需要另做一套（见 移动端 与移动端使用指南）。
上线前查什么
模块建好不等于能用。上线前按这张清单逐条过，比上线后救火便宜得多：
- 口径先定死。 佣金按支付成交、确认收货还是退货后有效成交？先由业务与财务拍一个全公司统一的口径，写进主档默认值。这一条没定，后面所有数字都可以被质疑。
- 主体去重。 把现有 Excel 里的达人与机构名单导进来前先查重：同一个人的多个写法合并成一个主体，账号种类放子表。宁可多花半天洗数据，不要在系统里留下两套身份。
- 历史数据只导入"底线数据"。 建议只导入近三个月的场次与未结清的款项——历史场次全量导入既不必要，也容易把旧口径带进来。老账留在原表里存档，需要时查得到即可。
- 唯一约束都配上并测过。 同一主体同一周期只一张结算单、同一场次不进两张结算单。测试方法：故意建两次，看是否被拦，提示是否说清原因。
- 状态字典一次定完。 场次状态、结算状态、费用类型、调整类型，全部走数据字典集中维护，别在代码或表单里写死中文选项——以后加一种费用类型就不用改表结构。
- 权限按角色配好。 商务能看自己负责的主体与场次，运营能填执行数据但不能改费用，财务能付款但不能改约定金额，外部对接人只能看本主体。逐个角色过一遍"他能看到别人家的数据吗"。
- 审批阈值与审批人填实。 阈值是多少、超了找谁批、结算单到谁手上停，全部配成真实的人与真实的分档。放空的审批流等于没有闸。
- 定时任务先在测试期观察一轮。 让提醒真实推送一次，确认收件人正确、内容说清了要做什么，再正式启用——推错人的提醒比没有提醒更伤信任。
- 附件规则说明白。 哪些单据必须有凭证（付款、费用、冲减），没附件不允许提交。规则写进拦截，不写在制度里。
- 对一个月做一次全流程演练。 用真实的几场直播走一遍：排期 → 回填 → 生成结算 → 审批 → 登记付款 → 退货冲减，看有没有断点。
之后怎么延伸
这套账跑顺之后，最自然的延伸有三条：
一是把佣金口径与内部销售提成打通的分界说清。 这两个概念经常被混着讲，实际是两套完全不同的账：本模块管的是"付给外部达人与机构的佣金"，内部销售人员的提成是另一套规则（目标分解、业绩归集、阶梯提成，思路见销售目标与提成核算）。两者可以共用主体与场次数据，但结算对象与审批人必须分开，否则一个人既拿内部提成又拿达人佣金，账就糊了。
二是往应付与开票走。 结算单审批通过后，付款与应付余额交给应收应付台账管（见应收应付）；需要达人或机构开具发票的，开票申请与进项是否到账走发票台账（见开票申请与发票台账）。本模块只管"该付多少、为什么付"，票据与资金动作交给相邻模块，避免两处各记一遍金额。
三是往复盘与选品走。 场次数据攒够三个月后，可以做按主体、按平台、按品类的投入产出对比，反过来指导下一季的达人选择与报价谈判。这一步的前提正是前面三条表分层——有明细行才能算清单个品的账。
这套方案不做什么
把边界说清楚，比把能力说大更有用：
- 不自动从平台后台拉数据。 抖音、快手、视频号等平台的数据需要人工导出后录入或导入，系统不与直播平台做接口直连。想要"自动同步成交额"，不在本方案范围内。
- 不做自动打款。 付款走企业既有的银行或支付渠道，系统只登记付款事实与凭证，不对接资金通道。
- 不算税务口径。 达人佣金的个税、发票与代扣代缴，按税务与主管部门规定处理，系统只记录金额与是否含税，不给税务建议。
- 不判断达人质量。 粉丝画像、流量真实性、内容合规审核都不在本方案里，系统只忠实记录合作结果，选人判断仍靠人。
- 不替代合同管理。 合作合同的正本、签署与续签提醒交给合同台账类模块，本模块只存约定金额与口径并挂附件。
一句话记法
对象、事件、金额三层分开：达人与机构一人一档（唯一约束防重复建档），场次一场一行（只记约定不记实付），商品与费用一行一笔，结算单按主体与周期汇总并加唯一约束，事后修正一律新增调整行。 口径写在主档上、校验做成拦截、提醒交给定时任务——账就永远是"算"出来的，而不是"填"出来的。