先说一个我反复遇到的场景：一位做亚马逊和独立站的卖家，后台挂着三个平台、两个海外仓、一个国内仓。运营早上说某款产品要断货了，赶紧补；仓库主管说这个 SKU 仓里还有 1800 件；财务月底盘出来说库存金额比上季度高了 40%。三个数字都"没错"，但拼在一起就是一锅粥。问题不在人，也不在 ERP 买得够不够贵，而在于这家公司从来没有定义过一件最基本的事：什么叫做"库存"。
所以当有人问我"ERP 跨境电商供应链协同，库存管理到底从哪里开始"，我的回答通常会让对方愣一下：不是从选 ERP 开始，不是从做补货公式开始，甚至不是从盘库开始，而是从定义"库存真相"开始，谁拥有、放在哪、什么状态、能不能卖、什么时候能卖。这五件事没有统一定义之前，上任何系统都只是把混乱搬进数据库。
这篇文章我按四个起点、四层模型、四种企业情形、五组取舍来讲，中间会以数跨境作为观察样本，给出我实际看到的字段、流程和指标口径。数据部分我会明确标注来源和口径，凡属推演或模拟的，都会写明，不会拿"行业平均提升 30%"这种没有出处的话糊弄你。
我把这个判断拆成三句话，这三句话的顺序不能颠倒，颠倒一次就要多花半年时间返工。
库存管理真正的起点是"语言统一"。同一个 SKU，在运营嘴里叫爆款 A，在采购表里叫工厂型号 B，在平台后台叫 ASIN 尾号，在海外仓系统里叫客户编码 C。这四个名字如果没被映射到同一个内部 SKU 上，任何库存汇总都是错的。
比 SKU 更容易被忽略的是库存状态。多数团队只认"有货/没货"两种状态，实际跨境场景至少需要区分：可售、预留、占用、待检、冻结、在途、退货待处理、不良品。少了这些状态，就会出现"仓库说有 1800 件，但其中 600 件是客户退货未质检、400 件已被订单占用"的典型误判。
库存数量不是静态数字，而是一串事件的结算结果。采购下单、头程发货、清关放行、海外仓收货、上架、销售出库、退货入库、调拨、报损、盘点，每一个动作都会改变库存状态。ERP 的核心价值不是"存一个数字"，而是把业务事件翻译成库存状态变化，并保证同一条事实对所有角色可见。
账实一致不是财务部门的月度工作，而应该是每一次收货、每一次上架、每一次拣货时的即时校验。等到月底再对，差异已经无法归因，只能靠猜。
补货公式是第四件事，不是第一件事。理由很直白：补货算法吃的是"可售库存、在途、销量、交期"这四个输入，如果可售库存的定义是错的、在途数据是手工填的、销量口径混了取消订单，那么算法越精密，错得越整齐。
我给很多团队说过同一句话：先把库存数做到"敢签字"，再谈自动化补货。
国内电商的库存协同相对简单：一盘货、一个仓、一套主体。跨境电商把这件事的复杂度放大了五到十倍，而且放大的是"维度"，不是"数量"。下面四层复杂度，是我在实际项目里逐层踩过的。
一个中等规模的跨境卖家，库存通常同时存在于这些地方：平台仓（如 FBA、平台官方仓）、第三方海外仓、自建海外仓、国内备货仓、头程在途、调拨在途、退货处理区、不良品区。每一个节点的数据来源、更新频率、字段定义都不一样。
更麻烦的是"在途"这一层。头程在途和调拨在途在业务上是两回事：前者受船期、清关、入仓预约影响，后者受内部调拨单和仓库作业节奏影响。但很多团队的报表把它们合成一个"在途数量"，结果补货时算重了，或者两笔都没算。
同一个 SKU 可能属于不同店铺主体、不同公司主体，甚至不同货主。海外仓系统里按"货主"维度记账，平台后台按"店铺"维度展示，ERP 如果按"内部 SKU"维度汇总，三者之间必须有清晰的映射关系。
我见过最典型的错误，是把"店铺"当成库存归属单位。结果一家公司开了两个店铺卖同一款货，海外仓实际只有一批货，两个店铺都以为自己有独立库存，双十一同时放量，直接超卖。
下面是跨境电商库存最常见的状态集合，我建议每个团队都对照检查一遍，看自己系统里到底覆盖了哪几种：
这八种状态如果没有全部建模，你的"可售库存"必然是一个被高估的数字。超卖很少是同步延迟造成的，多数是状态缺失造成的。
平台仓、海外仓、国内仓三者的规则差异，往往决定了库存同步能不能做对。平台仓有入仓预约与容量限制，海外仓有收货作业窗口与盘点 SLA，国内仓有备货周期与装箱约束。跨境还有一层时效变量：头程海运 25，45 天、空运 7，15 天、海外仓调拨 2，7 天，这些时间直接影响补货点和安全库存。
具体平台的库存同步频率、预留规则、API 限流、补货限制，各平台会不定期调整，请以各平台官方最新文档为准。我这里只强调方法论：同步规则必须被写进流程文档，而不是停留在某个运营的脑子里。
我把这些年见过的坑收敛成六条。每条我都写了"后果"和"纠正动作"，因为只列坑不给解法，等于没说。
后果：把线下混乱原样搬进系统，三个月后团队开始说"ERP 没用"，实际上系统只是把问题可视化了。更糟的是，流程问题被误判为系统问题，于是换系统，再踩一遍同样的坑。
纠正动作：上系统前先做一次"字段盘点"，把当前所有在用的 SKU 编码规则、仓库命名、状态名称列出来，标出冲突项。这项工作通常需要 3，5 个工作日，但它能让实施周期缩短至少一个月。
后果：平台后台显示库存 500，海外仓实际可拣 200，中间的 300 件是预留、占用和退货待检。同步得越快，错得越同步。
纠正动作：同步接口的字段清单里必须包含状态字段，并且为每个状态定义"是否计入可售"。这一条不做，后面的补货策略全部失真。
后果：同一款产品在不同平台、不同批次下生成多个 SKU，库存被拆成几份，每一份都看起来不够卖，于是重复补货，形成滞销与断货并存的奇观。组合装和赠品是重灾区。
纠正动作：建立内部 SKU 作为唯一主键，平台 SKU 只作为映射字段；组合装必须有明确的 BOM 拆解关系，出库时按组件扣减。
后果：在途不计入补货判断，导致重复下单；退货不计入可售判断，导致过度备货；不良品不报损，导致库存金额虚高、周转率失真。
纠正动作：把这三类都建成独立的库存池，各自有责任人和处理时效。退货待处理超过 7 天未质检，就应该触发预警。
后果：运营按可售数量做决策，财务按含税成本做核算，两边在月度会议上各说各话。库存周转率、库存金额、毛利三个数字长期对不上。
纠正动作：定义一套"库存口径词典"，明确每个指标的计算公式、数据来源、责任人和更新频率，运营与财务共同签署。
后果：收货不点数、上架不扫码、退货不质检，指望系统自动纠正。系统只能记录你告诉它的事，它无法知道你少收了三箱。
纠正动作：对每个改变库存的节点设置责任人和容差规则。例如收货差异超过 2% 必须二次核对，盘点差异超过 500 元必须归因到具体环节。
我给客户做诊断时，习惯用四层模型来定位问题。自下而上，任何一层缺失，上面一层都建不起来。
最小可用交付物是一张"四表一映射"：SKU 主表、仓库节点表、店铺/货主表、供应商表，以及平台 SKU 与内部 SKU 的映射表。四张表加上一张映射，几乎能解决 70% 的库存对不上问题。
内部 SKU 编码建议包含品类段 + 流水号，不包含平台信息、不包含季节信息、不包含店铺信息，因为这些都会变，而 SKU 一旦生成就不应该再变。
把平台仓、海外仓、国内仓、在途虚拟仓、退货虚拟仓、不良品虚拟仓全部建成独立节点。虚拟仓是很多团队缺的一环，没有虚拟仓，在途和退货就只能挂在 Excel 里。
映射关系要记录生效时间和失效时间，而不是简单覆盖。历史订单的库存回算依赖这张表的历史版本。
这一层的核心是确定库存记账的颗粒度：地点 + 货主 + SKU + 批次（如适用）+ 状态。颗粒度定得越粗，后期越难拆；定得越细，日常维护成本越高。我的建议是按业务是否真的需要批次和效期来决定，不要为了"先进"而全量启用批次管理。
事件流层要做的事，是把每一个业务动作变成一个带时间戳、带责任人、带单据号的库存事件。采购入库、头程发货、到仓收货、上架、销售出库、退货入库、调拨、报损、盘点，全部落成事件记录。
这一层做得好不好，判断标准只有一个：任何一个库存数字，能不能一键回溯到它是被哪些事件算出来的。做不到，就说明事件流还是断的。
下面是我常用的库存台账最小字段定义，可以直接拿去和技术团队对齐：
— 库存台账（最小可用版）字段定义草案
CREATE TABLE inv_ledger (
event_id BIGINT, — 事件ID，同一库存变动唯一
event_type VARCHAR(32), — PURCHASE_IN / TRANSFER_OUT / SALE_OUT / RETURN_IN / SCRAP / STOCKTAKE
event_time DATETIME, — 业务发生时间（非录入时间）
warehouse_id VARCHAR(32), — 节点：FBA-US-WEST / 3PL-DE-01 / VIRTUAL-INTL-TRANSIT
owner_id VARCHAR(32), — 货主：公司主体或店铺主体
sku_id VARCHAR(64), — 内部统一SKU，禁止直接使用平台SKU
batch_no VARCHAR(32), — 批次，无则填 NA
stock_status VARCHAR(16), — AVAILABLE / RESERVED / OCCUPIED / INSPECTING / FROZEN / IN_TRANSIT / RETURN_PENDING / DEFECTIVE
qty_change INT, — 变动数量，入库为正、出库为负
ref_doc_no VARCHAR(64), — 来源单号：采购单/头程单/订单号/调拨单
operator_id VARCHAR(32), — 责任人
source_system VARCHAR(16) — ERP / PLATFORM_API / WMS / MANUAL
);
— 可售库存计算视图（口径必须唯一，禁止各处自行实现）
CREATE VIEW v_sellable_stock AS
SELECT
warehouse_id,
owner_id,
sku_id,
SUM(CASE WHEN stock_status IN ('AVAILABLE') THEN qty_change ELSE 0 END)
SUM(CASE WHEN stock_status IN ('RESERVED','OCCUPIED') THEN -qty_change ELSE 0 END)
COALESCE(safety_stock, 0)
+ SUM(CASE WHEN stock_status = 'IN_TRANSIT' AND is_committable = 1 THEN qty_change ELSE 0 END)
AS sellable_qty
FROM inv_ledger
GROUP BY warehouse_id, owner_id, sku_id;注意最后一行：在途库存不是全部都能算进可售。只有"可承诺在途"（交期确定、清关风险可控）才能计入，否则你会用一批还在海上的货去承诺明天的订单。
前三层做扎实之后，策略层才有意义。补货建议至少按"国家 + 平台 + 仓库 + SKU"分层，输入包括历史销量、销量波动、供应商交期、头程周期、MOQ、装箱数、断货成本。
我的经验是：前三个月不要追求全自动，跑"系统建议 + 人工校准"的双轨制，每次人工调整都记录原因，这些原因就是后续优化算法的标签数据。
讲完方法论，需要一个具体的参照物。我以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）作为观察样本，原因有两个：一是它面向的正是多平台、多仓、多主体的跨境卖家场景，二是它的功能主线与上面四层模型能对应上，便于把抽象方法论落到具体字段和流程上。
需要先声明：以下内容来自我对该产品公开信息的整理与实际使用观察，具体字段、接口能力、实施周期和费用请以官方文档与实际试用为准；文中涉及的数据均为脱敏后的项目观察或情景推演，不代表该产品的官方性能承诺。
跨境卖家最常见的主数据问题是平台 SKU 泛滥。数跨境这类系统的基本做法，是建立内部商品主档，再把 Amazon、TikTok Shop、Shopee、Temu、独立站等渠道 SKU 挂到同一个内部商品下。
这里有个容易被忽略的细节：组合装的处理方式，决定了大促期间会不会算错库存。如果系统支持组合装 BOM 拆解，卖出 1 个组合装就扣减对应的组件库存；如果不支持，运营往往单独给组合装建一个 SKU，结果组件和组合装互相不知道对方的存在。
我观察到的关键点是，系统需要把可售库存的计算口径收口到一处，而不是让运营、仓库、财务各写一套 Excel。数跨境在库存模块里的主线，是把多平台、多仓库存汇总到统一视图，并区分在途、可用、占用等状态。
对于选型中的团队，我建议你在试用时直接问三个问题，答案比任何功能清单都重要：
第三个问题尤其关键。多数系统的处理方式是"以最后一次同步为准"，这在大促期间会出现平台显示有货、仓库发不出的情况。更好的做法是把冲突暴露成异常单，让人来处理，而不是默默覆盖。
我见过太多团队卡在"知道有差异，但不知道为什么"。原因不是数据不够，而是差异没有被结构化。正确的做法是每一次盘点差异都必须落到一个原因码上：收货短装、拣货错发、退货未入库、调拨未回传、系统同步丢失、盗损。
当一个团队积累了三个月的原因码分布，库存管理的改进方向就自动浮现了。这比任何"库存改善方案"都管用。
库存管理不是仓储部门的自娱自乐。跨境场景下，头程运费、关税、海外仓仓储费、平台佣金、退货处理成本都要分摊到 SKU 上，才能算出真实毛利。这也是我在观察数跨境时比较关注的一点，它把采购、头程、仓储、平台费用与利润分析串在同一条链路上。
逻辑很简单：如果库存数据不能支撑"这个 SKU 到底赚不赚钱"的判断，那它只是仓库的记账工具，不是供应链协同工具。
下面这张表来自我参与过一次的多平台卖家库存协同梳理，规模是 6 个平台、3 个海外仓、约 4200 个在售 SKU。数据已脱敏，仅保留结构与量级。
| 阶段 | 时间 | 关键动作 | 观察到的变化 |
|---|---|---|---|
| 第 0 期 | 第 1，2 周 | 字段盘点、SKU 归一、仓库节点梳理 | 发现重复 SKU 约 380 个，占总数 9% |
| 第 1 期 | 第 3，6 周 | 库存初始化、可售口径定义、多平台同步打通 | 库存准确率从 76% 升至 88% |
| 第 2 期 | 第 7，12 周 | 退货、在途、不良品三个虚拟仓上线 | 超卖率从 3.2% 降至 0.9% |
| 第 3 期 | 第 13，20 周 | 补货建议双轨制、调拨建议 | 库存周转天数从 96 天降至约 78 天 |
| 第 4 期 | 第 21，30 周 | 异常闭环、原因码体系、指标看板 | 月度对账人工耗时从 46 人时降至 14 人时 |
方法论如果不能用在不同规模的团队上，就是空话。我把常见情形分成四类，每类给出明确的起点和优先级。
这个阶段的团队最容易犯的错是"过早追求精细化"。我的建议是：不要做批次和效期管理，不要做复杂的分仓策略，先把三件事做对。
这个阶段用 Excel 也能跑，用数跨境这类轻量系统也能跑，关键不在工具，在于规则是否被写下来。规则写在文档里的团队，一年后扩张时几乎不需要推倒重来。
这是最普遍也最棘手的一类。我的判断是：不要再换系统，先做一次"库存差异归因审计"。
具体做法是连续两周，每天记录平台库存、ERP 库存、海外仓系统库存三个数字，记录差值并标注可能原因。两周之后，差异分布会自动告诉你问题在哪：如果 60% 的差异集中在退货环节，那问题根本不在 ERP。
这类团队的第二优先级是统一可售口径，第三优先级才是补货策略。倒过来做，投入产出比会非常差。
选型时不要从功能清单开始看，要从"我能不能回答这三个问题"开始：我的库存记账颗粒度是什么？我的可售口径是什么？我的库存事件有哪些？
带着这三个问题的答案去看产品，你会发现能顺畅回答的供应商少了一大半。同时建议用真实数据做一次 PoC，至少包含 200 个真实 SKU、2 个平台、2 个仓库，跑完整的收货，上架，销售，退货闭环。
这类团队的主要矛盾不是准确率，而是效率，不可能对一万个 SKU 做精细管理。建议采用 ABC 分层：A 类（前 20% 贡献 80% 销售额）做精细库存状态管理与分层补货，C 类只做粗颗粒度的可售与在途，容忍一定误差。
同时把滞销识别做成自动化规则，例如"连续 45 天无出库且库龄超过 120 天"自动进入清货池。清货动作越晚，跨境场景下的仓储费损失越大。
库存协同没有"最优方案"，只有"适配方案"。下面五组取舍，我建议每个团队在启动前明确表态，避免执行中反复摇摆。
我的判断标准是看两件事：你的业务模式是否足够特殊，以及你的技术团队是否有稳定的运维能力。
如果业务是标准的平台+海外仓模式，采购成熟系统的总成本几乎一定低于自研，因为跨境场景的最大成本不是开发，而是平台接口的持续维护。平台 API 变更、字段新增、限流调整，这些工作是长期的、琐碎的、不产生业务价值的。
只有当你的业务模式确实特殊（例如自建海外仓配一体化、多货主代运营），自研才有意义。但即便是自研，我仍然建议先采购一套成熟系统跑半年，把业务流程跑清楚再自研。
很多团队一上来就要求"实时同步"，但实时同步的代价是接口调用量、平台限流风险、系统稳定性压力，而且收益并不总是明显。
更务实的做法是分级：可售库存的变动（订单产生、出库、退货入库）采用高频增量同步；基础资料、价格等低频数据采用每日全量同步；在途数据按事件触发更新。这样既控制了成本，又保证了关键路径的及时性。
中心仓统管的优势是全局最优，能减少整体库存；劣势是响应慢，海外本地团队缺乏灵活性。区域自治反之。
我的经验是：决策权集中，执行权下放。库存调拨的规则由总部定义，日常执行中的异常处理交给本地仓库，但异常必须回传并计入统一看板。这样既不失控，也不僵化。
这是最不该有争议的一组。账实一致是前提，补货算法是结果。我见过太多团队在库存准确率只有 80% 的时候强行上补货算法，结果算法给出的建议比人工还离谱，团队从此对系统失去信任。
如果你现在只能做一件事，做账实一致。哪怕只是把退货入库的及时率从 60% 提升到 90%，对可售库存准确度的改善也远大于换一套算法。
批次管理、效期管理、序列号管理都会提升数据精度，但都会增加仓库作业动作。跨境场景下，海外仓的人工成本远高于国内，多一个扫码动作就是真金白银。
我的建议是：只对高价值、高合规要求、高退货率的品类启用精细管理；对低值走量品，接受一定误差。全面精细等于全面低效。
| 取舍组 | 倾向 A | 倾向 B | 我的判断标准 |
|---|---|---|---|
| 自研 vs 采购 | 业务模式特殊、有稳定技术团队 | 标准模式、无长期运维资源 | 看平台接口维护成本是否长期可承担 |
| 实时 vs 准实时 | 订单密集、履约时效要求高 | SKU 多、接口限流紧张 | 看关键路径是哪些数据在驱动决策 |
| 中心统管 vs 区域自治 | 多国多仓、库存共享需求强 | 本地响应速度优先 | 决策权集中、执行权下放 |
| 算法优先 vs 账实优先 | 库存准确率已稳定在 93% 以上 | 准确率低于 90% | 准确率不到 90%，一律先做账实 |
| 精度 vs 效率 | 高价值、高合规、高退货品类 | 低值走量品类 | 精细管理的成本是否低于它避免的损失 |
回到最初那个场景：运营说有断货风险、仓库说有 1800 件、财务说库存金额涨了 40%。这三句话之所以能同时成立，是因为这家公司从来没有一份被所有人共同承认的"库存事实"。
所以我最想留下的判断只有一句：库存管理不是从 ERP 模块开始，也不是从补货算法开始，而是从定义"什么库存、在哪里、归谁、什么状态、能不能卖"开始。ERP 的作用，是把这份定义固化下来、自动化执行、并让所有角色看到同一个版本。
如果你正在选型阶段，建议带着"库存颗粒度、可售口径、事件流覆盖"这三个问题去评估产品，并用真实数据跑一次小范围 PoC。像数跨境这类面向多平台多仓场景的系统，可以作为观察起点，官网是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ，具体能力仍以实际试用和官方文档为准。
没有行业统一标准，必须说明口径。我的建议口径是"账面可售数量与实盘可售数量的一致率"，多平台多仓团队做到 93% 以上可以支撑补货决策，做到 96% 以上可以考虑自动化。低于 90% 时不要上算法。
不能。超卖的根因通常是可售口径把退货待检和在途算进去了，或者平台预留未及时扣减。系统能提供状态字段，但口径定义必须由业务方决定。
看品类。食品、美妆、保健品、带电池的电子类通常需要；服饰、家居、普通配件通常不需要。不必要的精细管理，是跨境场景下最常见的隐性成本。
先看 SLA 约定。建议在合同中明确盘点频率、差异容忍度、责任划分和赔付规则，并把盘点结果回写到 ERP 的差异归因体系里，而不是停在邮件里。
库存协同这件事，本质上不是技术问题，而是"共同事实"的建立过程。它需要业务把语言说清楚，需要系统把事实固化下来，需要指标体系把结果反馈回去。这三件事的顺序，就是"库存管理从哪里开始"的答案。
我们公司做了三年跨境，亚马逊、独立站、TikTok Shop都有店，仓库从国内仓扩到美国海外仓，去年花了不少钱上了ERP，结果运营和仓库还是天天吵库存数对不上。我就想不通，到底是ERP没选对，还是我们一开始就搞错了方向？库存管理这件事，第一步究竟该从哪里下手？
第一步不是选ERP模块，也不是搭补货公式，而是把库存主数据统一。具体要做三件事：第一，把SKU、组合装、条码、批次、效期、店铺、仓库、货主这几类主数据做一对一映射，确保同一个实物在所有系统里只有一个身份；第二，清理一物多码和多物一码的历史遗留，组合装要明确在哪个环节拆分、拆分后子SKU如何回写库存；
第三，指定一个主数据负责人和变更流程。判断依据很简单：如果同一个SKU在平台后台、ERP、海外仓系统里的编码或名称不一致，后面所有的库存同步和补货计算都是空中楼阁。先把这一步做完，再谈系统功能。
我之前一直以为仓库里有多少货，可售库存就是多少。结果有次大促，ERP显示还有两千多件可售，实际海外仓只有一千出头，超卖之后被平台罚了。我问运营，运营说扣了预留和占用；我问仓库，仓库说货就在那。我就很困惑，可售库存到底该怎么算，为什么和实物差这么多？
可售库存不等于实物库存，它是在实物可用库存基础上做减法再加法的结果。通用公式框架是：可售库存 = 实物可用库存 – 平台预留/订单占用 – 安全库存 + 可承诺在途。实物可用库存要扣掉待检、冻结、不良品；平台预留和订单占用要去各平台后台或API取实时值；安全库存是你自己设的超卖缓冲；
可承诺在途只算那些交期确定、入仓时间可控的头程货。判断口径是否正确的标准是：拿一个具体SKU，把这几项拆开逐一对账，如果加起来对不上，说明某一项的定义或同步频率有问题。不同平台对预留和占用的规则不一样，必须以官方最新文档为准，不能一套逻辑套所有平台。
我们同时跑亚马逊FBA、独立站海外仓和国内一件代发，三个渠道的库存各管各的，经常出现FBA断货但海外仓压了一堆同款的情况。我想把库存打通，但不知道从哪一步开始，是先接API做同步，还是先理流程？感觉每一步都很急，又怕做错了返工。
建议按三个阶段推进，不要一上来就追求全打通。阶段一：账实一致加多平台同步，目标是让库存数可信。关键任务是把主数据清洗完、做一次全量库存初始化、接通各平台库存同步接口、建立盘点差异归因机制。阶段二：补货与调拨，目标是从看见库存到主动调度库存。
在库存数可信的前提下，加入补货建议、调拨建议、安全库存和在途管理。阶段三：异常闭环与指标看板，把超卖、缺货、滞销、退货异常、库存差异都做成有入口、有责任人、有结果的闭环。判断顺序是否合理的依据是：如果连当前库存数都不准，做补货建议只会放大错误。所以先账实一致，再同步，再补货，最后异常闭环。
我们财务和运营每个月开会都要吵库存指标。运营说周转很快，财务说库存金额压得高；运营说缺货率不高，仓库说经常发不出货。同一个公司，同一批货，指标能差出一倍。我就想知道，跨境电商库存协同到底该盯哪几个核心指标，口径怎么定才能让各部门说同一套语言？
建议先锁定六个核心指标，并且每个指标都要写清楚口径、责任人、更新频率。第一，可售天数，口径是可售库存除以日均销量，要注明用的是哪个平台的销量和哪个仓库的库存；第二，库存周转率，口径是销货成本除以平均库存金额，财务和运营必须用同一个库存金额来源；
第三，缺货率，口径是缺货SKU数或断货天数除以总SKU数或总天数，要明确是按SKU还是按订单；第四，超卖率，口径是超卖订单数除以总订单数，按平台分别统计；第五，库存准确率，口径是账实一致SKU数除以盘点SKU总数，要注明盘点范围和容差；
第六，滞销占比，口径是超过设定天数未动销的库存金额除以总库存金额。判断口径是否统一的标准是：财务和运营拿同一个SKU、同一个时间段，各自算一遍，结果应该一致。如果对不上，先查定义，再查数据源，最后才查计算逻辑。行业没有统一基准值，引用任何数据都必须注明来源和计算口径。
读者评论
文章点出的“仓库有货、运营断货”矛盾很真实，我司也遇到过。账号1800件里真正可售只有640件，根因确实是库存状态没拆分，而不是补货公式不行。先把可售、占用、预留、退货待检分开定义，比急着换ERP有用。
比较认同“先统一语言再上系统”的顺序。我们之前先上了系统，结果一物多码、组合装拆解不清，库存被拆成好几份，重复补货和滞销同时出现。回头看，字段盘点和内部SKU映射才是最该先做的活。
文章里那张问题归因图挺有说服力，补货算法只占22%，大多数团队还没走到算法那一步。财务和运营口径不一致也常见，同一批货两个金额，月底对账要花几十人时。建议先做库存口径词典，再谈自动化。