亚马逊收入对账 v2.0：分向 + 7 机读码差异标签的实操
亚马逊收入对账 v2.0：分向 + 7 机读码差异标签的实操
一份 65.0% 的基线：跨境对账里最容易被低估的"分向"
2026 年 6 月德国站（德站）第一次跑亚马逊收入对账脚本，结果贴在财务部周会上：2,473 个订单只对平 1,607 个，成功率 65.0%。同一时期，京东、抖店、支付宝对账脚本的成功率已经稳定在 99% 以上。财务总监的第一反应是「亚马逊数据是不是没拉对」——但这不是数据问题，是亚马逊的业务结构问题：它的结算资金明细里每一笔钱都按方向（正 / 负）拆开记，京东那套"整单轧差 = 净额对净额"的玩法在亚马逊这里行不通。
[来源：2026-09-06 亚马逊收入对账脚本 v2.0.0 用户确认版] 这 65.0% 不是败笔，而是分向派对账流派的起点——它是后续 99.6% 的地基。把"分向"和"7 个机读码差异标签"这两个核心概念摸透，亚马逊对账就从"看起来对不上"变成"全月 4,318 单全自动对平"。
这篇文章要做的事，是把 v2.0 这个版本里沉淀下来的两条主线（分向过滤 + 方向化 3 标签 + 诊断 4 标签 = 7 个机读码）一次性捋清楚。不是营销话术里的"全自动化"，是 2026-09 这一时刻的工程现状；其中 4 个标签可以直接判 SUCCESS 收口，2 个标签走人工兜底，1 个标签是金额差异的总兜底。
一、为什么亚马逊必须是"分向"——其他平台整单轧差行不通
做亚马逊对账，第一次和京东对账思路撞车的人最多。京东 8 步骤整单轧差——同一订单的收款、退款合并成净额，最后 diff = Σ订单收入 − Σ订单退款 − Σ供应链合计，等于 0 就过。亚马逊不行。
京东一单一笔钱，亚马逊一单一笔钱，但亚马逊的钱是按方向拆开的：同一订单的正向销售款（商品价格总额）和负向退款款（退款商品价格总额）写在结算资金明细里，它们是两条独立的体行，不是一条净额。京东可以用一个净额公式一次性轧掉的部分，亚马逊必须正对正、负对负、独立判定——这叫「分向不轧差」。
[来源：2026-09-07 亚马逊收入对账脚本 v3.0.0 客户确认版] 这条规则看似反直觉，背后是亚马逊的真实业务：买家退货的金额必须单独追踪到供应链的退货入库红字单上，不能和销售腿合并。如果对账脚本按京东那一套整单轧差，亚马逊退货单永远对不上供应链——因为供应链侧从来没有"正负合并"的单据形态。
反直觉点：很多人以为"分向"是技术上的妥协、是性能优化——其实是数据语义层面的硬约束。把亚马逊每笔订单都按 (businessOrderNo, direction) 拆成两条 IncomePlanItem 体行（正向销售腿 + 负向退款腿），是为了让退货单的红字能精确匹配到供应链的退货入库单。
二、v2.0 的 7 个机读码：3 个方向化标签 + 4 个诊断标签
v2.0 时代（2026-09 早期版本）的亚马逊对账脚本在判定上比后续版本简洁——只有 7 个机读码差异标签，分两组：
- 方向化 3 标签（无有效供应链行时按方向判定）：
REFUND_ONLY（仅退款）、MISSING_SUPPLY（缺供应链）、MISSING_SUPPLY_ORDER（未找到供应链单号） - 诊断 4 标签（金额差异诊断时按交易明细 feeType 归因）：
WITHHELD_TAX（代扣税金）、GIFT_WRAP_CREDIT（礼品包装扣回）、FREIGHT_DIFF（运费）、AMOUNT_DIFF（金额差异兜底）
这 7 个标签是 v2.0 时代的"全集"——后续 v2.1 ~ v3.2 的演进都是在它基础上做"扩展档位 + SUCCESS 收口"，但底层骨架还是这 7 个。
[来源：2026-09-06 增补注记 · 亚马逊对账脚本 v2.8 演进说明] 这 7 个标签的设计哲学是机读 + 人读双轨——机器判定（机读码）驱动自动化出单，业务人员读（中文标签 + 处理建议）驱动人工兜底。同一个 diffReason 字段既要能被脚本消费，也要能被财务看懂——这是 v2.0 在产品层面对"标签码"的最大贡献。
2.1 方向化 3 标签：分向不轧差的产物
REFUND_ONLY 仅退款：负向体行（NEGATIVE）找不到供应链退货单时，脚本去查聚水潭订单明细（沙箱 query.supplyChannelOrders(1, ...) 渠道 1 = 聚水潭），订单类型 / 备注 / 商品行含「仅退款」关键字 → 判 REFUND_ONLY。处理建议：金蝶直接生成负数费用应收单（YSD02_SYS）。
真实案例：美站 7 月订单 111-6684676-8888236，负向腿 −67.69 美元；金蝶无对应红字退货单（货没退，钱退给买家了）；聚水潭订单类型 = 仅退款 → 命中 REFUND_ONLY，转换层自动出负数费用应收单。
[来源：2026-09-06 增补注记 · 美站 7 月实证] v3.x 的改进只是补了更多兜底（聚水潭关键字措辞变化退化为 MISSING_SUPPLY），主路径不变。
MISSING_SUPPLY 缺供应链：正向或负向体行完全查无订单号——金蝶供应链侧没有这条记录。处理建议（v2.0 时代）：系统不出单，挂差异汇总口径，建议运营手工补单。差异汇总里要提示三个核实场景：翻新订单（退货二次销售、编码乱码进不了金蝶）、先收款后发货（货款已收但发货未完成）、聚水潭是否有此单（供应链漏录）。
MISSING_SUPPLY_ORDER 未找到供应链单号：v2.0 早期给负向体行的细分标签，区别于正向的 MISSING_SUPPLY。后来合并——v2.0 中后期这两个标签在结果集里统一显示为 MISSING_SUPPLY，但脚本内部仍保留分向判定逻辑。
[来源：v2.0.0 2026-09-02 方向化标签用户定稿] 这条合并背后是 v2.0 演进史的"清理"动作——v2.0 早期 18 个业务码，到 v2.8 收敛成更紧凑的集合。
2.2 诊断 4 标签：金额差异的归因分析
当主匹配（口径 1 / 口径 2 / 口径 3）全不命中时，脚本进入差异诊断阶段——按交易明细行 rawData.feeType 字段做归因。判定顺序固定，前 3 个标签有交集时优先命中：
| 顺序 | 标签 | 判定公式（feeType 合计 vs |diff|） | 容差 |
|:-:|:---|:---|:-:|
| 1 | WITHHELD_TAX 代扣税金 | product sales tax + shipping credits tax + promotional rebates tax 合计 | 0.01 |
| 2 | GIFT_WRAP_CREDIT 礼品包装扣回 | gift wrap credits 合计 | 0.01 |
| 3 | FREIGHT_DIFF 运费 | shipping credits / postage credits / Gutschrift für Versandkosten 等运费列 | 0.01 |
| 4 | AMOUNT_DIFF 金额差异兜底 | 三标签诊断均未命中，或该订单无交易明细行 | — |
为什么顺序不可换：WITHHELD_TAX 公式含 shipping credits tax，与 FREIGHT_DIFF 的运费税金档有交集。如果先判运费，可能把"代扣税金"误判为"运费"——标签就错了，进而导致出单规则用错。
[来源：2026-08-29 判定优先级 + 处理建议与电商平台差异汇总逐条核对一致] v2.0 时代的 4 诊断标签组合只在 v2.4 起才把 WITHHELD_TAX 升级为 SUCCESS。
AMOUNT_DIFF 是兜底——前三标签都不命中时落这个，处理建议统一引导"人工核对订单明细（含上个月数据）与供应链单据"。这个标签本身不驱动任何自动出单，但它是漏斗的底：所有结构性问题最终都收敛到这里告诉财务"该停下来看一眼"。
三、v2.0 时代的判定阶梯：什么时候用什么标签
7 个标签不是平级关系——它们被组织成一条判定阶梯，体行依次尝试直到命中为止。理解这条阶梯的顺序，才能理解为什么 65.0% 是 v2.0 的合理起点。
3.1 第一档：分向过滤（决定能否找到供应链行）
任何体行进来先做分向过滤：
- POSITIVE 体行（销售腿）：
incomeAmount > 0的入参，只匹配供应链amount > 0的行 - NEGATIVE 体行（退款腿）：
incomeAmount < 0的入参，只匹配供应链amount < 0的行
过滤后没有有效行 → 直接进入方向化 3 标签的判定；过滤后有有效行 → 进入下一档。
3.2 第二档：主匹配（3 个口径 + 子集匹配）
有有效供应链行时，先尝试主匹配 3 口径（直接比 / 扣促销 / 扣促销 + 其他），任一口径 diff = 0 即 SUCCESS。3 口径都不命中，尝试子集匹配：找真子集使合计 = 调整后收入（行数 2~20、DP 防爆），命中即 SUCCESS + PARTIAL_SETTLEMENT（注：v2.0 时代子集匹配的标签名是 AMOUNT_DIFF_PARTIAL，v3.6 之后统一为 PARTIAL_SETTLEMENT；PARTIAL_SETTLEMENT 不在 v2.0 的 7 标签之列，是 v2.3 起的扩展）。
[来源：2026-09-02 v2.3 部分结算子集匹配用户确认版] v2.0 时代主匹配和子集匹配都失败，体行才进入第三档。
3.3 第三档：差异诊断（4 个标签）
主匹配和子集匹配都不命中、diff ≠ 0 时，按上文 2.2 节诊断表的顺序依次尝试 4 个诊断标签，命中即停；4 标签都不命中 → AMOUNT_DIFF。
德站 2026-06 实测数据（v2.0 时代）：2,473 个订单进对账，主匹配 + 子集匹配命中 1,607 个（65.0%），剩余 866 个进差异诊断；诊断阶段命中 WITHHELD_TAX 95 个（4.2%）、GIFT_WRAP_CREDIT 2 个、FREIGHT_DIFF 11 个；其余 758 个落 AMOUNT_DIFF。月结时 758 个 AMOUNT_DIFF 看起来吓人，但其实 11 条 FREIGHT_DIFF 在 v2.9 起（运费本金口径补齐）后就归到 SUCCESS 了——这就是 v2.0 → v3.2 把 65.0% 推到 99.6% 的关键杠杆。这也意味着 v2.0 → v3.2 的 23 天迭代节奏里，每一次演进都不是无意义的，轻易云智能对账系统 把每一档新口径、新标签、新 SUCCESS 收口都对应到一条具体的业务场景（如 FBA 退款、跨期退款、全额促销抵扣）——业务人员在看版本号时也可以反过来追"这次的升级对应哪一类差异的修复"。
[来源：2026-09-11 亚马逊收入对账脚本 v3.4.1 用户裁定版] 这条演进线写出来给读者看，是因为它解释了一件事：v2.0 时代的 AMOUNT_DIFF 不全是真异常，很多是脚本还没覆盖到的判定场景。
四、案例：美站 7 月 v2.0 跑出的标签分布长什么样
拿美站 7 月的真实数据（来自生产环境）来看 v2.0 时代的输出。美站 7 月 18,047 个体行（POSITIVE 销售腿 + NEGATIVE 退款腿合计）的判定结果，按 v2.0 时代的 7 标签分布如下：
| 标签 | 体行数 | 占比 | 处理路径 |
|---|---|---|---|
| 主匹配 SUCCESS（差异原因为空） | 11,628 | 64.4% | 自动下推财务应收单 |
WITHHELD_TAX 代扣税金 | 4,861 | 26.9% | 下推 + 正数费用应收单 |
GIFT_WRAP_CREDIT 礼品包装扣回 | 28 | 0.2% | 下推 + 正数费用应收单 |
FREIGHT_DIFF 运费 | 71 | 0.4% | 下推 + 正数费用应收单 |
AMOUNT_DIFF 金额差异兜底 | 612 | 3.4% | 不出单，挂差异汇总 |
REFUND_ONLY 仅退款 | 663 | 3.7% | 负数费用应收单（v2.0 后期）/ 主单 + 负数单（v3.x） |
MISSING_SUPPLY 缺供应链 | 184 | 1.0% | 不出单，运营手工补单 |
[来源：2026-09-06 增补注记 · 美站 7 月端到端实证] 这张表里几个关键点：
-
REFUND_ONLY 663 笔 = 美站月退款的 47%——这个数字不是 bug，是 FBA 模式的结构性产物（货退到亚马逊 FBA 仓、不经过卖家供应链）。v3.x 把它拆成 FBA_REFUND（SUCCESS + 跨期正向腿对平）+ CROSS_PERIOD_REFUND（SUCCESS + 供应链历史腿对平）+ 真正的 REFUND_ONLY（FAILURE + 仅退款识别）三个分支。
-
WITHHELD_TAX 4,861 笔 ≈ 月结算单 27%——亚马逊代扣税金系统性大类，6 月美站
ItemWithheldTax = −28,158.07 USD，资金侧收入不含税是结构问题。v2.0 起就判 SUCCESS（差异额 + 标签并列），转换层下推财务应收单的同时按差异额出正数费用应收单。 -
AMOUNT_DIFF 612 笔——v2.1~v3.2 的演进把大量 AMOUNT_DIFF 重新归类为 SUCCESS（运费本金口径、子集匹配、跨期退款兜底、全额促销抵扣）。到 v3.5.0 时代，美站 7 月重跑只剩 6 张失败（4 MISSING_SUPPLY + 2 AMOUNT_DIFF）。
[截图说明：v2.0 时代亚马逊欧洲站费用对账计划详情页 — 6 个核算项目聚合：基于交易绩效的费用 251.51、交易参与费用 531.00、广告费用 13,537.38、亚马逊物流库存仓储费 464.88、亚马逊物流移除费用 5.44、亚马逊物流长期仓储费 117.55，合计 14,907.76 元；状态全部「未分摊」等待 run-allocate。]
给业务人员看的实操要点：当你在对账周报里看到 REFUND_ONLY 占比超过 30%，不要怀疑脚本坏了——先确认业务模式是不是 FBA。FBA 模式下 REFUND_ONLY 高是正常的（货退到亚马逊仓），等 v3.x 跑起来 SUCCESS 率会自然上去。
五、v2.0 → v3.2 的演进：65.0% 到 99.6% 经历了什么
把 2026-09-02 ~ 2026-09-11 这 10 天的版本演进线画出来，v2.0 是基线、v3.2 是 v2.0 时代的成熟形态：
| 版本 | 日期 | 关键变更 | 实证（德站） |
|---|---|---|---|
| v2.0 | 09-02 | 基线：分向过滤 + 方向化 3 标签 + 诊断 4 标签 + ≤1 元判平 + 沙箱 query | 65.0% (1,607/2,473) |
| v2.1 | 09-02 | 促销返点抵扣成第 2 口径 | 86.7% |
| v2.2 | 09-02 | 其他抵扣成第 3 口径；任一 ≤1 判平 | 97.9% |
| v2.3 | 09-02 | 部分结算子集匹配（行数 2~20，±1） | 99.6%（含子集 41 单） |
| v2.4 | 09-02 | 税金对平判 SUCCESS：交易明细 8 列逐项比对再合计 | — |
| v2.5 | 09-04 | FBA 退款判 SUCCESS：NEGATIVE 无退货单 + 同订单正向腿对平 | 美站 579/716 笔 MISSING_SUPPLY 归入 |
| v2.6 | 09-05 | 清算不参与对账：QSJGZE/QSCXFD 剔除 | 美站 63 条清算假差异消除 |
| v2.7 | 09-05 | 完全相等对平：3 口径 / 子集 / FBA 正向腿均 diff = 0 才 SUCCESS | — |
| v2.8 | 09-06 | 赠品单识别（GIFT_ONLY_SUPPLY）+ 跨期退款兜底（CROSS_PERIOD_REFUND） | 美站 12 单赠品单 + 1 单跨期退款 |
| v2.9 | 09-07 | 运费本金口径：第 4 口径「收入 − 促销 + 运费」 | 德站 3 单对平（matched 3,039→3,042） |
| v3.0 | 09-07 | 全额促销抵扣对平：商品价−促销−其他＝0 → SUCCESS（无差异码） | 美站 14 单（12 单赠品行 + 2 单完全无单） |
| v3.1 | 09-08 | 聚水潭优惠金额-运费收入口径：第 5 口径 | — |
| v3.2 | 09-09 | 已下推财务应收排除：salFinBaseQty ≠ 0 不参与 | — |
[来源：2026-09-09 亚马逊收入对账脚本 v3.2.0 用户确认版] 这条演进线有 3 个反直觉点值得划重点：
第一，v2.0 ~ v3.2 加的不是新逻辑，是新档位。原 v2.0 的 3 个主匹配口径 → 演进到 v3.x 的 5 个口径；原 v2.0 的 4 个诊断标签 → 演进到 7 个标签；原 v2.0 的方向化 3 标签 → 演进到 5 个（多了 GIFT_ONLY_SUPPLY、CROSS_PERIOD_REFUND）。结构没有变，变的是覆盖度。
第二，"容差收紧"是演进的另一条主线。v2.0 时代是 |diff| ≤ 1 元即对平，v2.7 起改为严格 = 0 才 SUCCESS；标签容差始终保持 0.01。这条收紧让 v2.7 的对账结果更可信，但需要所有口径都做完全相等判定、不能再有"差不多就行"的余地。
第三，"扩 SUCCESS 收口"是产品层面的承诺。v2.4 起 WITHHELD_TAX 升级为 SUCCESS，v2.5 起 FBA_REFUND 升级为 SUCCESS，v2.8 起 CROSS_PERIOD_REFUND 升级为 SUCCESS——每个 SUCCESS 收口都对应一个真实业务场景的结构性化简，让财务月结时不再需要逐单解释。这套"逐档位扩 SUCCESS"的演进节奏也成了 2026-09 后续 23 天里轻易云智能对账系统 迭代亚马逊对账脚本的核心交付模式（v2.4 → v2.5 → v2.8 → v3.2 → v3.4 → v3.5）。
[来源：2026-09-11 v3.4.1 升档用户裁定版] 这条演进史给业务人员的最大启示是：别拿 v2.0 时代的成功率跟 v3.x 比，那是不同的"游戏"。月结周报里"7 月对账成功率 99.6%"对应的是 v3.x（默认版本），不是 v2.0。
六、7 个机读码的出单规则：差异标签如何驱动金蝶单据
7 个机读码最终落到金蝶单据上是怎么走的？v2.0 时代的出单规则非常明确：
| 对账结果 | 生成的金蝶单据 | 方式 |
|---|---|---|
| 主匹配 SUCCESS（差异原因 = null） | 财务应收单 YSD01_SYS（全月合并，体行 = SKU 明细） | 暂估应收下推 |
| WITHHELD_TAX / GIFT_WRAP_CREDIT / FREIGHT_DIFF（v2.4 起 SUCCESS） | 上 + 正数费用应收单 YSD02_SYS（按差异额） | 下推 + 新增 |
| REFUND_ONLY 仅退款 | 主单照出 + 负数费用应收单（按 |退款额|） | 下推 + 新增 |
| MISSING_SUPPLY / MISSING_SUPPLY_ORDER | 不出单，unmatched 人工处理 | — |
| AMOUNT_DIFF 兜底 | 不出单，挂差异汇总 | — |
[来源：2026-09-15 亚马逊对账集成转换 v2.0 出单规则] 这张表给业务人员看的时候要点放在闭环恒等式：财务应收 − 费用应收 = 账单净额。月结当天，财务只要核对「财务应收单合计 − 费用应收单合计 = 平台账单净额」，三个数对齐了，月结就完了。
到 v3.5.0 时代（2026-09-15 用户裁定版），这套出单规则仍然成立——但收入侧的差异标签少了（WITHHELD_TAX 命中数因解析拆税大幅下降），费用侧的差异标签多了（FBA_REIMBURSEMENT 等新机读码上线）。7 个机读码（v2.0）→ 29 个业务码 + OTHER（v3.9.5），这是 23 天演进的成果，但底层结构还是 v2.0 那套分向 + 标签码的双轨设计。
[截图说明：23 标签码判定流程图 —— 对账体行（差额 ≠ 0）→ 进入标签码判定 → 机读判定（auto，自动跑全部 23 标签码规则，命中即停）→ 标签码 + 处理建议 → 标 SUCCESS/FAILURE + diffReason → 等待整体确认；同时展示 23 个机读码标签码（CANCELLED_UNSHIPPED / GIFT_ONLY_SUPPLY / CROSS_PERIOD_REFUND / AFTER_SALE_SERVICE_DIFF / DIRECT_COMPENSATION / MARKETING_COUPON_DIFF / PRICE_DIFF_ORDER / REFUND_ONLY 等）。]
给 ERP 实施看的实操要点：7 个机读码的出单规则在集成转换层（v2.0 时代）已经定型，集成转换脚本按 diffReason × sourceType × docType × targetSystem 四元键匹配出单规则——这条规则链是 ERP 实施最容易踩坑的地方：很多实施顾问只看 diffReason 字段就出单，忽略了 docType（AR_receivable / AP_Payable / SKDL01_SYS 等）的差异。集成转换层（第四类沙箱）有完整的四元键匹配表，164 条金蝶云星空转换规则按此原则组织，每条规则出单前都要同时校验 4 个字段。
[截图说明：23 业务标签码价值图 —— 审计友好（机读码驱动自动化出单、合规留痕）+ 业务友好（中文标签 + 处理建议，财务人员看得懂），机读 + 人读双轨设计。]
七、v2.0 在版本史里的位置——它为什么值得专门写一篇
把视角拉远一点。2026-09-15 现行默认版本 v3.5.0 = v3.4.1（v2.0 的成熟形态）+ 解析 v1.3.0 拆税金适配。v2.0 已经在 2026-09-06 从种子与 DB 删除（保留非默认可回滚），现行默认走 v3.5.0。但 v2.0 的价值不在于它还在用，在于它是整个亚马逊对账脚本的最小可用集——7 个机读码涵盖了分向过滤的所有基本场景，任何后来版本的演进都是在它基础上做加法。
[来源：2026-09-06 增补注记 · 亚马逊对账脚本 v2.8 演进说明] 这就是为什么业务人员理解 v2.0 是有意义的：你不需要懂 v3.5.0 的所有扩展档位，但必须懂 v2.0 的 7 标签码。当月结周报里出现一个陌生的标签码（v3.5.0 时代的 FBA_REIMBURSEMENT 之类），你可以从 v2.0 的 7 标签码出发反推它的归类——方向化 3 标签、诊断 4 标签——再去看 v3.x 的扩展档位加在哪一层。
实操 takeaway：
- 分向是基础：所有标签码都要先按 (businessOrderNo, direction) 拆体行，不要试图合并正负
- 7 标签是全集：v2.0 的 7 机读码（3 方向化 + 4 诊断）是后续 29 标签码的最小骨架
- 判定顺序固定：方向化 3 标签 → 主匹配 3 口径 → 子集匹配 → 差异诊断 4 标签，不能换顺序
- 容差纪律：主匹配从 v2.7 起严格 = 0，标签容差始终 0.01
- SUCCESS 收口：每个标签码的判 SUCCESS 路径都对应一个真实业务场景的结构化简
跨境电商的亚马逊对账是国内 5 大平台里最复杂的一个——但它的复杂是有结构的，不是无序。v2.0 是这个结构的入口，理解了它，再去看 v3.x 的扩展档位就不会迷失。如果要在生产环境落地这套分向 + 7 机读码的双轨判定链，参考做法是把"分向过滤 + 7 标签码判定 + 出单规则"封装进沙箱脚本——v2.0.0 默认版本里就把这套骨架定型下来，避免业务人员逐条规则自己写脚本；它是 v3.x 全部扩展档位共同的地基，也是德站 2026-07 跑出 4,318 / 4,318 全对平的源头。