货件已经显示已接收，库存总量也对得上，但可售数量仍是 0，几十件商品全部落在 Reserved；另一批货显示 FC Transfer 快三周，商品还能下单却没有 Prime 配送；还有几件从可售突然变成 FC Processing，卖家支持只让继续等待。
这三种情况在 Seller Central 里都叫“预留库存”，处理方法却完全不同。把 Reserved 当成一个状态，会造成三类误判：把客户订单占用当成库存丢失，把正常运营中心转运当成不可售，把真正异常的 FC Processing 一直留在等待队列。
先给结论：
Amazon FBA 的 Reserved 是 Customer Order、FC Transfer 和 FC Processing 三个子状态的合计。先拆数量，再看时间：客户订单已经消耗供给；FC Transfer 通常仍可购买但配送可能延后；FC Processing 是运营中心内部暂时处理，不能直接当可售。只有状态年龄、数量趋势和相关事件无法解释时，才进入人工 Case。
先把三类预留库存拆开
Amazon 论坛团队 2025 年发布的预留库存说明将 Reserved 分成三类：
| 子状态 | 正在发生什么 | 对销售的含义 | 第一动作 |
|---|---|---|---|
| Customer Order | 单位已分配给现有客户订单，等待拣货、发货或订单变化 | 已经被需求占用，不能再算未承诺供给 | 对齐订单与发货状态 |
| FC Transfer | 单位在 Amazon 运营中心之间转运 | 通常仍可购买，但可能显示未来送达日期 | 监控转运时长和数量趋势 |
| FC Processing | 单位在运营中心内等待额外处理 | 暂时不能当立即可售量 | 查尺寸重量、调查、移除和限制 |
转运处理期间，一些单位可能短时间同时出现在 FC Transfer 与 FC Processing 相关流程中。不要把界面某一刻的分类变化解释为库存重复增加，也不要只保存 Reserved 总数。
Customer Order 不等于后台一定能看到已付款订单
Customer Order 表示这些单位正在用于履行客户订单。订单可能仍处于付款验证、待处理、合并配送或取消释放前阶段，因此库存端出现占用与订单页面可见时间不一定完全同步。
| 看到的现象 | 合理解释 | 不应立即做什么 |
|---|---|---|
| Customer Order 增加，可售减少 | 新订单占用库存 | 不把它当丢件或入仓少收 |
| 数量随后释放回可售 | 订单取消或占用解除 | 不重复增加库存台账 |
| 数量转为出库事件 | 订单进入实际履行 | 不继续把它算未来供给 |
| 长期占用且无订单线索 | 可能存在待处理或系统异常 | 不只凭一个截图要求赔偿 |
补货计算时，Customer Order 应视为已被需求消耗，而不是“还在仓库，所以仍能卖”的安全库存。财务上则要等订单实际发货、退款或取消后再进入相应收入事件。
FC Transfer 通常还能卖，但配送承诺可能变慢
FC Transfer 是 Amazon 为靠近客户而在运营中心之间调拨库存。Amazon 当前公开说明指出，这类单位可以供客户购买；如果没有其他运营中心的即时库存，前台可能显示未来发货日期，且在到达目的运营中心前可能不具备 Prime 配送资格。
Amazon 论坛团队近期给出的常见时间是转运可能需要 22～25 天，天气等情况还可能更久。这个数字是观察基线，不是第 26 天自动赔偿的 SLA。
| FC Transfer 年龄 | 推荐判断 | 推荐动作 |
|---|---|---|
| 刚进入～数天 | 正常网络调拨 | 记录首次日期，观察数量是否下降 |
| 接近常见 22～25 天 | 仍可能正常，但交付风险升高 | 检查前台送达承诺、目的站点与数量变化 |
| 超过常见时间且持续不变 | 需要证据化复核 | 保存报告快照，核对货件和库存事件后联系支持 |
| 状态已释放 | 转为可售、订单或其他去向 | 验证库存总量与去向，不把释放重复记为入仓 |
广告层面也要区分“可购买”和“配送体验正常”。如果可售为 0、绝大多数只在 FC Transfer，前台承诺明显变长，转化率可能受到影响；此时不应仅因还能投放就自动提高 bid 或预算。
FC Processing 是内部处理，不是统一的丢货标签
FC Processing 表示单位已经在运营中心，但被暂时侧置进行额外处理。Amazon 列出的原因包括尺寸和重量验证、待处理调查、待处理移除订单，以及转运过程中的临时处理。
Amazon 论坛团队 2026 年 6 月的操作说明进一步列出拣货包装、临时质量或状态评估等场景，并称多数情况会在数小时到数天内自行清除；若持续超过 30 天、数量突然异常增加，或无法由移除和近期活动解释，可考虑联系卖家支持。
| 排查对象 | 要找的证据 | 可能解释的 FC Processing |
|---|---|---|
| 尺寸与重量 | 最近是否重新测量、费用是否异常变化 | 尺寸重量验证 |
| 账户与商品限制 | 绩效通知、合规缺失、真实性或危险品审核 | Listing/商品调查 |
| 移除订单 | Removal Order ID、创建日期、处理中数量 | 待处理移除 |
| 入仓与转运 | Shipment ID、接收时间、FC Transfer 数量变化 | 收货或转运处理 |
| 商品状态 | 退货、质量评估、不可售变化 | 状态或质量判定 |
30 天应作为近期 Amazon 论坛给出的人工升级参考，不应写进自动赔偿逻辑，也不能跨站点视为合同期限。账户页面出现更具体的调查或资格日期时，以当前页面为准。
Reserved、Inbound、Stranded 和 Unfulfillable 不是同一层
预留库存描述 Amazon 网络内部暂时如何占用或处理库存；入仓描述货件还在创建、运输或接收；Stranded 描述 FBA 库存没有有效 Offer；Unfulfillable 描述商品状态不可售。它们可能同时影响一个 SKU，却不能互相替代。
| 状态 | 核心问题 | 主要连接键 | 对应处理 |
|---|---|---|---|
| Inbound | 货是否还在入仓链 | Shipment ID + FNSKU | 查 Working、Shipped、Receiving |
| Reserved | 仓内单位为何被占用或处理 | SKU + ASIN + FNSKU | 拆 Customer Order、FC Transfer、FC Processing |
| Stranded | 有库存但 Offer 为什么无效 | SKU + ASIN + 原因码 | 修复 Listing、价格、合规或 SKU 映射 |
| Unfulfillable | 商品为什么不可售 | FNSKU + disposition | 查退货原因、损坏、移除或赔偿 |
如果库存数量存在入仓短少，先按《Amazon FBA 入仓数量不对怎么办？》建立货件证据链；如果库存存在但 Listing 无法销售，则转到《Amazon FBA 有库存却不可售怎么办？》。
用报告快照证明“卡了多久”
Amazon SP-API 的 FBA 报告文档把 Reserved Inventory report 定义为 GET_RESERVED_INVENTORY_DATA，提供近实时的预留数量数据；Manage Inventory 与 Restock 报告还提供可售、不可售、预留、入仓以及三类 Reserved 相关字段。
这些报告回答“现在有多少”，却不会自动替你保存完整的状态历史。要判断某个 FNSKU 是否真的卡住，至少每天保存一次快照：
| 字段 | 示例 | 用途 |
|---|---|---|
| snapshot_date / marketplace | 2026-07-16 / DE | 固定日期与站点口径 |
| seller_sku / ASIN / FNSKU | 三层身份 | 防止同 ASIN 多 SKU 混并 |
| available_qty | 20 | 当前立即可售基线 |
| reserved_customer_order | 6 | 已被订单占用 |
| reserved_fc_transfer | 40 | 网络调拨中的数量 |
| reserved_fc_processing | 8 | 内部处理中的数量 |
| inbound_working/shipped/receiving | 0 / 50 / 10 | 排除仍在入仓链的数量 |
| unfulfillable / stranded | 2 / 0 | 排除不可售和 Offer 问题 |
| first_seen_at / last_changed_at | 7-01 / 7-14 | 区分总年龄与最近是否仍变化 |
异常判断不只看 today - first_seen_at。如果 FC Transfer 已持续 28 天，但数量每天下降，可能只是分批完成；如果 FC Processing 只有 5 天却从 2 件突然升到全部库存，同时出现合规通知，反而应立即处理。
什么时候等待，什么时候开 Case
| 条件 | 默认动作 | 升级条件 |
|---|---|---|
| Customer Order 与近期订单规模相符 | 等发货或取消释放 | 长期占用且订单、发货和取消均无法解释 |
| FC Transfer 尚在常见时长且数量变化 | 继续观察 | 超过常见时长、数量冻结、前台无法购买或承诺异常 |
| FC Processing 数小时到数天 | 查限制后观察 | 超过近期 30 天参考、数量突增或与活动不匹配 |
| 同时存在 Stranded/合规问题 | 优先修复根因 | 修复后预留仍不释放 |
| 货件数量本身不一致 | 转货件调查流程 | 调查完成后库存去向仍无法对齐 |
提交 Case 时不要只写“库存卡了很久”。一次提供 marketplace、Seller SKU、ASIN、FNSKU、三类 Reserved 数量、首次发现和最后变化日期、相关 Shipment/Order/Removal ID、前台送达承诺、限制通知、日级快照，以及你已排除的路径。证据越接近状态机，越少在“请继续等待”之间往返。
把预留状态接到补货和广告决策
补货模型不能把所有 Reserved 加回可用库存，也不能全部从未来供给中删除。建议把供给分成三个层级：
| 层级 | 建议包含 | 主要用途 |
|---|---|---|
| 立即可售供给 | Available | 判断今天是否可能断货 |
| 网络可购买供给 | Available + 当前仍可购买的 FC Transfer | 观察前台能否接单及配送承诺 |
| 未承诺未来供给 | Available + 风险折扣后的 FC Transfer + Inbound | 做情景化补货，不含 Customer Order |
风险折扣不是 Amazon 官方公式，应由自己的站点、运营中心和历史转运分布估计。Customer Order 已经被需求占用；FC Processing 释放时间不确定，也不应默认 100% 计入短期安全库存。
每周运行一次安全排查：
- 导出 Reserved、Manage Inventory 和 Restock 当前数据；
- 以 marketplace + Seller SKU + ASIN + FNSKU 连接；
- 与昨日快照比较三类数量和最后变化时间；
- 先排 Customer Order，再查 FC Transfer 年龄，最后处理 FC Processing 原因；
- 同步检查货件、Stranded、不可售、移除和合规通知；
- 只有达到异常阈值的记录进入 Case 队列；
- 补货和广告只读取分层供给，不读取一个合并的 Reserved 总数。
如果预留来自买家退款、退回件或换货，应继续用《Amazon FBA 退款后商品去哪了？》连接客户事件、库存和赔偿。预留库存排查的目标不是让所有数字立刻归零，而是让每一件库存都有一个可解释的状态、时钟和下一步。
Reserved 报表解释当前可用性，Inventory Ledger 解释数量为什么变化；两者不要互相替代。可用《Amazon FBA 库存为什么对不上？》核对 FC Transfer、调整与期末余额是否真正闭合。
FBA 专题导航：Amazon FBA 库存、费用、资金与对账指南，可按“资金周转 → 补货与费用 → 入仓 → 库存状态 → 赔偿对账”继续阅读。
