标准场景 对账比对 岗位 · 运营

DR-02 · GMV 对账器(82% 告警线)

痛点 运营说卖了 92 万 · 财务说到账 71 万 · 两个人拿着各自的表谁也说服不了谁

① 场景引入

一、这件事现在是什么样

经营数据与口径治理 · 真实业务触发

月中对账,财务的支付宝流水和运营的生意参谋报表对不上 —— 差了 13.6 万。运营说是退款时差,财务说上个月也差、上上个月也差。老板娘要求:这个月把差额拆清楚,每一分钱都有去处。

二、痛点 · 每条都有来源

  1. 支付宝月度实际到账 ÷ 生意参谋支付金额低于 82%,说明退款率、渠道扣费或看板逻辑出现结构性错误 —— 不是时差是问题
    依据:对账指南:支付宝月度实际到账 ÷ 生意参谋支付金额低于 82%,说明退款率、渠道扣费或看板逻辑出现结构性错误;直接看板数据通常带 10%-15% 水分
  2. 「看起来正常」的口径差最危险:某商家实收比长期 78% 却从没告警,直到备货资金链紧了才发现退款窟窿
    依据:对账指南:支付宝月度实际到账 ÷ 生意参谋支付金额低于

82%,说明退款率、渠道扣费或看板逻辑出现结构性错误;直接看板数据通常带 10%-15% 水分3运营与财务各拿一张表互不信任 —— 老板夹在中间拍不了板,月底对账日成了每月一次的吵架日依据 · 日报形式主义吐槽:写了没人看、不写又挨骂;运营的时间黑洞在「每天登 N 个后台抄数拼表」

三、换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 支付宝月度实际到账 ÷ 生意参谋支付金额低于 82%,说明退款率、渠道扣费或看板逻辑出现结构性错误—— 不是时差是问题
  • 「看起来正常」的口径差最危险:某商家实收比长期 78% 却从没告警,直到备货资金链紧了才发现退款窟窿运营与财务各拿一张表互不信任 —— 老板夹在中间拍不了板,月底对账日成了每月一次的吵架日

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

  1. 总额对碰 · 差额先量化到账 − 支付口径 = 总差额;对照 82% 线判定性质
  2. 差额四拆 · 退款/扣点/时差/未知能拆的逐项核减,每项带明细数;拆不动的进「待查明」
  3. 未知项排查 · 串户与异常订单未知差额按单笔匹配 —— 定金未付、货到付款、跨月结算逐个过
  4. 月度趋势 · 这个月是例外还是惯例近 6 个月实收比走势 ——78% 常态与 88% 常态是完全不同的经营信号
  5. 对账报告 · 运营和财务同看一张差额拆解 + 凭证指向 + 趋势 ——吵架日变对表日

要准备什么:支付宝/微信月度到账流水财务侧的唯一真相生意参谋支付口径明细运营侧的报表来源退款明细(售中+售后)差额拆解的最大变量平台扣点与服务费明细第二变量

为什么这个场景值得做

优先级评分:痛感 5 × AI 适配 4 ÷ 落地难度 3 = 6.7

最大差异点:不要求先统一报表。支付宝流水 + 生意参谋导出两份数据扔进来 —— 差额自动拆解到项,拆不动的明说。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」;

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」;

落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五、会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

  • 正式件本体:GMV 对账报告.xlsx 差额四拆 + 凭证指向 + 6 个月趋势
  • 可派发清单:待查明订单清单.xlsx 未知差额对应的单笔订单 · 供财务当日核完
  • 可派发清单:口径差异说明(运营-财务对照版).xlsx 两张表为什么不一样 · 各项口径定义并排

这套东西不承诺什么:不做「调账」—— 差额的账务处理是财务的事。本场景做的是把差额拆到可解释:退款、扣点、时差、串户,每一项带凭证指向。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:洁屿家居(虚构)月中对账:财务的支付宝流水显示 8 月到账 789,856 元,运营的生意参谋报表支付口径926,000 元 —— 差了 136,144 元。老板娘要求把差额拆到可解释,每一分钱都有去处。

报表支付926,000 元实际到账789,856 元总差额136,144 元未知项3,800 元

输入运营手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_支付宝及合并结算流水_8月.xlsx 财务侧的唯一真相 —— 实际到账财务出纳导出 · 月中一次
  • 02_生意参谋支付口径明细_8月.xlsx 运营侧的报表来源 —— 支付口径沈飞导出 · 月度归档
  • 03_退款明细_8月.xlsx 差额拆解的第一变量各平台导出 · 沈飞汇总
  • 04_平台扣点与服务费明细_8月.xlsx 差额拆解的第二变量各平台结算单导出
  • 05_近6个月到账与支付对照.xlsx 判断本月是例外还是惯例的趋势底稿财务月度归档

注意标橙色那一份 —— 01_支付宝及合并结算流水_8月.xlsx。它财务出纳导出 · 月中一次,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

财务的到账流水、生意参谋的报表、退款和扣点明细都在这,帮我把差额拆清楚。 每一分钱都要有去处,拆不动的单独列出来别硬塞。 上几个月的流水也在这,看看这个月是例外还是老毛病。 最后要一份运营和财务都能认的报告。

短是因为「82% 验证线、差额四拆结构、串户排查规则」都在能力包里。对账这件事谁发起都行。

触发财务和运营各拿一张表

第 13 步 · .6 万的差额 · 每月一次的吵架日

运营坚持「时差说」(退款要 7-15 天才体现),财务坚持「上个月也差」—— 老板娘的裁决很简单:别吵了,把每一分钱拆到可解释。

第 1 步 · 总额对碰 · 差额先量化

到账 − 支付口径 = 总差额

演示数据(表格原文)口径金额(元)生意参谋支付口径(三平台合计)926,000实际到账(支付宝+合并结算)789,856总差额136,144实收/支付比85.3%高于 82% 线85.3% 高于 82% 告警线 —— 结构上没有大问题,但「高于线」不等于「每分钱都清楚」。

这一步的看点 · 排除性结论,把运营的「时差说」用数字排除「『退款时差』可以排除 —— 本月退款明细总额 91,108 元已全额计入拆解,而其中售中退款(拍下即退、36,400 元)根本不产生资金流动。真正的差异结构是:售后退款 54,708 + 扣点 41,236 + 售中退款 36,400 = 132,344,占差额 97.2% —— 剩下的 3,800 才是真未知。」运营一直坚持的「时差说」被数字拆掉了 —— 时差是真的,但它只影响『什么时候到』,不影响『差多少』。

第 2 步 · 差额四拆 · 退款/扣点/结算规则/未知

能拆的逐项核减 · 拆不动的进待查明

演示数据(表格原文)拆解项金额(元)占比性质售后退款(真金白银流出)54,70840.2%可解释售中退款(未产生资金流动)36,40026.7%可解释平台扣点(技术服务费)41,23630.3%可解释 · 成本结构货到付款未结算(直播专供链接)3,8002.8%盲区合计136,144100%—四项拆解合计恰好等于总差额 —— 但「货到付款未结算」这一项是推断:它对得上 6 个月趋势里的盲区规律,对得上不等于查实了。

这一步的看点 · 从历史月份里发现了惯例性的窟窿近 6 个月里有 4 个月(4、6、8 月)存在 3,000-4,000 元的未知差额、累计 10,600 元 —— 间隔与直播专供链接货到付款的结算周期完全吻合。这不是本月的新问题,是每两个月滚一次的口径盲区,只是金额没大到让人睡不着。这次按结算周期对上了账 —— 不靠财务记得有这回事。

第 3 步 · 未知项排查 · 3,800 元的下落

按单笔匹配 · 货到付款订单逐个过

演示数据(表格原文)排查动作结果直播专供链接的货到付款订单导出(8 月)37 单 · 未结算 11 单未结算金额合计3,812 元(与未知项 3,800差 12 元 —— 尾差为跨月单)结论盲区查实:货到付款 T+15 结算周期 vs 月度对账日的错位3,800 的下落找到了:货到付款的结算周期比月度对账日长 —— 它不是丢了,是还没到账。从「未知」变成「在途」,性质完全不同。

4月度趋势 · 这个月是例外还是惯例

演示数据(表格原文)78% 常态与 88% 常态是两种经营指标近 6 个月区间本店位置实收/支付比83.8% – 85.3%85.3% · 区间上沿健康退款率6.5% – 14.8%(渠道间)抖音14.8% 为主要拖累(与 DR-01 同源)未知差额频率6 个月中 4 次货到付款周期性 · 已查实趋势表建立后,月度对账从「每次从头查」变成「只看与基线的偏离」—— 对账的复利来自基线。

这一步的看点 · 该拦的地方拦住了结论写的是「这份对账报告还不能交给老板娘」—— 按老习惯,报告会写「差额 13.6 万,主要为退款与时差」—— 带着「等量未知」交上去,等于给下一次吵架留火种。给出的不是干等:报告按「已解释 97.2% + 在途 3,800(附 11 单货到付款订单号)」的结构交 —— 财务当天核完订单号即可闭环,两边的表第一次变成同一张。

第 5 步 · 对账报告 · 运营和财务同看一张

吵架日变对表日

演示数据(表格原文)交付物内容GMV 对账报告总差额四拆 + 凭证指向 + 6 个月趋势 + 82% 线判定待查明订单清单11 笔货到付款订单号 ·财务当日核完口径差异说明运营表与财务表的字段级对照(为什么两张表不一样)报告按「97.2% 已解释 + 3,800 在途」交 —— 但两个口径口径必须写死「在途」与「未知」一字之差,但决定下个月这3,800 会不会再吵一次 —— 货到付款 T+15 结算周期必须写进两张表的口径说明,否则财务下个月还是会把在途当差额。方案 A(推荐 · 当日交):报告按四拆结构交,附 11 笔订单号;口径说明加一行「货到付款按 T+15 结算,月度对账日存在固定在途」—— 下月起这部分自动进「可解释」区。方案 B(次日交):等 11 笔订单全部结算到账(T+15周期差 2 天)再交「零未知」版 —— 报告更完美,代价是对账日推迟、吵架风险多两天。另:抖音 14.8% 的退款率已连续两月上探 —— 对账报告只能看见它,解决它要靠 MD-02 的差评聚类与 DR-01 日报的每日跟踪。之后这一次跑完,公司多了什么

不讲省了多久 · 讲少了几个隐患、沉淀了什么

演示数据(表格原文)✓对账从「总额吵架」变成「逐项核减」—— 每分钱有去处✓货到付款这个每月 1.2 万的口径盲区被翻出 —— 从惯例变成已知✓实收比 6 个月趋势建立 —— 78% 常态与 88% 常态的经营信号分开了✓运营与财务第一次看同一张表 ——老板娘不用再当裁判追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果以后每月都要跑一次吗?建议月度固定跑(对账日 10 分钟)—— 首月建好基线后,后续只看异常项。能直接生成财务凭证吗?不能。我们产出对账报告与明细指向,凭证编制是财务系统的活。平台的预估扣点和实扣差是平台的错吗?不是错,是口径定义 —— 报表预估、结算实扣。把它写进口径说明,下个月这 8,000 的差额就进「可解释」区。

③ 能力沉淀(Skill / 提示词 / 预期输出 / 人工边界)

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

GMV 对账器(82% 告警线) · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

gmv-reconciliation.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是运营手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁DR-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

  • 01_支付宝及合并结算流水_8月.xlsx 财务侧的唯一真相 —— 实际到账
  • 02_生意参谋支付口径明细_8月.xlsx 运营侧的报表来源 —— 支付口径
  • 03_退款明细_8月.xlsx 差额拆解的第一变量
  • 04_平台扣点与服务费明细_8月.xlsx 差额拆解的第二变量
  • 05_近6个月到账与支付对照.xlsx 判断本月是例外还是惯例的趋势底稿

怎么用

  • 把素材全部拖进 WorkBuddy 对话框(不需要整理格式、不需要改文件名)
  • 粘贴下方提示词发送
  • 拿到正式件初稿 —— 签批栏留空,推荐意见留空,由你填

3. 提示词卡片

财务的到账流水、生意参谋的报表、退款和扣点明细都在这,帮我把差额拆清楚。 每一分钱都要有去处,拆不动的单独列出来别硬塞。 上几个月的流水也在这,看看这个月是例外还是老毛病。 最后要一份运营和财务都能认的报告。

为什么这么短就够了:短是因为「82% 验证线、差额四拆结构、串户排查规则」都在能力包里。对账这件事谁发起都行。

换成你自己的业务:把素材换成你手上的真实文件即可。导入 Skill 之后,

该走几步、什么口径、什么情况必须拦住,Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

  • 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说:什么事、什么文件、什么要求。不用讲究格式。
  • 调用 Skill 补齐专业规则 —— 导入本页 Skill 后,流程、口径、硬规则 Agent 自己知道。
  • 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮,把随口说的话补成更完整的表述。

分工:自然语言负责「这是什么事」,Skill 负责「该怎么做」,增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

  • DR-02_GMV 对账报告.xlsx 正式件本体 · 差额四拆 + 凭证指向 + 6 个月趋势
  • DR-02_待查明订单清单.xlsx 未知差额对应的单笔订单 · 供财务当日核完
  • DR-02_口径差异说明(运营-财务对照版).xlsx 两张表为什么不一样 · 各项口径定义并排

Skill 里固化了什么:从历史月份里发现了惯例性的窟窿该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:支付宝/微信月度到账流水财务侧的唯一真相生意参谋支付口径明细运营侧的报表来源退款明细(售中+售后)差额拆解的最大变量平台扣点与服务费明细第二变量

人工边界:不做「调账」—— 差额的账务处理是财务的事。本场景做的是把差额拆到可解释:退款、扣点、时差、串户,每一项带凭证指向。

升为客户真实案例还缺什么:客户当前真实输入文件(不要整理过的)岗位现行 SOP 与审批链(金额分档、谁签字)至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径(多少天算临期、多少金额算大额)

5. 同一角色下的其他场景

经营数据与口径治理 · 产出即下一步输入

DR-01 · 多平台经营日报(口径统一版) — 日报上 GMV 漂漂亮亮 · 老板娘问「钱呢」,支付口径和实收之间隔着15% 的水分 查看 →DR-03 · 周报一页纸 — 周报写了三年 · 老板娘从来没有翻到过第二页 查看 →DR-04 · 大促复盘报告(补断链版) — 818 大促 GMV 超了目标 15% · 退款潮 12 天后才来,复盘会开成了庆功会 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入,不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理,演示中的企业、人物与数据均为虚构,不代表任何客户的实际成效;痛点引用的公开来源已做脱敏处理。网页版由原资料转换,部分演示表格以原文形式展示。

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。

看运营其他场景