亚马逊FBA容量不够，要不要用Capacity Manager？先算清预留费和绩效抵扣

平台观察

2026-11-10

263

旺季补货会前，财务表里有一格特别容易被填成0：Capacity Manager的reservation fee。

旺季FBA额外容量申请前的预留费与销量测算（原创专题配图）

旺季FBA额外容量申请前的预留费与销量测算

运营给出的理由通常很顺：“不是有performance credits吗？货卖掉就能抵回来。”

这句话不能说错，但拿它直接做预算，风险不小。截至2026年10月22日，亚马逊美国站现行Capacity Manager规则允许绩效抵扣最高覆盖100%的预留费，但“有抵扣机制”和“这次一定不用付预留费”完全是两回事。如果目标月份销量不够，抵扣不足的差额仍由卖家承担；如果额外容量获批后根本没用上，预留费也不会因为“没发这批货”自动消失。

所以，对一个已经确认旺季需求、只是FBA标准尺寸容量不够的卖家来说，现在真正要决定的不是“Capacity Manager值不值得用”，而是三个更具体的问题：到底缺多少容量、最高愿意报多少预留费，以及销量低于预期时，这笔净费用能不能接受。

先确认你缺的是“额度”，不是货还没进去

Capacity Manager解决的是FBA capacity limit，不是所有“旺季没货卖”的问题。

美国站FBA容量按仓储类型分别管理。标准尺寸、超大件、服装、鞋类、extra-large都有各自的容量，不能互相调。与此同时，Capacity Monitor里的使用量不只是仓内现货，正在去亚马逊履约中心的货件、尚未关闭的开放货件也会占用容量。

这意味着，在准备花钱申请额外容量之前，先把Capacity Monitor打开，比先研究报价更重要。

假设团队说：“11月还差400立方英尺。”

这个400首先要拆开看：是不是已经创建但实际上不会再发的旧货件占着额度？是不是产品尺寸或体积数据与团队自己的装箱表不一致？是不是货已经发了，只是还在运输或接收中？又或者真正卡住的是仓库接收速度、货源交期，而不是capacity limit？

如果瓶颈不是容量额度，买更多额度不会让库存凭空变成可售状态。

还有一个时间边界很容易忽略：Capacity Manager当前不能为正在进行的本期提交新请求，只能申请已经公布confirmed或estimated limit的未来期间。如果10月22日才发现10月本身已经没容量，它不是当天补洞的按钮。

额外容量获批后，亚马逊可能允许卖家提前最多一个月使用这部分容量，以便提前创建货件、把库存送进网络。但“容量提前可用”和“库存已经完成接收、已经可售”仍然是两件事。

最高预留费不是最终账单，却是你主动承担的风险上限

Capacity Manager要求卖家填写两个核心数字：需要多少额外容量，以及自己愿意支付的最高预留费，单位为美元/立方英尺。

这里最容易产生两个相反的误解。

一种是把自己填写的最高报价直接当最终收费。并不是。

亚马逊会根据网络可用容量定期处理请求，当前帮助页面给出的示例频率是每3至4天一次，并从每立方英尺预留费报价较高的请求开始分配。请求获批时，实际适用费率可能低于卖家自己填写的最高值。

同一周获批的卖家适用该周最低的获批预留费率；同一期间如果以后又有请求以更低费率获批，已经获批的预留费率还可能继续下调。

所以，报3美元/立方英尺，不等于最后必收3美元。

但另一种误解更危险：既然最后可能下调，就把最高报价往上填，反正“大概率不是这个价”。

也不对。

最高预留费应该被当成团队愿意承担的费用上限，而不是抢容量时随手拉高的筹码。如果市场紧、你的请求最终就在较高水平获批，而销量又没有跑出来，差额是真的可能进入账单。

Capacity Manager不要求预付款。获批时不会立刻扣预留费，费用在所申请期间结束之后结算，最终收费是预留费减去已获得的performance credits之后的差额。

现金不是申请当天出去，但风险在获批那一刻已经开始形成。

绩效抵扣到底怎么算？不是“全店GMV×15%”

这是这道题最值得算清的一层。

截至目前，美国站官方规则是：使用额外容量产生的合格销售额，每1美元可产生0.15美元performance credit，也就是15%。

问题在于，什么叫“使用额外容量产生的销售额”？

亚马逊不是要求卖家逐件证明“这一单恰好来自我用Capacity Manager新塞进去的库存”，也不是简单拿全店销售额乘15%。

在一个单一额外容量请求的简化场景里，官方计算逻辑可以理解成：

先计算额外容量在新总容量里的占比。

再用这个比例，对目标期间、对应仓储类型ASIN产生的FBA销售额进行分摊。

最后，对这部分分摊后的销售额按15%计算performance credits。

比如，一个美国站卖家的标准尺寸基础容量是1200立方英尺，额外获批400立方英尺，那么新的总容量就是1600立方英尺。

额外容量占比不是400÷1200，而是：

400÷1600＝25%。

假设目标月符合口径的标准尺寸FBA销售额是20000美元，那么按这一简化场景计算，分摊到额外容量的销售额是5000美元，performance credits约为750美元。

还有两个边界要守住。

第一，不是全店GMV。如果申请的是标准尺寸容量，就看相应仓储类型ASIN的FBA销售口径；MCF销售目前不进入performance credits计算。

第二，只计算申请期间内符合规则的销售。亚马逊虽然可能让额外容量提前开放，方便提前备货，但目标期间之外的销售不能自行挪进来冲当期预留费。

所以，看到“每销售1美元返0.15美元”就直接拿整店月销售额乘15%，很容易把抵扣预算做得过于乐观。

把“能不能全抵掉”换成一个更有用的问题

还是上面的卖家。

基础标准尺寸容量1200立方英尺，计划再申请400立方英尺。

为了演示，假设最终实际适用的预留费为2.40美元/立方英尺。注意，2.40美元只是本文算例假设，不代表当前市场报价。

那么目标期间的预留费总额是：

400×2.40＝960美元。

额外容量比例为25%。

如果当月对应仓储类型FBA销售额只有12000美元，分摊销售额为3000美元，performance credits约450美元，最后还会留下约510美元净预留费。

如果销售额做到20000美元，credits约750美元，净预留费约210美元。

要把960美元全部抵完，需要对应的分摊销售额达到6400美元。由于额外容量占比是25%，换算成该仓储类型目标期FBA销售额，就是大约25600美元。

于是团队终于有了一个能用于决策的数字：

不是“理论上可以免费”，而是“按照这个容量结构和费率，目标月大概要跑到25600美元的相应FBA销售额，才有机会把这960美元全部抵完”。

如果团队自己的保守预测只有12000美元，这时再把净预留费按0写进预算，就已经不是乐观，而是在忽略公式。

最高报价最好倒着算，不要先问别人报多少

很多卖家做Capacity Manager时，第一反应是去找一个“别人最近报多少”的答案。

历史获批费率当然有参考意义，Capacity Manager本身也提供历史reservation fee数据供卖家查看。但决定自己该报多少，更合理的方法其实是倒推。

继续用刚才的400立方英尺举例。

假设团队认为，在悲观销售情形下，这次额外容量产生的净预留费最多只能承受600美元。再多，就会明显侵蚀这批旺季补货能够增加的贡献利润。

悲观情形仍按12000美元同仓储类型FBA销售计算，预计credits约450美元。

那么可接受的预留费总额上限大约就是：

600美元可承受净费用＋450美元预计抵扣＝1050美元。

1050÷400＝2.625美元/立方英尺。

也就是说，在这些假设不变时，团队自己算出来的最高报价上限大约是2.62美元/立方英尺，而不是“听说最近有人报3.5美元，所以我们也报3.5”。

报得更低，可能降低获批概率；报得更高，则是在提高自己承诺承担的费用风险。这个取舍没有一个适合所有卖家的神奇数字。

而且，净预留费并不是这批货的全部成本。

为了利用额外容量备下来的库存会占现金，头程和其他适用FBA费用照常存在。Capacity Manager的performance credits抵的是reservation fee，不等于额外库存进入FBA以后所有费用都被免掉。

反过来，不申请也有机会成本。如果不增加容量，会让已经验证需求的SKU在旺季断货，真正应该比较的是“多获得这400立方英尺之后能够多实现多少贡献利润”，而不是把整个旺季销售额都算成Capacity Manager创造出来的收益。

申请多少，比“报多高”更应该先决定

如果真实缺口只有250立方英尺，为了“旺季保险”直接申请600立方英尺，问题不只是多占一点容量。

获批之后，即使最终没有把这些容量充分使用，reservation fee也不会因为实际利用率低而自然消失。亚马逊官方甚至明确提醒，如果没有信心有效利用容量并通过销售获得足够的performance credits，就不建议申请，因为剩余差额仍然需要承担。

因此，申请量最好从已经验证的补货缺口出发。

先算目标月现有容量、已经占用的在库和开放货件，再看高确定性的补货计划到底多出多少体积。不要把所有“也许会爆”的SKU全部塞进容量申请，更不要为了抢旺季空间，把尚未验证需求的库存量一起包装成刚需。

对普通标准尺寸商品来说，产品包装后的单位体积在这里直接影响钱。申请量以立方英尺计，如果团队还在用供应商最初给的尺寸估体积，却没有核对Seller Central里亚马逊实际采用的产品体积数据，容量预算本身就可能偏掉。

获批之后，别再假设“反正可以取消”

Capacity Manager给卖家留了request expiration date。

这个功能很适合和实际业务节点绑定。比如供应商最晚哪天必须确认排产、海运最晚什么时候订舱、超过哪一天即使再批容量也赶不上目标销售期，就把请求的有效期和这些节点对应起来。

在请求仍处于pending状态时，卖家可以在获批或到期之前取消请求，也可以取消后重新提交更高报价。

但一旦请求已经granted，情况就不同了。

当前官方规则并不是“获批以后随时反悔”。已获批请求只有在特定情形下才有取消空间，其中一个重要场景是：此前依据estimated limit申请了额外容量，后来亚马逊确认的基础capacity limit比原先估计更高。这种情况下，规则允许在规定窗口内取消部分或全部此前获批的额外容量，Capacity Manager也提供相应的auto-cancellation机制。

这恰好说明为什么报价时不能把“以后不需要就退掉”当成默认退出机制。

同样，货没发出去也不是取消费率承诺的替代办法。官方FAQ已经明确：获批的额外容量即使实际没有使用，reservation fee也不因此改变。