FBA 货件状态全对照：每一个状态卡住该查什么（含到仓不上架的处理顺序）

先给结论，省得你在后台来回刷新：FBA 货件状态只回答一件事：货走到哪一格了，它不回答为什么慢。所以「卡住了」这个说法本身就不精确，你得先确认卡在哪一格，因为不同格子对应的责任方完全不同：前三格（创建、待发运、已发运）的问题在你和承运商，中间两格（在途、已送达）基本只跟承运商有关，最后三格（已签入、接收中、已关闭）才轮到亚马逊仓内。

还有一条更实用的：在状态变成 Closed 之前，你没有资格开对账调查。这是很多人白等、白发工单的根源——不是亚马逊不理你，是那个入口根本还没长出来。

本文的口径全部来自亚马逊公开页 sell.amazon.com 的货件追踪说明，2026 年 8 月 25 日实查。凡官方没写明的时长，下面会直说「官方未给出统一时长」，不替它编一个数字——中文圈流传的那些「几天必须入库」的说法，绝大多数找不到官方出处，按它去掐表只会让你在错误的时间点发工单。

看状态的入口在卖家后台的发货队列（Shipping Queue）：找到那一票货，点状态旁边的「Track shipment」，进货件摘要页。后面讲的每一个查法，落点都在这一页里，不需要额外工具。

一张表：八个状态分别在发生什么、卡住先查哪里

表里的定义是官方原话的中文转述，不是逐字引用；天数（45 天／75 天）是官方页写死的数字，原样照抄。

发出去之前：状态不动，多半是你这边没动

Shipment created、Ready to ship、Shipped 这三格，本质上是你自己的动作在推进状态。Ready to ship 是打印标签触发的，Shipped 是交件触发的。如果货件停在 Shipment created 好几天，那不是亚马逊卡你，是这批货还没走到打标签那一步。

这一段最常见的两个坑：一是货件计划被系统拆成两个甚至三个货件、分发不同仓库，你只处理了其中一个，剩下的还停在创建态；二是箱唛打了但贴错箱、或者商品条码没做对，货到仓被判异常，而这类问题在状态上不会立刻显形，要等 Receiving 才暴露。

还有一个容易忽略的：Shipped 是「交给承运商」这个动作触发的，不是「货离开你仓库」触发的。自提约在下周、货堆在你自己仓里的这几天，状态当然不动，这不是异常。

发货前该做对的事另有专文，本文不重复——那是「发之前别做错」的范畴，见文末分工说明。

在路上：In transit 和 Delivered 的区别，最容易误判

这两格的差别值得单拎出来讲，因为读错一次就会白等一周。

In transit 意味着承运商确认了在运，亚马逊此时对这批货一无所知。你要查的是承运商官网的轨迹，不是卖家后台。这一格慢，去催承运商。

Delivered 不等于亚马逊收到了你的货。按官方定义，它表示货件即将到达亚马逊地点，或者已经到了但还没完成签入。换句话说，Delivered 之后货可能还在卡车上、还在堆场排队。很多人一看到 Delivered 就开始算「亚马逊压了我多少天」，其实那段时间货还没进门。

判断方法很简单：手上有承运商的签收凭证（POD），且状态还是 Delivered 没往 Checked in 走，那就是仓库门口的排队问题；连 POD 都拿不到，那还是承运商的问题。

到仓了却不上架：Checked in 和 Receiving 在做的事不一样

这是本文最想讲清楚的一段，也是中文内容里最含糊的一段。

Checked in 的官方定义是：货件已从堆场移到卸货门、准备卸货。注意，Checked in 只是排到了卸货位，一件都还没扫。所以看到 Checked in 却查不到库存增加，这是完全正常的，不是丢件。

Receiving 才是真正开始扫描入库。官方对这一格有一句很关键的说明：扫描到第一张货件标签时进入该状态，已接收的单元即可售。也就是说入库是滚动生效的，不是全部扫完才一起上架——你会看到可售库存一点一点往上涨。

那到底多久才扫完？官方公开页未给出统一时长（2026年8月25日实查，sell.amazon.com 货件追踪页对 Receiving 状态只定义了触发条件与可售规则，没有写明处理时长）。市面上流传的各种「X 天内必须完成」的数字，来源都不是这一页，本文不采用。

所以这一格的正确判法不是掐表，是看数字涨不涨：进入 Receiving 之后，每天看一次货件详情里的已接收数量。数量在涨，说明仓库在处理你的货，等就行；连续几天纹丝不动，才有必要往下一步走。

顺带说一句，旺季（Prime Day 前后、Q4）仓内节奏明显变慢是常态，同样不构成开工单的理由——官方页没有给出旺季的另一套阈值，所以「旺季爆仓」只能解释慢，不能当作异常的判据。

三个看起来像异常、其实正常的现象

第一，Checked in 停了两三天没动。这一格的定义就是「排到卸货位、准备卸货」，卸货本身要排队，官方没有承诺时长。这时候发工单，得到的回复通常是让你继续等。

第二，Receiving 已接收数量小于发货数量。入库是滚动扫描、逐步生效的，中途看到差额是过程量不是结果量。只有走到 Closed，那个差额才算最终差额。

第三，同一批货被拆成多个货件、进度差很多。不同目的仓的处理节奏本来就不一样，A 仓已经 Closed、B 仓还在 Receiving 是常见形态。判断要按货件逐票判，不要按「这批货」整体判。

照这个顺序排查，别一上来就发工单

把上面的内容压成一个可执行的顺序，遇到「货件卡住了」照着往下走：

1. 先看状态落在哪一格——前三格找自己和承运商，中间两格找承运商和签收凭证，后三格才是仓内节奏
2. 状态在 Delivered，先确认拿没拿到承运商的签收凭证；没拿到就是运输段的事，不是仓库的事
3. 状态在 Checked in，什么都别做，等它跳 Receiving
4. 状态在 Receiving，每天记一次已接收数量；只要在涨就继续等，连续几天不涨再往下走
5. 状态变成 Closed 且有差额，这时候才进对账流程，走下一节的五步

这个顺序的价值不在于快，在于不把时间浪费在没有入口的动作上。前四步里没有任何一步需要开 case，真正能开的入口只有第五步。

什么时候才该开调查：官方只认一个信号

到这里就能回答开头那句话了。按官方页的对账流程，只有当货件状态变成 Closed，符合条件的商品才会出现「Action required」下拉菜单——那个菜单就是对账调查的唯一入口。状态没到 Closed，你在货件详情页里找不到它。

Closed 是怎么来的？两条路：一是亚马逊确认收全了你货件里的所有单元；二是超时自动关闭——国内货件开启超过 45 天、国际货件超过 75 天（2026年8月25日实查）。这意味着最坏情况下，你需要等到 45 天或 75 天那条线，货件才会自己走到可对账的状态。

按官方页给的顺序，Closed 之后的动作是这样的：

1. 打开货件摘要里的「Contents」标签页，看预期数量与实际定位数量的差额
2. 确认该货件符合对账资格，符合的商品会出现「Action required」下拉菜单
3. 对照官方的常见入库问题清单，先自查差异原因
4. 用「Action required」下拉菜单说明情况：要么确认你实际发的数量与货件登记数不一致，要么请求亚马逊调查这个差额
5. 提交后关注案件状态；官方明确要求，对账请求相关的问询须在五个工作日内回复

第 5 条那个五个工作日容易被忽略：case 提交之后不是等结果，是要盯着回复。逾期不回，案件按官方流程会走向不利于你的结果。

至于差额确认之后怎么算钱、哪些能赔哪些不能赔，那是另一条线的事，站内有专文。工具层面，reimburseops.com 这类自助审计工具的做法是让你上传后台导出的 CSV，按严重度把疑似少赔漏赔的记录列出来，适合货件量大、人工核不过来的卖家；小卖家用货件详情页逐单核也够用。

一句话分工：这三篇各管一段

FBA 入库这件事在本站被拆成了三篇，边界很清楚，别拿错工具：

• FBA 入仓贴标要求 管发之前别做错：条码怎么选、标签贴哪、外箱旧码怎么处理。这一篇做对了，后面卡住的概率大幅下降。
• 本篇管发出去之后卡在哪：八个状态各是什么、卡住查哪里、什么时候才该开调查。
• FBA 索赔自查 SOP 管确认丢了怎么把钱要回来：账单核对、赔付口径、AI 怎么帮你算。

顺序是固定的：先按第一篇做对，再按本篇判位置，最后到 Closed 有差额了才进第三篇。跳过中间一篇直接去索赔，最常见的结果是「入口都还没出现」。

延伸阅读

• 亚马逊 FBA 入仓贴标要求：条码、包装、外箱标签怎么做才不被拒收
• 亚马逊 FBA 索赔自查 SOP：把被亚马逊吞掉的钱找回来
• 亚马逊 FBA 退货怎么处理：退回的货去哪了、什么时候赔你
• 亚马逊 FBA 费用计算全拆解：每一项怎么算