Seller Central 显示某个 SKU 在 FBA 还有库存，商品页却无法购买。第一反应往往是“仓库还没上架”“广告没流量”，于是有人继续加预算、改价格，甚至直接删除 Listing 重建。问题是：库存数量、Listing 和 Offer 是三层不同状态；其中任何一层没对齐，仓库里有货也不等于消费者可以买到。
先给结论：
Amazon 中文后台所说的“无在售信息的亚马逊库存”，英文资料称 stranded inventory：FBA 履约中心里有库存，但没有关联有效 Offer。先锁定站点、Seller SKU、ASIN、FNSKU 和 stranded reason，再修直接原因；删除 Listing、创建新 SKU 或移除库存都不是默认第一步。
先确认是不是“无在售信息的亚马逊库存”
Amazon FBA Inventory 工具说明把 stranded inventory 定义为 FBA 履约中心里的商品没有 active offer；中文 Seller Central 常称为“无在售信息的亚马逊库存”。这个定义很窄：它描述的是“库存与有效 Offer 断开”，不是所有不可售、没购物车或没销量问题的总称。为方便行文，本文后续简称“滞留库存”。
| 后台状态 | 是否等同滞留库存 | 先查什么 |
|---|---|---|
| FBA 有 available 数量，但没有 active offer | 符合核心定义 | Fix Stranded Inventory 的原因和建议动作 |
| Listing 为 Inactive / Search Suppressed | 可能是上游原因 | 属性、图片、价格、资格、合规通知 |
| 没有 Featured Offer | 不一定 | 自己的 Offer 是否仍可在其他卖家入口购买 |
| Reserved / FC transfer | 不一定 | 是暂时不可用，还是 Listing 本身失效 |
| Unfulfillable | 不等同 | 库存是否可恢复、翻新、移除或回收 |
| Out of stock | 不一定 | 可售数量是否真的大于 0 |
如果 Fix Stranded Inventory 页面没有这一 SKU，就不要先入为主地按“滞留库存”处理。先确认你查看的是正确站点、正确 Seller SKU，以及 available、reserved 和 unfulfillable 中的哪一种数量。
若数量主要落在 Reserved，可继续按《Amazon FBA 库存一直预留怎么办？》区分客户订单、运营中心转运和运营中心处理，避免把临时占用误当成无在售信息库存。
一次收齐这 12 个字段
不要只截一张“不可售”红字。一次性把对象、数量、原因和截止时间收齐，后面每一次修改才有可比较的基线。
| 字段 | 为什么需要 |
|---|---|
| Marketplace / 站点 | 同一 ASIN 在不同站点可以有不同 Offer 状态 |
| Seller SKU | 库存与 Offer 连接的卖家对象 |
| ASIN | 确认商品详情页和目录对象 |
| FNSKU | 确认仓内标签库存属于哪个卖家 SKU |
| Fulfillment channel | 防止误把 FBA 改成 FBM |
| Available 数量 | 确认真正可履约的数量 |
| Reserved 数量 | 排除订单、转仓或处理中库存 |
| Unfulfillable 数量 | 区分不可履约库存 |
| Listing / Offer status | 确认是否存在有效 Offer |
| Stranded reason | 决定修复路径 |
| 自动操作日期 | 防止修复过程中触发移除或弃置 |
| 最近变更与 Case ID | 建立故障时间线和支持证据 |
Amazon 近期的 inactive FBA inventory 说明列出的常见原因包括关闭或受抑制的 Listing、价格错误、过期商品、缺失商品信息、类目要求、品牌/GTIN 资格以及合规材料。真正的入口仍是账户里的 Fix Stranded Inventory 和通知，而不是从网上找一个万能按钮。
按原因分流，不要用一套动作修所有问题
| 原因组 | 典型证据 | 优先动作 |
|---|---|---|
| Listing 被关闭、删除或切换 FBM | Offer 不存在，履约渠道变化 | 恢复原 Offer 与 FBA 关系 |
| 属性或目录错误 | Listing error、字段冲突、Search Suppressed | 修错误码对应字段并保存处理报告 |
| 价格错误 | Inactive (Pricing Error)、Pricing Health 提示 | 核对售价、最低/最高价、促销和商业价格 |
| 品牌、GTIN、类目资格 | 需要批准或商品匹配错误 | 按错误页提交申请，不创建重复 ASIN |
| 合规、知识产权、账户健康 | 绩效通知或销售资格受限 | 按原通知补材料或申诉 |
| 过期或不可履约 | 有效期或库存状态异常 | 判断能否恢复，否则转移除/价值回收 |
| 系统同步异常 | 页面互相矛盾、修改后原因不变 | 保留 Feed 回执并开 Seller Support Case |
Amazon Listing error 指南强调，错误通常与缺失或冲突信息、权限和商品匹配有关，并建议从 Search Suppressed and Inactive Listings / Fix Your Products 查看具体错误。不要把“Listing error”四个字直接翻译成“删掉重建”。
最安全的修复顺序
1. 先保存现场
导出或截图滞留库存页面、Manage All Inventory、库存数量、错误详情和通知，记录 Seller SKU、ASIN、FNSKU、发现时间及账户显示的自动操作日期。如果后面状态变化，这些证据能说明修改前到底是什么问题。
2. 只修页面指出的直接原因
关闭的 Listing 就重新激活；缺属性就补属性；价格错误就检查价格字段；需要类目、品牌或合规批准，就走对应申请或申诉。一次同时改标题、类目、价格、SKU 和履约渠道，成功后也无法知道哪一项起作用，失败时更难回滚。
3. 保存处理回执，再等状态同步
使用表格或 Feed 更新时保存批次 ID 和 processing report；页面操作也记录时间。刷新页面不是证据，必须看到 Listing active、Offer 实际可购买，并且滞留数量归零，才算恢复完成。
4. 需要重建 Offer 时，守住原对象标识
Amazon 官方的 stranded inventory 说明指出，关闭或删除 Listing、把 FBA 改成 FBM 都可能制造滞留库存。若错误页或 Seller Support 明确要求重建，先确认应继续使用哪个 Seller SKU、ASIN 和履约渠道；不要随手创建新 SKU 或重复 ASIN，再期待旧 FNSKU 库存自动连接过去。
5. 页面矛盾时，用完整时间线开 Case
Case 至少包含站点、Seller SKU、ASIN、FNSKU、当前数量、stranded reason、最后一次成功状态、所有修改时间、Feed 回执和截图。问题陈述应是“这个对象在这些页面出现矛盾”，而不是只有一句“库存不可售，请修复”。
6. 同时管理不可逆截止时间
旧官方资料出现过通知后 30 天自动移除的说明，近期官方帖子又展示了按周或双周执行自动移除的设置。这意味着固定天数不能跨站点、账户和时间照抄。真正需要记录的是你账户当前显示的自动操作日期和设置；无法在截止前恢复时，才进入移除、清算、捐赠或弃置比较。
为什么这时候加广告没有用
广告能竞争流量，不能替代有效 Offer。Listing 没有恢复可售时，提高 bid 或预算无法把仓内库存重新连接到商品页；即便某些后台仍显示历史 Campaign，最终也不应把广告花费当作修复手段。
正确顺序是：
库存对象正确
→ Listing active
→ Offer 可购买
→ 价格与合规状态正常
→ 再判断是否需要广告恢复流量
恢复后还要把不可售期间从广告和销量分析窗口中标记出来。否则你可能把“Offer 不存在导致 0 单”误判为关键词转化差，再错误降价或降 bid。
一组教学排查案例
假设美国站某 SKU 显示 FBA available 120 件，前台不可购买，Fix Stranded Inventory 的原因是 Listing error。两天前团队刚批量更新类目属性。
安全流程不是立即删除 Listing，而是：
- 记录站点、Seller SKU、ASIN、FNSKU、120 件数量、原因和自动操作日期；
- 检查 Search Suppressed / Inactive Listing 与批量文件 processing report；
- 找到缺失或冲突属性，只提交该字段修复；
- 保存 Feed 批次 ID，等待状态同步；
- 验证 Listing active、Offer 可购买、滞留数量归零；
- 若原因仍不刷新，用修改前后证据和批次 ID 开 Case；
- 只有在账户截止日期前无法恢复时，才比较移除或其他处置。
这只是教学案例，不代表所有 Listing error 都来自属性更新，也不承诺任何固定处理时长。
可以自动监控，但不要自动删 Listing
适合每天只读保存的字段包括：
| 监控字段 | 告警条件 |
|---|---|
| stranded unit 数量 | 新增或扩大 |
| 首次发现时间 | 超过内部处理 SLA |
| stranded reason | 原因变化或为空 |
| 自动操作日期 | 进入预设人工处理窗口 |
| Listing / Offer status | 修复后仍未 active / purchasable |
| Case ID 与最近动作 | 长时间没有新回执 |
自动化最多生成告警和待办，不应自动删除 Listing、创建新 SKU、降低价格、提交合规申诉或修改移除设置。对这些不可逆动作，人工确认比“尽快清零告警”更重要。
修不好时，才进入库存处置
如果政策、知识产权、商品状态或目录问题使 Offer 无法恢复，就不要无限期付仓储费等待。此时再用《Amazon FBA 库龄越来越长怎么办》的统一净回收方法，比较移除海外仓、清算、捐赠和弃置；在下一次补货前，也要用《Amazon FBA 该补多少货》把不可售和冻结库存从正常库存位置中分开。
最终检查表
| 检查 | 通过标准 |
|---|---|
| 对象 | 站点、Seller SKU、ASIN、FNSKU 对齐 |
| 数量 | available、reserved、unfulfillable 分开 |
| 原因 | 已读取 stranded reason 和关联通知 |
| 截止 | 已记录账户实际自动操作日期 |
| 修复 | 只修改直接原因并保存回执 |
| 验收 | Listing active、Offer 可购买、滞留数量归零 |
| 升级 | 页面矛盾时 Case 包含完整时间线与处理报告 |
| 处置 | 无法恢复时才比较移除、清算或弃置 |
| 自动化 | 只读监控和告警，不执行不可逆动作 |
FBA 有库存却不可售，最危险的不是多点几次刷新，而是把对象关系改乱：换了 SKU、建了重复 ASIN、删掉原 Listing，却没有留下任何处理回执。把库存、Listing 和 Offer 三层分开，按原因码逐步恢复，才是成本最低、也最容易审计的处理方式。
FBA 专题导航：Amazon FBA 库存、费用、资金与对账指南，可按“资金周转 → 补货与费用 → 入仓 → 库存状态 → 赔偿对账”继续阅读。
优先级提示：无在售信息库存占仓却不能销售，通常应在 IPI 运营排障中优先修复。它与积压、周转和补货的关系见Amazon IPI 分数诊断指南。
修复失败后再比较清算：无在售信息库存若无法在截止前恢复 Offer，应把批量清算与移除、弃置放在同一净值模型中。资格、费用和不可撤销检查见FBA Liquidations 决策指南。
