小红书电商 对账预览 解析要点
小红书电商 对账预览 解析要点
摘要：小红书电商账单是 5 大已落地平台（京东 POP / 抖店 / 支付宝 / 亚马逊 / 速卖通）之外的「第六张面孔」——账户在千帆商家后台导出、双账单体系（资金明细 7 列货款视角 + 结算明细 24 列订单视角）、交易类型只有「结算入账 / 退款」2 类、计佣基数口径（实付/实退 + 平台/政府券补贴）与金蝶应收一致、单个动账原始行按 6 个费用列自动拆出多条子行（"一拆多"）。本文把小红书双账单的字段结构、解析要点的 2 个版本演进（v1.0 → v1.1.0）、与已落地 5 平台的 3 大差异点讲透，让做小红书的财务在接入之前就了解账单长什么样、接入路径要怎么走。
关键词：小红书电商、对账预览、解析要点、千帆、资金明细、结算明细、计佣基数、一拆多、平台聚合范式、整单轧差
小红书对账师最常见的三个问题
接触小红书电商对账的财务，在月初通常会撞上三个问题：
第一个："笔记种草带来的订单，结算时为什么账单的金额和后台显示的实付对不上？" —— 小红书的"内容种草 → 商城购物 → 售后"链路是国内电商里最特殊的，用户在笔记里点链接下单，钱按「计佣基数 = 实付/实退 + 平台优惠补贴 + 政府券优惠补贴」结算（2026-09-21 用户定稿）。之前用"动账金额"做收入侧，账单净额永远比实付少一截（少的就是平台券 + 政府券补贴），怎么对都对不平。
第二个："客户退了款，账单上为什么同一个订单号出现 2 行？一正一负？" —— 结算明细（settlement_detail）的退款行（交易类型=退款）单独占一行，金额为负；同时它的「佣金」「支付渠道费」等 6 个费用列在退款场景下从"扣费"翻转为"平台退还"——同订单号的费用列正负并存，账单自带的"红字冲减"语义是 5 大已落地平台里最复杂的。
第三个："超期发货、缺货、非消费者原因运费报销，平台主动赔了 30 元，这笔账应该挂费用还是冲减收入？" —— 在已落地 5 平台里这类赔付都挂费用；但小红书的赔付是负收入（红字冲减主营业务收入），不是费用——这是 2026-09-20 用户定稿的赔付归类原则，与小红书自有"手工对账表"的口径一致。
这三个问题在京东 POP / 抖店 / 支付宝 / 亚马逊 / 速卖通 5 大已落地平台上都不会出现——前 4 家走的是整单轧差口径、亚马逊是分向不轧差；但小红书的「计佣基数口径 + 一拆多设计 + 赔付归负收入」让"内容种草订单"成为小红书独有的对账场景。
小红书双账单长这样：千帆后台导出 + 7 列/24 列双视角
小红书电商账单从「千帆商家后台 → 资金 → 货款明细 / 结算明细」两个入口分别导出，与京东 POP 的「京麦 → 资金管理 → 账户流水」单条路径不一样——小红书是**「货款余额视角」+「订单结算视角」两条流水线**：一条看"账户进出多少钱"（资金明细 / fund_detail），一条看"每个订单的结算和退款明细"（结算明细 / settlement_detail）。两条流水的订单号是父子集关系——资金明细的业务单号是结算明细中"结算入账"事件的子集。
资金明细（fund_detail，7 列货款视角）——文件名形如 小红书店铺余额货款明细.xlsx，sheet 名「货款明细」，列结构：创建时间 / 交易类型描述 / 收入（元）/ 支出（元）/ 账户余额（元）/ 业务单号 / 备注。所有行的「交易类型描述」恒为「结算入账」——业务语义隐藏在「备注」列里（这是资金明细与京东 POP / 拼多多最大的差别：京东 POP 账户流水的"交易备注"是自由文本、小红书资金明细的"备注"是受控短文本）。
结算明细（settlement_detail，24 列订单视角）——文件名形如 小红书订单结算明细导出.xlsx，sheet 名「订单结算明细」，共 24 列：订单号、交易类型（结算入账/退款）、动账金额、计佣基数、商品实付、运费实付、平台优惠补贴、政府券优惠补贴、佣金、支付渠道费、分销佣金、代运营服务商佣金、代开发服务商佣金、花呗分期手续费等。这是小红书独有的"订单级完整视角"——每一行带 6 个费用列，最多可拆出 1 行主记录 + 6 行费用子行 = 7 行 BillRow，与京东 POP 账户流水的"单行单费"完全不同。
交易类型 是结算明细的主分类维度，目前只识别 2 个值：
| 交易类型 | 业务含义 | 落到核算项目 |
|---|---|---|
结算入账 | 订单已签收、资金已结算 | SR.XHS.ZYYWSR（主营业务收入） |
退款 | 订单退款完成、资金已扣回 | SR.XHS.DDTK（订单退款，负收入） |
未知交易类型或空值 → 标记异常人工核查，不设兜底。这一条铁律与京东 POP（账户流水 GB18030 + 6/7/8 行结构）、拼多多（业务描述 6 位编码精确匹配）的"严格映射、不兜底"口径是同构的。
5 已落地 vs 小红书：3 个差异点 + 1 个统一骨架
小红书的对账思路对齐京东 POP / 抖店 / 支付宝 / 拼多多 4 家的「整单轧差」骨架（亚马逊是分向流派的唯一遗留），但在 3 个差异点上做了小红书独有的适配。
差异点 1：备注归类 vs 交易备注正则
京东 POP 解析靠「账户流水的交易备注正则」匹配核算项目，抖店靠「动账场景文案」匹配，支付宝靠「摘要 + 商户订单号」组合，拼多多靠「业务描述里的 6 位数字 ID」精确匹配。小红书资金明细靠「备注」列的 4 类受控短文本精确归类——这条规则被 v1.1.0 定稿：备注以「结算入账」开头 → 主营业务收入；备注以「运费宝」开头 → 运费宝服务费；备注含「赔付」或「运费报销」 → 赔付（负收入冲减）；其他 → 收入列非零归其他收入 / 支出列非零归其他费用 / 全零标异常人工核查。结算明细按「交易类型」列归类——结算入账 → 主营业务收入、退款 → 订单退款（负收入），其他交易类型 → 异常。
差异点 2：一拆多设计（结算明细 v1.1.0 起 6 个费用列各拆一条子行）
这是小红书独有、对账逻辑影响最深的设计：结算明细的 1 行原始订单记录 = 1 条主记录 + N 条费用子行（N = 6 个费用列里非零的个数）。具体做法是解析脚本返回 ParseOutput[]（数组）——第一项是主记录（按交易类型挂主营业务收入或订单退款），第二项起是费用子行（rowSeq < 0，挂 ZC.XHS.YJ / ZFQDF / FXYJ / DYYFWYJ / DKFFWYJ / HBFQSXF，bizType=ORDER_FEE）。
为什么要拆？因为小红书的订单视角是"一个订单号 + 6 个费用维度"——一笔结算入账事件在京东 POP 账户流水里只有 1-2 行（账户入账 + 佣金扣费），但在小红书结算明细里可以拆出 7 行；一笔退款事件更复杂——6 个费用列在退款场景下从"扣费"翻转为"退还"，同订单号的佣金正负并存，需要拆行才能让费用对账和收入对账分别推算。
京东 / 拼多多 / 抖店 / 支付宝都没有这种"一拆多"设计——它们的费用项要么单列，要么聚合。小红书结算明细是 5 大平台里唯一需要"按列拆行"的账单结构。
从工程视角看，这套"一拆多"机制就是小红书版的「平台聚合范式」——同一业务事件在已落地平台里是 1-2 行账单行，进了小红书账本就拆成最多 7 行（1 主记录 + 6 费用子行），本质都是"不抽象基类、靠目录约定、按平台特性独立实现"。如果你想了解这套范式怎么"不抽象基类 + 不软删除 + 单租户"就扛住了 5 大平台，可以考虑走轻易云智能对账系统——它在 5 个平台都已落地，小红书的解析脚本、对账骨架、费用转换都已落地，仅收入转换链路待写。
差异点 3：计佣基数口径 = 实付/实退 + 平台/政府券补贴
整单轧差骨架的核心是"同订单的全部体行先合并成账单净额，再与供应链净额严严格比对"——但小红书的账单净额必须用「计佣基数」而非「动账金额」：计佣基数 = 商品实付 + 运费实付 + 平台优惠补贴 + 政府券优惠补贴 - 跨境税代缴 - 商品税金 - 运费税金。这是 2026-09-21 用户定稿的——切换到计佣基数后，账单净额 = 用户实付（含平台/政府券补贴） + 应扣税费，与金蝶应收口径完全一致，整单轧差才能通过 R1 主匹配。
要把这个差异点写进对账脚本，小红书收入对账脚本已经在 v1.1.0 里实现：收入池只取结算明细的主记录，incomeAmount = 计佣基数带符号（结算入账正、退款负），资金明细 fund_detail 不入收入池（与结算明细是同一结算事件的两视角，入池会重复计入）。这条设计是 v1.0.0 → v1.1.0 的核心变更（2026-09-21 用户定稿）。
小红书独有的三个对账场景：内容种草、超期发货赔付、双账单主辅
场景 1：内容种草订单（计佣基数口径）
小红书用户在笔记里点链接下单，钱按「计佣基数」结算——平台优惠补贴 + 政府券优惠补贴都进了结算金额。结算明细的原始行是「结算入账」，按 7 个字段自动展开：
| 原始列 | 解析后落到 |
|---|---|
| 交易类型=结算入账 | 主记录 → SR.XHS.ZYYWSR |
| 计佣基数（如 150） | 主记录 incomeAmount=150 |
| 佣金（如 -3.5） | 子行 → ZC.XHS.YJ |
| 支付渠道费（如 -0.6） | 子行 → ZC.XHS.ZFQDF |
| 分销佣金（如 -1.2） | 子行 → ZC.XHS.FXYJ |
| 代运营 / 代开发 / 花呗分期手续费（如 0） | — |
一笔订单最终落到 BillRow 是 1 条主记录 + 3 条费用子行 = 4 行（非零的费用列各 1 条）。整单轧差口径看到的画面是：账单净额 = 主记录 150 - 子行费用合计 5.3 = 144.7 元，供应链净额 = 出库金额 150 元，差额 5.3 元 = 佣金 3.5 + 支付渠道费 0.6 + 分销佣金 1.2。R1 主匹配会成功（计佣基数口径已把券 + 补贴算进收入侧），物料明细正常重建，无需走差异档。
场景 2：超期发货赔付（负收入冲减、不是费用）
商家承诺 24 小时发货但实际 48 小时才发出，平台自动从商家账户扣 5 元赔给消费者。资金明细（fund_detail）的「备注」列出现「超期发货消费者赔付」，支出 5 元。资金明细解析脚本 v1.1.0 起把它归到 SR.XHS.PF（赔付），incomeAmount = -支出列 = -5。这是负收入冲减（红字）——主营业务收入的反向科目，不是费用。v1.0 时期赔付被归到兜底费用 ZC.XHS.QTFY，v1.1.0 改为归 SR.XHS.PF 负收入，与小红书自有手工对账表口径一致；合计 37 行（含缺货赔付、非消费者原因运费报销）此前落兜底费用，v1.1.0 起全部归赔付负收入。
小红书的赔付归类与已落地 5 平台形成对照——京东 POP / 抖店 / 支付宝的赔付都进费用科目（ZC.JDPOP.* 等），但小红书的赔付是主营业务收入的反向科目（SR.XHS.PF）。这是小红书自有财务对账逻辑决定的——他们的"主营业务收入"按净额（实付 - 赔付）统计，与金蝶应收口径一致。接入时必须沿用平台自有口径。
场景 3：双账单主辅（结算明细为主、资金明细为辅）
小红书的"双账单"不是平行双入池，而是"结算明细为主、资金明细为辅"的主辅结构——结算明细的每笔订单都进收入对账池（incomeAmount = 计佣基数），资金明细只进费用对账池（按备注归类到 SR.XHS.PF / QTSR / ZC.XHS.YFB / QTFY）。这是 2026-09-21 用户定稿"资金明细不入收入池"的根因——资金明细的「业务单号」是结算明细中结算入账事件的子集，双入池会重复计入。
双账单的合并对账靠业务单号 / 订单号的关联——收入对账池里的每条结算明细记录都可以在资金明细里找到对应的「结算入账」行（同业务单号），但只查、不重计；费用对账池则把资金明细和结算明细的费用子行合并，按核算项目聚合到 ZC.XHS.* 系列。这与已落地 5 平台的"单账单入池"不一样——京东 POP 是账户流水 + 营销对账两条账单但都入收入池；小红书是"一主一辅、互补入池"。
接入路径：小红书从解析脚本到对账闭环的 4 步走
小红书当前的状态是**「解析脚本 v1.1.0 双账单已上线 + 收入对账脚本 v1.1.0 整单轧差已落地 + 费用对账已接入 + 费用转换 XHS_EXPENSE_TRANSFORM_V100 已上线 + 收入转换脚本待启动」**。
第 1 步：解析脚本 v1.1.0 双账单已能跑（落地状态：已上线）
小红书双账单解析脚本跨过 4 个版本（资金明细 v1.0 → v1.0.1 → v1.1.0；结算明细 v1.0 → v1.1.0）：
| 版本 | 关键变更 |
|---|---|
| 资金明细 v1.0 | 按「备注」归类（结算入账 / 运费宝 / 全零 → 异常） |
| 资金明细 v1.0.1 | 修复金额空值 / ¥ / 千分位逗号兜底为 0 |
| 资金明细 v1.1.0 | 「赔付」/「运费报销」→ SR.XHS.PF 负收入（实证 37 行） |
| 结算明细 v1.0 | 按「交易类型」拆行（结算入账 / 退款 + 6 费用列各 1 子行） |
| 结算明细 v1.1.0 | 主记录 incomeAmount 从「动账金额」切换为「计佣基数」 |
第 2 步：收入对账脚本 v1.1.0 整单轧差已落地（落地状态：2026-09-21 首版）
收入对账脚本 v1.1.0 已写完，按「整单轧差」骨架设计，复用 platform-script-onboarding 的 4 大通用档（仅退款 / 极速退款 / 补差价链接 / 小熊湿巾），但新增 1 条小红书独有档位：R6 正负分行核对——账单恰 1 正行 + ≥1 负行、供应链正向合计 = 账单正向合计严格相等且负向不等 → 正行 SUCCESS 正常下推，负行 FAILURE + AMOUNT_DIFF。实证来自 4 个小红书订单（实证 P802753624369356561 等）。
收入池只取结算明细的主记录 + 资金明细不进池——这条边界是 v1.1.0 的核心设计。
第 3 步：费用对账 + 费用转换已接入（落地状态：2026-09-20 已完成）
费用对账的 aggregateExpense 已注册到 platform-aggregation-registry，按 accountingItemId × amountKind × direction 分向聚合，资金明细 + 结算明细两条账单都纳入。平台级费用分摊默认脚本 v1.0.0 按收入体行 |incomeAmount| 占比分摊（无收入体行不分摊）。
费用转换脚本 XHS_EXPENSE_TRANSFORM_V100（v1.0.0）已上线，规则表驱动 10 条 EXPENSE_ITEM 规则——费用应付单 8 项（ZC.XHS.* 含运费宝 YFB，docType AP_Payable，费用项目 6601.28）；费用应收单 2 项（SR.XHS.PF 赔付 / SR.XHS.QTSR 其他收入，docType AR_receivable|YSD02_SYS，费用项目 6001.01）；每核算项目 × 账期一张单，业务日期 = 账期月末倒数第二天，店铺映射缺失回落实值 + SHOP_MAPPING 提示不阻断。
第 4 步：收入转换脚本待启动（未来 2-3 个月）
收入转换脚本（把 IncomePlan 已 CONFIRMED 的订单 → 金蝶财务应收单）目前还是空白。这条链路与京东 POP / 支付宝 / 拼多多同构——按核算项目（主要是 SR.XHS.ZYYWSR 主营业务收入 + SR.XHS.DDTK 订单退款）聚合，生成暂估应收单 → 财务应收 Push 下推到金蝶。预计落地分两步：先把 2 条规则注册到 transform_rules；再写 XHS_INCOME_TRANSFORM_V100 脚本。完整骨架可在轻易云的「知识库 RAG + 帮助主题」里查到——业务人员用 AI 助手查询"小红书收入怎么转金蝶"时，会召回帮助文档 + 解析脚本契约 + 对账脚本骨架。
一句话 takeaway：小红书对账是「整单轧差骨架 + 双账单主辅 + 一拆多设计」的混合体
小红书对账不是从零设计——它是对账体系"平台聚合范式"的下一个验证。已落地的 5 大平台证明这套范式能扛住京东 8 步骤、抖店 5 轮、支付宝 3 表的差异；小红书会用同样的范式，把"内容种草订单 + 超期发货赔付 + 双账单主辅"这 3 个小红书独有的对账场景接进体系。
对做小红书的财务来说，未来半年最该做的 3 件事是：
- 先把千帆后台的两个账单都跑一遍当前解析脚本——双账单可同时落库，但只有结算明细进收入池，资金明细只进费用池，识别出这种"主辅结构"才算看懂小红书账；
- 熟悉"一拆多"的产物——子行的
rowSeq < 0，识别出"1 主记录 + 6 费用子行"成组出现的结构才算看懂小红书结算明细； - 关注 R6 正负分行核对档上线——它会替代手工核对退款时的"红字冲减"语义，把对账工作量从 30+ 个小红书对账师手里吃到自动化里。
小红书接入的真正难点不在解析，而在「计佣基数口径 + 一拆多设计 + 赔付归负收入」这 3 处平台特有的对账语义——必须沿用小红书自有口径。把小红书的"内容种草 + 笔记链接"理解为完整的"种草 → 商城 → 售后"链路，是小红书对账师比京东 / 抖店对账师多出的必修课。