抖店动账场景 列名映射 解析脚本

一份抖店资金账单 CSV 有 39 列，5.5k–7k 行；每一行能同时塞下货款、服务费、佣金、补贴、退款 5 类核算项目。把这一行水丝当一行对账信息，还是当 N 条 BillRow？答案在动账场景 + 列名关键词「两级映射」。

一行账单里塞着 5 个非零金额

抖店商家后台导出的「资金账单」是电商行业最复杂的一类账单：它不像京东「结算账单」那样行=单笔交易，也不像支付宝「聚合结算」那样行=日切额。抖店一行水流的结构是这样的：

动账时间 | 动帐流水号 | 动账方向 | 动账金额 | 动账场景 | 子订单号 | 订单号
订单实付应结 | 运费实付 | 平台服务费 | 佣金 | 服务商佣金 | 渠道分成 | 招商服务费
实际平台补贴 | 实际达人补贴 | 实际抖音支付补贴 | 银行补贴 | 订单退款 | ...（共 39 列）

2026 年 7 月火枫官方旗舰店真实账单里有一行货款结算入账，动账金额 1250.00，但同时：

• 订单实付应结 = 1250.00（货值）
• 平台服务费 = 0.00（线上代码下未发具体折扣列）
• 佣金 = 0.00（直营小店）
• 实际平台补贴 = 0.00

「解析脚本要决定的就是这一行要变成 1 条、2 条还是 N 条 BillRow」。直觉做法是「按列名逐一识别非零金额，列=记录」，但这种做法的盲区在于：抖店有 7+ 种动账场景会让列名识别彻底失效——比如「消费者赔付」「小额打款」「抖音月付联合贴息」「提现」「上门取件运费」「拦截费」「评价有礼」这 7 个场景的动账金额并不落在任何「货值」「服务费」「佣金」这些「常规列」里，它们走的是专属动账场景——必须先识别「动账场景」这一列，再决定走哪条路径。

这就是「动账场景优先 + 列名兜底」这一解析体系的核心设计选择：优先级 1（动账场景精确/包含匹配）→ 优先级 2（列名关键词模糊匹配）→ 优先级 3（兜底按动账方向）。三级映射相互独立、互不混淆，覆盖了「常规货款 + 7 种场景专属 + 完全未识别」三个场景，形成一个有界、无歧义、可被运维单测验证的解析口径。

下文展开这套口径是怎么长出来的：动账场景的 9+ 类规则、列名关键词的 13 条规则、兜底的 2 个内置编码，以及怎么从「一行 CSV 流水」映射到「多核算项目 BillRow」。

一、动账场景：解析优先级 1（场景精确/包含匹配）

动账场景（CSV 第 6 列）是抖店资金账单的业务分类列，由商家后台根据交易类型自动填写。它会告诉解析脚本「这一行是什么性质的进出账」，优先级最高——会绕过全部列名匹配——动账金额（CSV 第 4 列）一对一映射到对应核算项目，符号按动账方向（入账/出账）自动决定。

实测 2026 年 5/6/7 月三份账单样本共出现 17 种动账场景，下表是 9 个优先级 1 命中规则（按代码 v3.3.12，2026-09-15 定稿）：

1.1 场景匹配的三个关键设计

设计点 1：精确等于 vs 包含匹配

7 个场景用「精确等于」匹配：「抖音月付联合贴息」「上门取件运费」「小额打款」这些商家后生名字写一不一都不能命中。「拦截」/「提现」则用「包含」匹配：商家后生可能写「快递拦截费」「提现手续费」，只要含关键字都命中。这是「严格优先 + 宽容补充」组合：首选精确匹配是因为商家后生命名稳定。

设计点 2：包含匹配同时看「备注」列

「拦截费」特殊场景会进「备注」列以「拦截费_YT…」开头，动账场景列反而是空的。脚本同时看两个字段：「场景含「拦截」 → 命中」「备注以「拦截费」开头 → 命中」，二者任一即可。包含判断双列同时进行，是为了覆盖商家后生不走主场景列的低概率变动。

设计点 3：v3.3.10 反转——消费者赔付从费用改负收入

这是 2026-09-08 发生的关键反转。

这是 2026-09-08 发生的关键反转。之前代码 v3.2.0→v3.3.9 把「消费者赔付」映射为 ZC.DOUYIN.XIAOFEIZHEPEIFU（费用），但用户实际看账后确认这是「收入冲减」不是「费用」。v3.3.10 一次性反转：

v3.3.9：消费者赔付 → ZC.DOUYIN.XIAOFEIZHEPEIFU（费用，出账记正费用）
v3.3.10：消费者赔付 → SR.DOUYIN.XIAOFEIZHEPEIFU（收入类，出账记负收入）

反转后「消费者赔付」与「小额打款」同口径，都是「出账→负收入」。同时需要同步推动下游：转换规则表停用旧 ZC 条目、启用新 SR 条目；存量 7 月 4 行已定向修补为反向行。这是「变动以代码为主、转换规则只腿」的一个真实代价：必须配 1 条 ZC 停用 + 1 条 SR 启用，否则旧 ZC 负项还会进应付单。

1.2 提现行：业务订单号改成「动帐流水号」

提现行在 CSV 里没有业务订单号（动账场景=「提现」时订单号列为空），但解析脚本必须输出 businessOrderNo 字段。这一改动是轻易云智能对账系统 7 月批量解析时定稿的关键设计之一。v3.3.4 之前临时填个空字符串，导致提现行被同号合并、变成「无单号合并成一条分录」的奇怪状态。v3.3.4 定稿：

if (!sceneMatched && scene.indexOf("提现") !== -1) {
  // 动账场景含「提现」→ DOUYIN.TIXIAN，按出账记费用
  pushMovementRecord("DOUYIN.TIXIAN", "fee", cleanOrderNo(rawData["动帐流水号"]));
  sceneMatched = true;
}

businessOrderNo 改成取「动帐流水号」（dy + 日期 + 序号，例如 DY260701000001）。这样提现行有了「业务订单号」，同时转换层以「动帐流水号」为单号入账，多个提现行各自独立、不撞单。

1.3 优先级 1 命中即返：场景识别高于一切

优先级 1 命中后，脚本立即返回 results，不再走列名匹配。这是一个看似反直觉但必要的选择：如果「上门取件运费」场景里有动账金额 50 元，但同时订单实付应结列里也有 50 元（商家后生某些变动会导致），脚本会优先走场景，不加注到一个本不该出现的「订单实付」上。这靠的是优先级的「互斥性」：场景命中后不再走列名，避免同一动账金额被多个会计项识别。

二、列名关键词：解析优先级 2（一行按列拆多条）

如果动账场景不在 9 个命中规则里、也不是「拦截」/「提现」，脚本退到优先级 2：按 rawData 的列名逐一匹配，每命中一个非零金额列生成一条独立记录。

这条线是抖店资金账单的「主战场」——2026 年 7 月火枫店主场景「货款结算入账」占总行数 ~90%，主场景全都是列名匹配打出。

2.1 13 条列名关键词规则（按 v3.3.12）

2.2 「订单实付应结」固定首条

13 条规则里有 1 条与其它不同：「订单实付/订单实付应结」固定作为第一条记录写回父行。这是 v3.2.0 的设计选择。沙箱返回多条记录时，服务层需要决定写回哪一条到父行的 main_field（业务订单号列、incomeAmount/feeAmount、parseStatus）。PostgreSQL JSONB 字段虽然不保证 rawData 列顺序，但服务层从沙箱取数组第一条的代码逻辑必须可控——如果「订单实付」不是第一条，父行的金额汇总可能是个「佣金」或「平台服务费」值，这是个反直觉但危险的隐性 Bug。

// 「订单实付/订单实付应结」固定排在第一条
const orderPaidKeys = [];
const otherKeys = [];
for (let i = 0; i < keys.length; i++) {
  const key = keys[i];
  if (includesAny(key, ["订单实付", "订单实付应结"])) orderPaidKeys.push(key);
  else otherKeys.push(key);
}
const orderedKeys = orderPaidKeys.concat(otherKeys);

这是「业务逻辑控制列顺序」的一个现实例子：rawData 是 JSONB，沙箱代码手动重排 keys 保证父行拿到的总是「订单实付」。同口径在淘宝、京东、拼多多的解析脚本里也都有体现。

2.3 补贴细分：4 个独立核算项目

v3.2.0 把「实际平台补贴」一类拆成了 4 个独立核算项目：

实际达人补贴      → SR.DOUYIN.DRBT
实际抖音支付补贴  → SR.DOUYIN.ZFBT
实际抖音月付营销补贴 → SR.DOUYIN.YFYCBT
其余补贴          → SR.DOUYIN.BUTIE

这是一个在「批量节约核算项目」与「精细度曝光」之间的折衷。设计点在于「精准者」要拆分，「不确定性」合并：

• 「达人补贴/抖音支付补贴/月付营销补贴」三个是平台明确定义、互不交叉、不可能属于其他——拆开
• 「实际平台补贴_运费」「其他平台补贴」「以旧换新抵扣」「政府补贴平台垫资」「银行补贴」这 5 列含义重叠、商家后生变动频繁、拆分只会增加错误率——合并成 BUTIE

这个「3+5」的拆分是商家后生变动实测后提炼的「最稳状态」。

2.4 退款负收入与费用列取负的统一语义

列名匹配还隐含两个「符号反转」设计：

反转 1：订单退款列恒正 → 转负后入账。CSV 里「订单退款」列含义是「本期退款额」（恒正），但按金额符号统一语义（2026-08-05 定稿），退款必须是负收入。脚本主动 toNegative(amount)：

if (includesAny(key, ["订单退款"])) {
  pushIncome("SR.DOUYIN.TUIKUAN", toNegative(amount));
  continue;
}

反转 2：费用类列取负落库。抖店费用类列（平台服务费、佣金等）原始负值 = 正常扣费、正值 = 平台返还。脚本统一 negate() 取负：扣费→正 feeAmount，返还→负 feeAmount。这是「原始语义不变 + 库内口径统一」的折衷。

两个反转加起来，库里 incomeAmount/feeAmount/amount 三列始终是「收入正、费用正、退款负、返还负」，下游对账脚本不再需要重判符号。跨平台对账（多门店、多平台汇总报表）能省下一道反复逻辑。

三、案例段：2026 年 7 月「同一订单 4 类补贴」实战验算

把两级映射拼起来看一场实战。2026 年 7 月火枫店某订单（订单号 6951000000000004）：

动账场景=货款结算入账，方向=入账，动账金额=2,399.00
订单实付应结 = 2,399.00
平台服务费 = 119.95
佣金 = 239.90
实际平台补贴 = 0.00

3.1 优先级 1 校验

动账场景「货款结算入账」不在 9 个命中规则里，也不含「拦截」/「提现」。优先级 1 未命中，进入优先级 2。

3.2 优先级 2 拆分

按 orderedKeys 顺序扫描 4 个非零列（实际只有 3 个非零，「实际平台补贴」是 0 跳过）：

第 1 条：订单实付应结 2,399.00 → SR.DOUYIN.GOODS_SALES（MAIN_INCOME）
第 2 条：平台服务费   -119.95 → 取负 → 119.95 → ZC.DOUDIAN.PDFWF
第 3 条：佣金         -239.90 → 取负 → 239.90 → ZC.DOUDIAN.YJ

输出 3 条 BillRow。商品名称不是「用户向商家打款」，不走 YHXSJDK 分支；没有「运费实付」「免佣金额」「实际达人补贴」等其他非零列，1 行只拆 3 条。

3.3 下游验证

3 条 BillRow 各自的 bizType 决定去向：

GOODS_SALES（MAIN_INCOME）  → 收入对账池（与金蝶暂估应收单匹配）
PDFWF（OTHER_FEE）           → 费用对账池（公摊到已确认收入体行）
YJ（OTHER_FEE）              → 费用对账池（同上）

收入对账账期 7 月里，这一单 2,399.00 进入收入对账计划体行；与供应链订单同号正行 2,399.00 严格相等匹配（R1 主匹配），结果 = SUCCESS。两条费用进入费用对账计划，按已确认收入体行的 |incomeAmount| 占比分摊，反写 allocatedFeeAmount。

3.4 7 月锚点回验（生产环境实测）

这项验算按业务真源（2026-07 火枫店锚点）：752,530.72 / -83,923.78 / 668,606.94。也就是说 7 月所有 BillRow 的收入合计应为 752,530.72、费用合计应为 -83,923.78、净额 668,606.94。这三个数字是 7 月任何动账、转换、推送调整后验算的「试金石」。如果动账场景、列名关键词任何一条映射规则调整，这三个数字都会变，必须重调。

这种「数字双错位一调整就动」的设计是上线后的代价，但也是「变动可量化」的代价：随便一条规则变动，金额动一动就知道有没有拍反。

四、兜底与异常：优先级 3 + 解析失败闸

如果动账场景不在 9 个命中规则里、列名匹配也全部 0 值（无任何非零金额列），脚本走优先级 3：按动账方向分别归入 SR.DOUDIAN.QTST（入账 → 其他收入）或 ZC.DOUDIAN.QT（出账 → 其他费用）。方向未知（既不是入账也不是出账）则记录仍会输出但标记异常 unknown movement direction: xxx。

4.1 解析后双零：全局 FAILED 闸（2026-08-06 定稿）

2026-08-06 定稿后还有一个全局闸：解析写回后 incomeAmount 与 feeAmount 同为 0 的行由解析执行层统一判 parseStatus = FAILED。这是「动账金额 0」「场景未命中 + 所有列都为 0」「异常行 + 金额解析失败」三种姿势的统一门口。例如：

• 一行货款结算入账但所有金额列都是 0（商家后生导了空行）→ 解析后 incomeAmount=0、feeAmount=0 → 闸判 FAILED，不进任何对账池
• 「提现 0 元」这类上几期走收谷期 0 元提现的行 → 闸判 FAILED，不再加拍为「需人抹个零」
• 异常行金额解析失败 → safeParseDecimal 返回 0、inAbnormal=true → 闸判 FAILED（但不丢 inAbnormal 标记）

这条闸在上线后补救了「提现 0 元」漏洞：以前会走到费用对账池里变成一条 0 元费用体行，下游反写时可能误拍为「费用合计 0」、这个 0 会加到提现 7 月上期总里。到 8 月定稿后零元提现直接 FAILED，不再加拍。

4.2 场景未命中 + 部分列非零的「半映射」

另外一个被闸保护的边界是「场景未命中但有列非零」。例如某个商家后生出现一个新场景名「上门取件-支付快递费」（v3.3.5 才加上入映射表）：

• v3.3.4 及之前：场景未命中，列表里有「上门取件-支付快递费」列 × 1 元 → 走优先级 2，列名匹配未中（列名不是任何 13 条规则的关键字），最终落到优先级 3 → ZC.DOUDIAN.QT 其他费用
• v3.3.5：场景「上门取件-支付快递费」加入映射表 → 优先级 1 命中 → ZC.DOUDIAN.ZFKDF（独立核算项目）

这个变动是 2026-09-03 用户定稿后一次补充：原本代码会静默落入「QT 其他费用」与 Excel 手工「其他费用」反同，但转换规则表里没有 QT 条目 → 不进应付单，计算结果是负 0。这条修订代价是必须在转换规则表同步加 ZC.DOUDIAN.ZFKDF 条目，否则场景映射加上去、但转换下推还是会拍反。这就是「场景映射必须与转换规则双向同步」的一个典型代价。

五、沙箱可靠性与版本演进链

脚本在 isolated-vm V8 context 隔离的 Parse 沙箱里跑，逐行执行，每行隔离 30 秒闸，沙箱本身带 SIGKILL 强制终止、stderr 前 500 字符异常输出、durationMs 性能指标。沙箱只读 query 能力只能调 findMany/findFirst/findUnique/count/aggregate/groupBy，denylist 拒绝 user/appKey/systemSetting 三个模型，不会被非法访问后台数据。这套沙箱架构由轻易云智能对账系统 4 类脚本（parse / reconcile / allocate / transform）共同复用，抖店资金账单解析脚本是其中最复杂的代表例。

5.1 12 版迭代的代价链

抖店解析脚本从 v3.2.0 到 v3.3.12 迭代 12 版，每次变动都绑死业务口径反转。完整代价：

v3.2.0 补贴细分 4 科目 + 费用细分 4 科目
v3.3.0 用户向商家打款 → SR.DOUYIN.YHXSJDK
v3.3.3 向商家打款 → 追加 -仅对账记录（JYDZ）
v3.3.4 提现行业务订单号 → 动帐流水号
v3.3.5 新增场景：退换货运费险、上门取件-支付快递费
v3.3.6 向商家打款 -仅对账记录金额 → 带符号透传
v3.3.7 -仅对账记录仅当供应链订单存在才生成
v3.3.8 -仅对账记录生成条件加严（仅未下推收入）
v3.3.9 向商家打款 不再追加 -仅对账记录（JYDZ 下线）
v3.3.10 消费者赔付 → SR.DOUYIN.XIAOFEIZHEPEIFU（负收入）
v3.3.11 上门取件运费 → feeNeg（出账记负费用）
v3.3.12 评价有礼 → ZC.DOUDIAN.PJYL

这是一个「v3.2.0 起步→v3.3.12 定稿」长达数月的代价链。每一版变动都拍回边界、产生试跑反馈、合并下一版。这个演进路径中体现了「脚本版本必须可追溯」的设计：脚本 history JSON 字段记录每版代码，定部在 seeds 里与生成日期绑定。

如果以一个反直觉的点看，「评价有礼」这个场景名在 2026-09-15 才被加上映射表，是因为 7 月账单里出现了这个场景、商家后生写入了这个场景名，但优先级 1 未命中 + 列表均不含「包含评价有礼」这样的关键字 → 静默落到 QT 其他费用 → 转换表无 QT 条目 → 不出应付单。这就是「脚本代价必须带历史账账」的实际代价。

六、原始账单结构与服务层机械拆分

抖店导入服务在机械层按列位置（record[0]…[38]）映射 39 个命名字段，同时以表头为键存 rawData JSON 供沙箱脚本使用——这一层不负责业务判断，只负责「列位置 → 字段名」的机械翻译：

buildRow(record[0..38]) {
  movementAmount = parseDecimal(record[3])  // 动账金额
  direction      = cellToString(record[2])  // 动账方向
  // 导入初值：出账 → feeAmount=动账金额；入账反之
  // amount = incomeAmount − feeAmount
  // 业务归类以解析脚本输出为准
  return { ..., rawData: buildRawData(headers, record), direction, scene, ... };
}

buildRawData 把表头 + 当行内容拼成 { "动账时间": "...", "动帐流水号": "...", ... } 的 JSONB，注入沙箱脚本里的 rawData["动账方向"] / rawData["动账金额"] / rawData["动账场景"] 都能拿到原始字符串，不受列位置变动影响。这是「沙箱脚本以 rawData 键名驱动」与「服务层以列位置机械拆分」双层隔离的设计：商家后生列顺序变动时，服务层只要更新 record 索引，沙箱脚本完全不用改。

七、收尾

动账场景 + 列名关键词「两级映射」看起来是动账场景 9+ 条 + 列名 13 条总计 22 条规则，但在业务上是一个「有界、无歧义、可被运维单测验证」的解析口径：每一行只会走 1 动账场景路径或 2 变量名路径、不会两个都中；异常行清晰拍为 QTST/QT + inAbnormal；金额符号反转清晰拍为转负、取负；「解析后双零」闸拍为 FAILED。

这套口径在 2026 年 7 月火枫店试跑，账单收入合计 752,530.72、费用合计 -83,923.78、净额 668,606.94，双错位一调整就动，设计上「变动可量化」。

拍设计之外的代价是沙箱本身：isolated-vm V8 隔离 + 30 秒闸 + SIGKILL 强制终止 + stderr 异常输出 + durationMs 性能指标。抖店资金账单的解析脚本是「最复杂的代码实例」之一，与对账、费用分摊、集成转换 3 类脚本合起来是 4 类沙箱脚本的代表例。

如果你正在设计多平台账单解析层级，「优先级 1 动账场景 + 优先级 2 列名关键词 + 优先级 3 动账方向兜底」这个三级映射架构是个可以套用的模板：每一级负责一个场景、每一级不重复另一级、每一级都有明确的产品型门 — 从这个角度看，动的不是脚本、是业务口径。

延伸阅读

• 4 类沙箱脚本契约（parse / reconcile / allocate / transform）与试跑端点设计，可参考生产团队维护的「Parse Script 沙箱契约」文档（项目内 SKILL 仓库按主题检索 parse-script-development）
• 新平台接入对账脚本与集成转换脚本的通用经验总览，含跨平台踩坑清单与四级验证防线，可参考生产团队维护的「新平台脚本接入」总 skill（项目内 SKILL 仓库按主题检索 platform-script-onboarding）