同一笔订单，后台显示买家付了 5129 卢布，API 返回的价格是 6983 卢布，最后打到账上的却是 5330.99 卢布。
三个数字，三种口径，到底该信哪个？
这篇就把这事一次讲透。
一、开门见山：WB 的数据有一层"滤镜"
Wildberries（下称 WB）是俄罗斯最大的电商平台之一。我对接它的 API 做日报自动化的时候，撞上一个在 OZON 从没遇到过的问题——后台显示的数字，和 API 返回的数字，差了一千多卢布。
不是精度问题，不是尾数差，是真真切切差了一大截。
搞懂这事，得先过两个坎：单号搞不清对不上账、价格和佣金的结算机制反直觉。下面一个一个来。
二、第一个坑：WB 有三种"订单号"，搞混就对不上账
这个坑隐蔽但特别致命——你拿代码拉出来的订单号，往 WB 后台一搜，搜不到。
为什么？因为 WB 系统里其实有三个不同用途的"单号"，各管各的。
1. gNumber — 买家购物车的订单号
- 什么意思：买家一次购物车结算出来的号（Номер заказа покупателя）
- 特点：一个买家一次买 3 件你的衣服，API 里会是 3 条数据，但 gNumber 是同一个
- 用途：主要是客服跟买家对话时用
- 坑：在 WB 后台（FBS 发货台、财务明细）里基本搜不到
2. 备货任务号（Номер сборочного задания）— 网页发货用的号
- 什么意思：每一件实体商品对应的打包单号，长得像
1234567-8901 - 特点：你在 FBS（Маркетплейс）列表里天天看到的就是它
- 坑：
/orders统计接口里压根没这个字段——那个接口是财务口径，不管仓储
3. Srid — 系统底层唯一 ID（最关键）
- 什么意思：WB 系统底层的绝对唯一 ID
- 在哪看：只在**财务明细表（Детализация）**里才有专门一列
- 用途：要把 Python 拉的日报和周末下载的财务明细表做 VLOOKUP 对账，只有 Srid 能对上，别的号都不行
一张表总结：
| 单号 | 哪里能看到 | 干嘛用 |
|---|---|---|
| gNumber | /orders 接口、客服场景 |
跟买家对账 |
| 备货任务号 | FBS 网页列表 | 打包发货 |
| Srid | 财务明细表 | 对账、追到钱 |
我自己踩的坑：第一版日报脚本用了 API 返回的 gNumber 当"订单号"存 Excel。第二周想对账，把这些号一个一个扔进 WB 后台——全部搜不到。那一刻人都麻了。后来才反应过来，WB 的单号不是"一号走天下"，而是"一件货在不同环节有不同身份证"。
修正方案：日报里三个号都留着，对账用 Srid，发货用备货任务号，对买家用 gNumber。不浪费一个字段。
三、第二个坑：你以为的"销售额"到底是哪个价？
这块最有意思——WB 的价格口径有三层，网页给你看的、API 返回的、最后打到账上的，是三个完全不同的数。
拿一台 NOTE 13 PRO 手机的真实订单做例子。
三个价：谁是谁
① 你自己定的价（Цена розничная с учетом скидки）：6983.03 ₽
- 你在后台设置的价（扣掉你自己给的折扣之后）
- WB 认为这笔生意是按这个价成交的
- API 里的
priceWithDisc字段就是它
② 买家实际付的钱（Вайлдберриз реализовал Товар）：5129.00 ₽
- 买家真掏出来的钱
- 网页端"买家支付额"显示的就是这个
- API 里的
finishedPrice对应它 - 比 ① 少了 1854.03 ₽
③ 差额去哪了？SPP 平台补贴：1854.03 ₽
- 买家之所以少付，是因为 WB 自己给他贴了这 1854 卢布
- 重点来了：这 1854 卢布 WB 会补给你
换句话说：买家觉得自己薅到羊毛，但你没亏。WB 自掏腰包承担了差价。
佣金怎么扣：不是直接扣钱，而是"改佣金率"
这是 WB 结算最骚的地方——它不直接从你账上扣 1854，而是降低对你收的佣金比例来实现这个补贴：
| 项目 | 数值 | 说明 |
|---|---|---|
原始佣金率（Размер кВВ, %） |
26.55% | 合同上说好的类目佣金 |
实际执行佣金率（Итоговый кВВ, %） |
20.72% | 因为 WB 补贴，帮你往下调了 |
| 佣金金额 | 6983.03 × 20.72% = 1446.88 ₽ |
按 ① 号价算，不是按 ② |
银行收款手续费（Комиссия за эквайринг） |
205.16 ₽ | 买家刷卡，银行拿的钱 |
最后到手多少（Вознаграждение за реализованный товар）：
你的定价 (6983.03) − 佣金 (1446.88) − 银行手续费 (205.16) = 5330.99 ₽
为啥你到手的钱（5330.99）比买家付的钱（5129）还多？
这是整套机制最反直觉的地方。答案：
- WB 承认这单是按 6983 成交的（按 ① 号价算佣金）
- 买家只掏了 5129（② 比 ① 少了 1854）
- WB 通过砍佣金率，把那 1854 里的大部分又塞回到你账上
所以你账上进的钱 5330.99 > 买家付的 5129。
平台宁愿少收你佣金、甚至贴钱，也要让买家觉得"在 WB 买东西就是便宜"。对平台来说这不是亏损，是获客成本。
四、亚马逊、ozon的平台补贴是怎么样的？
几乎每个主流平台都有类似机制，但实现方式天差地别。
三个平台放一张表里对比：
| 维度 | Wildberries（SPP） | OZON（折扣积分） | Amazon（Discount Provided by Amazon） |
|---|---|---|---|
| 谁决定打折 | 平台自动 | 平台自动 | 平台自动 |
| 差额谁出 | 平台（通过降低佣金率） | 平台（通过发"积分"抵佣金） | 平台全额出 |
| 卖家要不要主动参加 | 默认就参加，很难退 | 默认参加，可申请退出 | 自动参加，可 opt-out（但不可逆） |
| 卖家最终按啥结算 | 按你的"定价"结算 | 按你的"定价"算，差额用积分抵佣金 | 按你的"原始挂牌价"全额拿到钱 |
| 佣金基数 | 你的定价（高） | 你的定价（高） | 全价（高） |
| 报表里能不能看到补贴 | 能，但要自己拿两个佣金率反推 | 能，有专门"折扣积分"字段 | 能，财务报表里有 “Amazon funded” |
| 对卖家数据的误导程度 | 最高 | 中等 | 较低 |
OZON：也有，叫"折扣积分"（Баллы за скидки）
OZON 的逻辑和 WB 的 SPP 非常像，但摊得比 WB 明白：
- 平台给买家打折 100 卢布 → OZON 按 1:1 给卖家发 100 个"积分"
- 这些积分专门用来抵扣 OZON 要收的佣金
- 积分最多能覆盖佣金的 99%
- 不能跨结算周期用，用不完就归零
跟 WB 的本质区别：WB 直接改写佣金率，让你看到的佣金数字就是最终数字；OZON 是先按正常佣金扣你的钱，再用积分补回来。
所以 OZON 的财务报表里有一列清清楚楚的"折扣积分"，卖家一眼就能反应过来"这笔钱是平台帮我出的"。WB 就没这列，你得自己算。
Amazon：也有，而且最痛快
先说清楚，Amazon 有两套完全不同的机制，别搞混了：
① 卖家自己发的 coupon / promotion
- 卖家自己掏钱。卖家设折扣价，买家少付的钱全部从卖家结算额里扣
- Amazon 还额外收 coupon 手续费（2025 年 6 月改革后是 $5 固定费 + 2.5% 销售额抽成，之前是每次兑换收 $0.60）
- 就是一般说的"Amazon 促销"，跟 WB SPP 没关系
② Discount Provided by Amazon（平台出钱打折）
- 这个才是类比 WB SPP 的东西
- 卖家照样按原挂牌价拿到全额货款，Amazon 自己承担折扣那部分
- 佣金按全价算，不会因为打了折就少收
- 所有卖家默认自动加入，可以账户级别 opt-out，但一旦退出就不能再回来
- Amazon 自己选哪些商品降价、降多少，卖家事先可能都不知道
Amazon 这套和 WB SPP 的不同在于：
- 更痛快——直接按全价给你结算，没有"先扣再补"的复杂流程
- 但可能踩到卖家跟上游品牌方的 MAP（最低广告价）协议，因为 Amazon 擅自降价可能破坏你和品牌商之间的价格政策
总结
OZON 是"账面上清清楚楚告诉你’这部分我帮你出了’"。 Amazon 是"直接给你全款，我自己消化差价"。 WB 是"把补贴藏进佣金率里，自己算去"。
WB 的 SPP 最阴。不是阴在"存在补贴"——补贴本身对卖家是好事——而是阴在它没有任何一个字段直接告诉你补贴了多少。
你看到的全是计算结果，没有计算过程。原始佣金率 26.55% 和实际佣金率 20.72% 摆在那，你得自己反应过来"哦，这俩差了 5.83%，乘以定价 6983，就是……不对，还得加上银行手续费的变化，还得考虑……"——大多数卖家根本算不清这笔账，看到"买家只付了 5129"就以为自己亏了。
五、网页端 vs API：同样的订单，差异在哪
网页端能看到什么
- 买家支付额（5129）
- 订单状态、发货信息
- 佣金总额（汇总的，不拆）
- 简化版财务摘要
API 能多看到什么
- ① 你的定价 6983（真实成交额，佣金基数）
- ③ SPP 补贴相关字段
- 原始佣金率 vs 实际佣金率的差
- 每一笔银行手续费
- Srid——对账必备
差异对照表
| 维度 | 网页后台 | API |
|---|---|---|
| “销售额"显示 | 买家支付价（5129），看着偏低 | 定价（6983），真实成交额 |
| 佣金 | 只给总额 | 原始率 + 实际率 + 差额都有 |
| SPP 补贴 | 某个栏目汇总 | 明细字段可见 |
| 单号 | 备货任务号（能搜） | gNumber（搜不到） |
| 对账能力 | 弱，字段不够 | 强，有 Srid |
| 数据延迟 | 有平台加工延迟 | 接近实时 |
核心差异一句话：
网页端给你的是"买家视角”（他付了多少），API 给你的是"结算视角"（这单值多少钱）。 只看网页端，容易把每一单都当成"少赚了"，吓自己。
六、怎么跟老板汇报：三个数字讲清楚
到这一步，汇报就很简单了：
“老板，这单 NOTE 13 PRO 我们挂牌卖 6983，买家因为平台 SPP 补贴只掏了 5129，WB 扣了 20% 左右的佣金和手续费，最后打给我们 5330.99 卢布。我们不仅没亏，平台还替我们承担了一部分折扣成本。”
三个数字、两个动作（平台补、平台扣）、一个结论（没亏，反而被补了）。这就是合格财务该有的汇报颗粒度——不是把数字念一遍，而是把"钱的流向"讲清楚。
七、技术细节：API 鉴权和"单 token"设计
比起 OZON 把"销售 API"和"广告 API"拆成两套完全独立的鉴权体系，WB 这边简洁很多：
- 只有一个 token——一把钥匙开所有门（订单、统计、财务、商品、广告、仓储）
- 鉴权方式：HTTP header 里塞
Authorization: Bearer <token> - 域名：不同业务走不同子域名，但共用同一个 token
好处是开发者友好，坏处是权限粒度粗——这个 token 一旦泄露，整个店铺裸奔。所以 token 管理要格外小心。
关键代码示意：
headers = {"Authorization": WB_TOKEN}
# 订单统计接口：按下单时间拉数据
resp = requests.get(
"https://statistics-api.wildberries.ru/api/v1/supplier/orders",
headers=headers,
params={"dateFrom": "2024-01-01T00:00:00"},
timeout=30
)
注释：
dateFrom用 ISO 8601 格式，不带时区的话 WB 默认按莫斯科时间（UTC+3）处理- 统计接口有每分钟一次的调用限制，频繁轮询会被 429 怼回来
- 财务明细接口按周结算，不是按天——和订单接口口径不一样
- 要拿 Srid，必须走财务明细接口，订单统计接口里没这字段
八、最后
对接完 WB 之后，我最深的感受是：
做跨境电商，最容易踩雷的不是"算错数"，而是"用错口径"。
WB 这个例子里，如果你拿"买家支付额"去算毛利、算 ROAS、算广告投产比——每个指标都会系统性偏低。偏低 20%~30% 的数据，足以让一个本该加投的品被误杀，也足以让一个本该下架的品被继续烧钱。
API 的价值不只是自动化。更重要的是——它逼着你把"那个模糊的销售额"一层一层拆开，看清楚每一层到底是什么。
- 后台给你一个数字，那是结论
- API 给你一组数字，那是过程
财务的专业度，就藏在"过程"里。看到的层数越多，判断就越准。这也是我坚持把每个平台的 API 都吃透一遍的原因——不是为了写脚本，是为了不被平台的默认视角带偏。