Amazon FBA 后台经常同时出现几组看似矛盾的数字：库存页面显示 112 件，补货表里只有 96 件可用，入仓货件说已经接收 40 件，赔偿页面又出现丢失和找回。直接把这些页面截图放在一起，通常只会得到更多数字，而不是答案。
问题往往不在某一张表“算错”，而在于你把库存余额、库存状态、仓库事件和资金交易放进了同一个比较框。Inventory Ledger（库存分类账）的作用，就是像银行流水一样，把某个 FNSKU 的期初余额、期间变动和期末余额连成一条可复核链路。
先用 Summary View 证明余额是否闭合，再用 Detailed View 找到造成变化的具体事件。库存数量对上以后，才分别进入入仓调查、退货、赔偿或结算流程。Inventory Ledger 是库存证据，不是自动判定“Amazon 欠我多少钱”的索赔结果。
本文按 2026-07-17 可见的 Amazon 公开资料核对。Seller Central 的菜单名称、筛选项和政策窗口可能随站点与账户变化，实际操作应以当前账户界面为准。
Inventory Ledger 不是另一张库存快照
Amazon 将 Inventory Ledger 定义为库存的“银行对账单”。它把期初库存、接收、客户订单、退货、调整、移除和期末余额放在同一个报表体系中。2023 年 1 月 31 日起，它取代了 Daily Inventory History、Monthly Inventory History、Inventory Event Detail、Inventory Adjustments、Inventory Reconciliation 和 Received Inventory 六张旧报表。
| 视图 | 回答的问题 | 典型粒度 | 不要拿它替代 |
|---|---|---|---|
| Summary View | 期初经过全部期间变动后，是否得到期末 | 按日、周或月，并按国家或运营中心聚合 | 具体订单、货件或调整证据 |
| Detailed View | 哪一天、哪个 FNSKU、哪类事件改变了多少件 | 事件行，带 Reference ID、FC、Disposition 和 Reason | 当前可售、预留或不可售状态快照 |
通过 SP-API 请求时，Summary View 的 report type 是 GET_LEDGER_SUMMARY_VIEW_DATA，Detailed View 是 GET_LEDGER_DETAIL_VIEW_DATA。Amazon 官方资料说明，Detailed View 可查看 18 个月历史库存变动，并可按 Adjustments、CustomerReturns、Receipts、Shipments、VendorReturns 和 WhseTransfers 筛选事件。
如果只在 Seller Central 操作，通常可进入 Inventory Ledger 后在 Summary 与 Detailed 之间切换；Amazon 版主给出的调整事件示例是选择 Detailed view、Event type 为 Adjustments、日期范围后生成报表。不同站点 UI 可能调整，不要把一条旧菜单路径写进永久 SOP。
对账前先固定五个边界
库存分类账最常见的“假差异”，来自筛选边界不同。生成报表前先把下面五项写在对账表头，不要只保存下载文件名：
- Marketplace：美国、德国、日本等站点不能混在一条余额里。
- 库存身份：优先用 FNSKU；同一个 ASIN 或 MSKU 可能映射到多个 FNSKU、状态或历史关系。
- 位置：Summary 可以按 Country 或 FC 聚合。按国家汇总时，运营中心之间的转入转出可能互相抵消；按 FC 时则会分别出现。
- Disposition：SELLABLE、UNSELLABLE 等状态不是同一种可用性，不能只按商品标题合并。
- 日期与时区：期初、期末和事件日期必须使用同一时间边界。跨 UTC 与站点本地日切时，订单和退货可能落在相邻日期。
按月请求 Summary 时，Amazon 的 SP-API 文档要求开始日期和结束日期覆盖完整月份；按周也要使用周起止边界。日期边界无效可能返回空数据，而不是一张“零变动”的正确报表。
先用一条公式证明余额闭合
业务上可以把期末余额写成：
期末库存
= 期初库存
入仓接收
客户退货
调拨转入
找回
其他正向调整
− 客户出库
− 供应商退回或移除
− 调拨转出
− 丢失、损坏与弃置
± 其他事件
如果直接处理下载文件，应尊重报表原始字段和 Quantity 的正负号。不要先按事件名称手工反转一次，又在求和时把负数再减一次。最稳妥的程序口径是：
计算期末 = 期初 + Σ（期间内每条明细的带符号 Quantity）
余额差异 = 报表期末 − 计算期末
Summary 字段已经拆出 StartingWarehouseBalance、Receipts、CustomerShipments、CustomerReturns、WarehouseTransferIn/Out、Found、Lost、Damaged、Disposed、OtherEvents、UnknownEvents 和 EndingWarehouseBalance。先在同一行验证这些字段，再下钻到 Detailed；不要一开始就在几十万行明细中搜索“看起来可疑”的数字。
Summary 负责验算，Detailed 负责举证
一套可重复执行的对账流程是：
- 选定一个 Marketplace、一个 FNSKU、一个 Disposition 和同一日期范围。
- 先下载日级 Summary；若跨多个运营中心，分别保留 Country 与 FC 两种聚合结果。
- 计算每一行的期末余额差异，先筛出不闭合或 UnknownEvents 不为零的日期。
- 对异常日期下载 Detailed，先不筛 Event type，以免遗漏事件；数据量过大时再按官方支持的事件类型拆分。
- 用
ReferenceID连接订单、入仓货件、移除订单、调整或其他操作记录。 - 按
FulfillmentCenter、Disposition、Reason和Country判断它是位置变化、状态变化还是实际数量变化。 - 保留原始 TSV/CSV、生成时间和筛选条件，再制作自己的异常表；不要只保留二次加工后的 Excel。
Amazon 说明 Summary 会按所选日、周或月刷新，Detailed 事件接近实时更新。因此刚发生的接收、退货或调整短暂不同步，不应立刻被当成永久缺失。先记录首次发现时间，再观察事件是否补齐。
Detailed View 的字段应该怎样读
| 字段 | 对账用途 | 常见误区 |
|---|---|---|
| Date | 确定事件落在哪个日切区间 | 直接与另一报表的本地日期比较 |
| FNSKU / MSKU / ASIN | 锁定库存身份与当前映射 | 只按 ASIN 合并多个 FNSKU |
| EventType | 区分接收、出库、退货、调整与转运 | 把所有负数都叫“丢件” |
| ReferenceID | 连接订单、货件、移除或调整证据 | 只记日期和数量，无法回到原事件 |
| Quantity | 按原始正负号重建余额 | 人为重复反转符号 |
| FulfillmentCenter / Country | 判断跨仓转运和站点边界 | 国家汇总与 FC 明细直接比较 |
| Disposition | 区分可售与不可售等库存状态 | 把总库存等同于可售库存 |
| Reason | 解释调整原因并选择下一份证据 | 看到 Adjustments 就默认可索赔 |
| ReconciledQuantity / UnreconciledQuantity | 观察事件是否已被后续库存变化核销 | 把未核销数量直接乘售价当应赔金额 |
UnreconciledQuantity 是继续调查的线索，不是自动成立的赔偿数量。赔偿资格、责任、成本口径、索赔窗口和最终结算仍需进入对应的 reimbursement 与 settlement 证据链。
六类常见差异怎样回到原事件
1. 入仓货件已签收，但 Receipts 还没完整出现
承运商签收、Amazon 开始 receiving、FNSKU 被接收和最终可售是不同事件。Inventory Ledger 只能证明进入仓库分类账的数量；箱内装了什么、所有权和交付证据仍需按《Amazon FBA 入仓数量不对怎么办？》建立 Shipment ID、箱数重量、FNSKU、POD 与调查资格链。
2. 客户已经退款，但 CustomerReturns 没有同日增加
退款、实物寄回、运营中心接收、Disposition 判断和重新入库不会必然发生在同一天；Returnless resolution 更不会产生库存回仓。用《Amazon FBA 退款后商品去哪了？》按订单号连接退款、退货、库存和赔偿，不要看到退款就强行给 Ledger 加一件。
3. Lost、Found、Damaged 与赔偿金额对不上
库存事件和资金事件属于两本账。Lost 后可能先赔偿，随后 Found 又触发赔偿冲回；Damaged 也不等于所有责任都由 Amazon 承担。先在 Ledger 证明数量事件，再按《Amazon FBA 赔偿为什么少？》核对采购成本、赔偿交易、reversal 和结算净额。
4. FC Transfer 让仓级数字变化，国家总量却不变
同一件货从 FC-A 转出、在途、再进入 FC-B，会让两个运营中心的明细分别变化，而 Country 聚合可能净额为零。当前可用性和转运时钟应继续看《Amazon FBA 库存一直预留怎么办？》；不要把仓内转运误报成整站丢失。
5. 期末总库存对了，可售数量仍然少
Ledger 证明数量守恒，不代表每件库存都有有效 Offer 或可立即配送。若差异集中在 Disposition、Stranded 或 inactive listing，应转到《Amazon FBA 有库存却不可售怎么办？》按 Seller SKU、ASIN、FNSKU 和原因码修复。
6. 移除、弃置后仍把原库存算在资产里
Removal、Disposed 或 VendorReturns 已经改变库存位置或终止未来销售可能。对账完成后，还要按实际回收现金和处置成本更新《Amazon FBA 库龄越来越长怎么办？》中的净回收决策表，不能一边确认弃置，一边继续把原成本保留为 FBA 可售资产。
一个 120 件期初库存的完整例子
假设某美国站 FNSKU 在日级、Country 聚合、SELLABLE 口径下有以下变动：
| 事件 | 数量 | 证据 |
|---|---|---|
| 期初库存 | 120 | Summary StartingWarehouseBalance |
| Receipts | +40 | Detailed Receipt + Shipment/FNSKU |
| CustomerShipments | −55 | Detailed Shipment + ReferenceID |
| CustomerReturns | +4 | Detailed CustomerReturns + 订单链 |
| Lost | −2 | Adjustment + Reason |
| Found | +1 | 后续 Adjustment + ReferenceID |
| Disposed | −3 | Removal/Disposal 记录 |
| 计算期末 | 105 | 120 + 40 − 55 + 4 − 2 + 1 − 3 |
如果 Summary 的 EndingWarehouseBalance 也是 105，库存分类账已经闭合。此时库存页面只显示 98 件可售，不代表还丢了 7 件；这 7 件可能处于预留、不可售或其他状态，必须比较相同 Disposition 与可用性口径。
如果 Summary 期末是 105，但按 Detailed 求和只有 103，应先检查日期边界、FC/Country 粒度、遗漏的 EventType、OtherEvents 和 UnknownEvents。只有这些边界一致后，2 件差异才值得进入异常调查。
Unreconciled Quantity 不为零时怎样排查
- 保存异常行的 Date、FNSKU、EventType、ReferenceID、Quantity、FC、Disposition、Reason 与 Country。
- 查看同一 ReferenceID 是否存在后续 Found、Return、Transfer 或反向 Adjustment。
- 把首次出现、最后变化和当前年龄分开；接近实时不等于所有链路同时完成。
- 按事件类型进入对应页面：入仓看 Shipment，退货看 Order/Return，移除看 Removal Order，赔偿看 Reimbursements 与 settlement。
- 确认站点当前政策窗口和账户页面显示的 eligibility date，不用一条旧的“统一 60 天”规则覆盖所有事件。
- 若事件已经在库存层核销，但资金层仍未闭合，停止反复改 Ledger，转去做赔偿和结算对账。
提交 Seller Support 前准备一份可复核证据包
不要只写“库存少了 2 件”。一个有效证据包至少包括：
- Marketplace、Seller ID、MSKU、ASIN、FNSKU 与 Disposition；
- 同一日期范围的 Summary 和 Detailed 原始文件及生成时间；
- Country 与 FC 聚合选择、时区和日切说明；
- 期初、每类变动、计算期末、报表期末和差异公式；
- 异常行与前后相关行的 ReferenceID、Reason 和截图；
- 关联的 Shipment、Order、Return、Removal、Reimbursement 或 Case ID；
- 你已经排除的口径差异，以及希望 Amazon 核实的具体事件。
这样的 Case 可以被另一位运营人员完整复算，也能减少客服只回复“请等待库存更新”的往返。
把 Inventory Ledger 变成每周例行控制
不需要每天人工对全店所有明细。可以建立三层节奏：
| 频率 | 范围 | 动作 |
|---|---|---|
| 每日 | 高销量、正在 receiving、异常退货或大额调整的 FNSKU | 保存 Summary 快照，监控首次异常与最后变化 |
| 每周 | 全部活跃 FNSKU | 计算余额差异、UnknownEvents 和 UnreconciledQuantity，按金额与缺货风险排序 |
| 每月 | 库存、赔偿与财务关账 | 冻结原始报表哈希，连接 settlement，并把净差异写入会计调整 |
Ledger 期末不是补货模型里的“可用供给”。补货仍要把可售、预留、入仓和在途分别处理，再按《Amazon FBA 该补多少货？》计算库存位置、保护期与安全库存。完成库存和赔偿对账后，再回到《Amazon FBA 为什么越卖越缺现金？》核对被库存和未结算余额占用的真实资金。
最后给一张执行清单
- 固定 Marketplace、FNSKU、位置、Disposition、日期和时区。
- 先用 Summary 验证期初 + 期间变动 = 期末。
- 只对不闭合日期或异常事件下钻 Detailed。
- 按原始 Quantity 符号计算，不重复反转。
- 用 ReferenceID 连接订单、货件、移除和调整。
- 把库存核销与赔偿结算拆成两条链。
- 保留原始报表、筛选条件、生成时间与哈希。
- 按风险和金额排序 Case，不把短暂刷新差异全部升级。
Inventory Ledger 的价值，不是再增加一张报表，而是把“我觉得少了”改写成可计算、可定位、可举证的库存事件。先证明数量是否守恒，再判断状态、责任与现金结果，FBA 的入仓、退货、预留和赔偿才会真正形成闭环。
Amazon 官方资料
- Amazon SP-API：FBA Reports 与 Inventory Ledger 字段
- Amazon SP-API：Request a report
- Amazon News：Inventory Ledger 取代六张旧报表
- Amazon 版主：在 Detailed View 筛选 Adjustments
想按完整顺序继续学习，可返回《Amazon 广告优化与 RongAds 学习路线》的 FBA 库存、资金与赔偿闭环。
Inventory Ledger 解释商品数量如何进入并在运营中心之间变化；入仓配置费属于另一条费用链。创建货件前可先看《Amazon FBA 入仓配置费怎么选？》，保存 shipping plan 与 shipment 级成本基线。
FBA 专题导航：Amazon FBA 库存、费用、资金与对账指南，可按“资金周转 → 补货与费用 → 入仓 → 库存状态 → 赔偿对账”继续阅读。
入仓事件的源头：库存总账能否解释接收变动，取决于货件创建时的 SKU、箱号、数量和交运证据是否完整。发货前控制清单见Amazon FBA 预处理与装箱指南。
Returnless 的库存含义：客户退款后保留商品时，通常不会出现实物退回、接收和库存回补事件。台账应单独标记处理结果，设置方法与对账字段见FBA 无需退回退款决策指南。
Grade and Resell 要单独跟踪库存状态：原客户退货、分级处理、Used 可售、搁浅、二次销售与再次退货不能合并成一次库存变动。完整字段与净回收模型见FBA Grade and Resell 指南。
