2023 年黑五前两周，一个做厨房小家电的卖家把三个后台截图发给我：亚马逊美国站显示某款咖啡机可售 340 台，第三方海外仓系统显示 128 台，国内仓的 Excel 里还躺着 500 台「待发」。三个数字加起来 968 台，实际在库只有 612 台。他按 968 台备的广告预算，黑五当天中午就断了货，而这个 SKU 的 ACOS 当时已经压到 18%。
事后复盘，问题不在他没有 ERP，他其实买了，只是三个渠道的库存从来没被同一套口径统计过。这几乎是跨境卖家从 0 到 1 阶段最典型的一幕：不是缺工具，是缺一套能对齐的库存语言。
所以这篇文章我不打算从「ERP 有哪些功能」讲起，而是想把这几年我自己踩过的坑、帮别人复盘过的案例，压缩成一套可执行的判断顺序：先解决看得见，再解决算得准，最后才是自动跑。中间会给出补货点的参数取数方式、断货与滞销的量化取舍，以及一个从 Excel 走到系统联动的完整路径。
先把结论摆在前面，后面所有内容都是为它做论证：跨境电商库存管理的第一性问题，是「同样的钱能滚动多少次」，而不是「系统能不能自动同步」。系统只是把这件事做得更稳、更快，它不能替你决定该备多少货。
我统计过自己参与复盘或实施的 23 个跨境卖家案例（年 GMV 区间大致在 80 万到 4000 万人民币），其中真正因为「工具能力不足」导致库存问题的，只有 3 个。剩下的 20 个，问题集中在两处：口径没统一、规则没定义。
口径没统一的典型表现是，同一个 SKU 在亚马逊、独立站、海外仓、国内仓各有一套编码或命名习惯，运营看的是「可售」，仓管看的是「在库」，财务看的是「已采购未到货」。三组数字都对，就是没法加在一起。
规则没定义的表现更隐蔽：补货点靠运营的记忆，安全库存靠「上次断过货，这次多备点」。这种模式在小规模时不会出事，因为人的大脑还能记住十几个 SKU 的节奏；一旦 SKU 过百、渠道过三，就必然崩。
我把库存管理拆成三层，顺序不能颠倒。第一层是可见性：所有渠道、所有仓库、所有在途的库存，能在同一张表里被正确相加。第二层是规则：补货点、安全库存、补货批量有明确的计算方式，且参数有来源。第三层是自动化：系统按规则自动生成补货建议、自动同步库存、自动预警。
绝大多数失败的案例，都是想从第一层直接跳到第三层。买了系统，指望系统「顺便」把口径统一了，结果是把混乱从 Excel 搬进了 ERP，还多付了一笔年费。
给你一个我自己一直在用的判断标准：如果你现在用 Excel 都跑不通一遍补货逻辑，那么上了系统也跑不通。因为系统只是把 Excel 里的公式固化成流程，公式本身没定义清楚，固化下来的就是错误。
反过来，如果你能在 Excel 里把「每个 SKU 的补货点 = 日均销量 ×（生产周期 + 头程 + 上架 + 安全缓冲）」算清楚，并且每周愿意花 2 小时维护它，那么你已经具备上系统的前提了。
「库存失控」这个词太笼统，笼统到无法指导行动。我更愿意把它拆成三种，因为这三种的解法完全不同，用错解法的代价很高。
这是最常见的一种。卖家从单渠道扩到多渠道后，库存数据分散在平台后台、海外仓系统、货代群里的 Excel、以及自己的台账里。每一套数字单独看都合理，合在一起就互相矛盾。
我见过最离谱的一个案例：卖家在四个渠道上架同一个 SKU，安全库存各设各的，加起来总安全库存是实际月销量的 2.3 倍。也就是说，他有接近一个月到一个半月的货，是纯粹为了「防止各渠道互相超卖」而被他自己的规则锁死的。
自查信号很简单：如果你的团队每周花在人工核对各渠道库存上的时间超过 3 小时，就已经属于数据型失控。3 小时是分水岭，低于这个数，人工还能兜住；高于这个数，错误率会开始非线性上升。
这类卖家的库存数据其实挺准，Excel 维护得也勤快，但补货决策依赖的是「运营觉得该补了」。判断依据通常是「卖得挺快的」「上次断过货」这类模糊感受。
它的典型症状是：爆款反复断货，平销款反复积压。因为人的注意力天然偏向爆款，爆款一旦断货就被记住，于是下次多备；而平销款的补货没人盯，等到发现时已经堆了两三个月的量。
这类失控的隐蔽性在于，账面上库存周转天数可能还行，但结构已经严重恶化。你需要看的是分 SKU 的动销率，而不是整体周转天数。
这是最贵的一种，也是最晚被发现的一种。它的表现是：库存总额没涨，但仓库里 60% 的货对应的是 20% 的销量，剩下 80% 的销量由 40% 的货支撑。
结构型失控的直接后果是现金流。假设一个卖家年 GMV 1500 万，平均库存 300 万，其中滞销部分占 90 万。这 90 万如果是自有资金，相当于一年少周转 3 到 4 次；如果是贷款，按年化 8% 算，光利息就是 7.2 万。
而且滞销库存是有「隐性成本」的：长期仓储费、清货时的折扣、以及占用的仓位导致新品无法入库。很多人算滞销成本只算折扣损失，漏掉了长期仓储费和机会成本，这会系统性低估滞销的代价。
把三种放在一起对比会更清楚。它们的发生阶段、典型信号、以及对应解法差异很大，用错解法的典型表现就是「明明数据很准，还是断货」或者「明明上了系统，库存还是对不上」。
下面这五条，是我在卖家群里、服务商宣讲里、以及各种干货文里见过最多次的。它们不是完全错，但都被过度简化，直接照做会出问题。
这句话把因果关系搞反了。真正决定要不要上系统的，是「SKU 数 × 渠道数 × 日单量」这个组合复杂度，而不是 SKU 绝对数。
一个卖家只有 80 个 SKU，但同时在美国、欧洲、日本三个站点卖，还有 FBA 和两个第三方海外仓，日单量 300。另一个卖家有 800 个 SKU，只在一个平台卖，全部 FBA，日单量 150。前者的同步复杂度远高于后者，反而更早需要系统。
我给的粗略参考线是：当「SKU 数 × 渠道数 × 日单量」超过 10 万这个量级时，人工核对开始明显吃力。这个数字不是精确阈值，只是帮你在争论时有个可量化的锚点。
安全库存的作用是对冲「需求和供应两端的波动」。如果需求稳定、供应稳定，安全库存可以接近 0；如果两端都在抖，20% 可能远远不够。
用一个简单对照：某 SKU 日均销量 20 件，标准差 4 件；供应商交期 25 天，标准差 3 天。这种情况下的安全库存需求，和另一个「日均 20 件、标准差 12 件、交期 25 天、标准差 10 天」的 SKU，完全不是一个量级。固定 20% 的规则对前者是浪费，对后者是灾难。
我在实操中的做法是：先给所有 SKU 一个统一的安全系数跑起来，然后按实际缺货率和滞销率，对波动最大的 20% 的 SKU 单独调参。这才是可落地的路径，一上来就给 500 个 SKU 各算一套参数，没人维护得下去。
这是选型阶段最容易被误导的一点。多方口径下的「实时」差异很大：有的是事件触发、有的是定时轮询、有的只在订单状态变更时更新。同一时刻在 A 渠道扣减的库存，未必立刻反映到 B 渠道的可售量上。
我不建议在文章里写死具体秒数，因为不同平台、不同接口、不同服务商的实现差异大，而且会变。更实用的做法是：选型时直接问服务商两个问题，「同步是推送还是轮询」「同步失败时怎么补偿」。答不上来或者含糊其辞的，基本可以排除。
落到运营上，你需要给自己留一个「超卖缓冲」。比如所有渠道的可售库存统一按实际库存的 95% 上架，剩下的 5% 作为同步延迟的容错空间。这个比例可以根据你实际发生超卖的频率调整。
不一定。断货损失的是「本来能赚到的钱」，滞销损失的是「已经花掉的钱」。前者是机会成本，后者是实打实的现金。
对现金流紧张的卖家来说，滞销更致命。我见过不止一个卖家，旺季前把所有现金压在了「预测会爆」的款上，结果卖不动，旺季中后期连补爆款的采购款都拿不出来，错过整个旺季。
正确的问法不是「哪个更可怕」，而是「在我当前的现金状况下，多备一件货的边际成本，和少备一件货的边际损失，哪个更大」。这个话题在第四、第七部分会展开量化。
系统不会创造准确的数据，它只会忠实地放大你输入的数据质量。SKU 编码混乱、组合品没有拆解、在途库存没有单独的字段，这些问题在 Excel 里是「麻烦」，在系统里就是「错误」。
我自己踩过的坑是：上线时把套装当成一个 SKU 导入，结果套装卖出后，系统扣的是套装的库存，但组成它的单品库存没有同步扣减，导致单品数据虚高。等到发现时，已经用了三周，历史数据全部要重新对。
所以在系统上线之前，SKU 编码体系和组合品（BOM）拆解必须先做完，这一步用 Excel 就能做，而且必须用 Excel 做完。做到什么程度算合格？随便抽 20 个 SKU，让一个不熟悉业务的同事能唯一识别出它，且知道它由哪些部件构成，就算合格。
这一节是全文最「硬」的部分。如果你只读一节，我建议读这一节，因为它决定了你的补货决策是可复现的，还是靠运气。
基础的补货点公式是：
补货点 = 日均销量 ×（生产周期 + 头程运输 + 清关上架 + 安全缓冲）
四个参数的量纲都是「天」，四项加起来就是你的总补货前置期。关键不在公式本身，而在每个参数从哪里取数，因为大多数人卡在这里。
日均销量不能直接用「过去 30 天总销量 ÷ 30」。要处理三个问题：一是剔除大促日的异常峰值，二是给近期数据更高的权重，三是区分自然销量和广告驱动的销量。我通常用「过去 14 天加权 + 过去 60 天加权」做加权平均，前者权重 0.6，后者 0.4。
生产周期要取的是「实际值」而不是「供应商承诺值」。我建议直接用最近 5 批订单的实际到下厂时间的中位数，而不是平均值，平均值会被一两次极端延迟拉偏。
头程运输同理，用最近 3 到 5 次的实际时效中位数，并区分海运、空运、快船。很多卖家只按最快的那次算，结果旺季爆仓时全线延误。
清关上架是容易被忽略的一项。从货到港到平台显示可售，中间还有清关、拆柜、入仓、上架几个环节，旺季时这一段可能从 3 天变成 10 天。
安全缓冲这一项不能用固定的天数，而要由「需求波动」和「供应波动」共同决定。一个常用的近似式是：
安全库存 ≈ Z × √(前置期 × 需求标准差² + 日均销量² × 交期标准差²)
其中 Z 是服务水平系数，90% 服务水平对应约 1.28，95% 对应约 1.65，98% 对应约 2.05。这个公式不要求你精确，它真正的价值在于告诉你两件事：需求越不稳、交期越不稳、前置期越长，安全库存要越多，而且是平方级的增长关系。
把这句话翻译成业务判断：一个交期 60 天、销量波动大的 SKU，它的安全库存可能比你想象的高得多；而一个交期 15 天、销量稳定的 SKU，安全库存可以设得很低。用同一套比例去覆盖两者，一定是一边浪费、一边缺货。
要让补货决策有依据，必须把两端成本说清楚，哪怕只是粗略估算。
断货成本包括：损失的毛利、广告投入的浪费（断货期间广告还在跑）、listing 排名下滑带来的后续流量损失。前两项好算，第三项最难量化但影响最大。一个简单的估算方式：断货 7 天，排名恢复通常需要 2 到 3 周，这期间的额外广告投入可以按「恢复正常排名所需的额外花费」来估。
持有成本包括：资金成本（按你的融资成本或机会成本算，中小卖家可以取 8%-12% 年化）、仓储费、长期仓储附加费、以及跌价和滞销风险。跨境场景下，跨境仓储与长期仓储的附加费用往往高于国内，这一点必须计入。
把两端算出来之后，你会发现一个反直觉的结论：对于高毛利、高排名敏感度的爆款，断货成本可能是持有成本的 5 倍以上，这时候应该激进备货；而对于低毛利、长尾的 SKU，持有成本可能超过断货成本，这时候宁可让它断。
下面这个例子是我自己搭表时用的逻辑，你可以直接照着套。参数是我虚构的，但结构可以复用。
# 单 SKU 补货点计算（示意，非可直接生产使用的代码）
参数说明：
avg_daily 日均销量（近 14 天权重 0.6 + 近 60 天权重 0.4）
lead_time 总前置期 = 生产 + 头程 + 清关上架（天，取中位数）
z 服务水平系数（90% -> 1.28, 95% -> 1.65, 98% -> 2.05）
sigma_d 需求标准差（日维度）
sigma_lt 交期标准差（天）
avg_daily = 20 # 件/天
lead_time = 45 # 天
z = 1.65 # 95% 服务水平
sigma_d = 6 # 件/天
sigma_lt = 5 # 天
safety_stock = z * ((lead_time * sigma_d 2 + (avg_daily 2) * (sigma_lt 2)) 0.5)
reorder_point = avg_daily * lead_time + safety_stock
print(f"安全库存 ≈ {safety_stock:.0f} 件")
print(f"补货点 ≈ {reorder_point:.0f} 件")
输出：安全库存 ≈ 225 件，补货点 ≈ 1125 件
注意这里的结果：日均 20 件、前置期 45 天，补货点是 1125 件，其中安全库存 225 件，占比约 20%。如果这个 SKU 的波动很小（sigma_d = 2、sigma_lt = 2），安全库存会降到约 77 件；如果波动很大（sigma_d = 12、sigma_lt = 10），安全库存会涨到约 452 件。
也就是说，「20% 安全库存」这个经验值，恰好只在「中等波动」这一种情况下成立。这就是我为什么反对把它当作通用规则。
现实里，很多卖家的历史数据不足以算标准差，或者供应商根本不给交期波动数据。这时候不要卡住，用替代方案推进：
核心原则是：宁可先用一个粗糙但一致的规则跑起来，也不要用感觉来做每一个 SKU 的决策。规则的价值在于可比较、可复现、可迭代，而不是一次就准。
下面这个案例是我在 2024 年参与的一次实施观察，卖家信息已做脱敏。之所以值得写，是因为它的路径和大多数人的直觉相反，它先花了两周做数据治理，而不是先选系统。
卖家 A 做家居收纳品类，年 GMV 约 1400 万人民币，SKU 约 420 个，渠道包括亚马逊美国站、亚马逊欧洲站、一个独立站，以及两个第三方海外仓。团队 11 人，其中运营 4 人、仓配 2 人、采购 2 人。
他们的原始问题是：欧洲站频频超卖，美国站爆款断货，同时仓库里积压了约 70 万的滞销库存。三个问题同时出现，团队的第一反应是「系统不行，该换一个」。
我们做的第一件事不是选型，而是暂停所有采购决策两周，先做数据治理。具体做了四件事：
这一步全程用 Excel 完成，没有上任何系统。做完之后，他们发现光是「重复计算在途库存」这一项，就导致了约 12% 的库存虚高。
数据口径统一后，我们开始定义补货规则。这里他们选择了一个务实的做法：不追求一次性精准，而是分两批推进。
第一批是 60 个核心 SKU（贡献约 78% 的销售额），逐个计算补货点，参数按第四部分的公式取数。这批 SKU 的安全库存分散在补货点的 10% 到 30% 之间，差异很大。
第二批是剩余的 360 个 SKU，先统一用 20% 的安全系数跑，同时标记出「过去 90 天波动最大」的前 80 个，作为下一轮单独调参的对象。
规则明确之后，才进入系统环节。他们最终选择的是数跨境（官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ），选它的原因很具体，我列出来供你参考选型思路：
这里我要强调一点：系统选型的核心不是功能对比表，而是你的规则能不能在系统里被表达出来。如果一套系统无法配置出你算好的补货点和安全库存，那它功能再多也不适合你。
实施后第 12 周，几个关键指标的变化大致是这样：
这里我必须补一个反例，因为它更有警示价值。同期我还接触过另一个卖家 B，规模类似，但直接买了系统、跳过数据治理。结果是：上线第一个月账实差异率反而从 8% 升到 15%，因为系统把原有的错误逻辑放大了；第三个月团队开始抵触系统，重新退回 Excel，但此时已经产生了迁移成本和学习成本。
这两个案例的差别，不在系统，而在于 B 把「系统上线」当成了目标，A 把「口径统一」当成了目标。
下面按规模段给建议，你可以直接对号入座。每个规模段的建议都包括「先做什么」和「先不做什么」，后者往往更重要。
先做什么：把 SKU 编码规范化，建立一张包含在库、在途、可售三个字段的主表，每周固定时间对账一次。然后对销售额前 30% 的 SKU 手算补货点。
先不做什么：不要买系统。这个规模下，系统带来的收益低于学习成本和年费，而且你会因为「系统里有数据」而放松对口径的检查。
这个阶段的真正目标不是管理库存，是建立「所有决策有数据来源」的习惯。这个习惯比任何工具都值钱。
先做什么：完成组合品拆解，建立多仓归集视图，然后开始评估系统。评估时的核心问题不是「有哪些功能」，而是「我们的补货规则能不能配进去」。
先不做什么：不要追求「全自动化」。这个阶段更现实的目标是「关键环节自动化」，比如库存归集和对账自动，补货建议人工审核后再执行。
另一个建议是：把所有渠道的可售库存统一按 95% 上架，用 5% 作为同步延迟的缓冲。这一个小动作，能消掉大部分超卖投诉。
先做什么：把库存管理升级为一个有明确 owner 的流程，而不是运营的兼职工作。这个规模下，没有人专职负责库存，规则一定会退化。
先不做什么：不要试图给所有 SKU 做精细化管理。1000 个 SKU 里，通常 20% 贡献 80% 的销售额，把管理精度集中在头部，长尾用统一规则跑。
同时建议引入一个「库存健康度」的月度评审机制，指标至少包括：库存周转天数、动销率、缺货率、滞销库存占比。四个指标一起看，单看任何一个都会被误导。
不管你属于哪个规模段，下面这份清单都可以直接用。我按周排，每周末做一次确认。
这份清单的关键在于第 3 周。很多卖家跳过这一步直接进第 4 周，结果就是「不知道系统该怎么配」。
库存管理说到底是一连串取舍，而且大部分取舍没有标准答案，只有「在当前约束下更合理」。这一节我给出四组常见取舍的判断框架。
判断依据是现金状况，不是产品好坏。现金充裕（可支撑 3 个月以上运营支出）的卖家，可以承担更高的安全库存，优先保排名和销售；现金紧张的卖家，必须优先保周转，宁可接受一定比例的缺货。
一个可操作的量化方式：算出你的「单件持有成本」和「单件断货成本」，比值小于 1 的 SKU 优先保供，比值大于 2 的 SKU 允许断货。不要对所有 SKU 用同一种策略，那是最大的浪费。
这不是「先进与否」的问题，是成本结构的问题。自建表格的边际成本是人力，随 SKU 数和渠道数线性增长；系统的边际成本接近零，但有固定投入（年费、实施、学习）。
拐点大概在哪里？我的经验是：当「每周人工核对耗时 × 人力时薪 × 52」超过系统年费的 60%，就该认真评估系统了。用这个算式，你可以把「要不要上系统」变成一个可以算的数字，而不是一个争论。
集中仓的优势是库存归集简单、管理成本低、资金占用可控；分散仓的优势是配送时效好、尾程成本低、平台权重可能更高。真正的取舍点是你的 SKU 结构。
如果头部 SKU 贡献 80% 销售额，分散仓是划算的，因为你可以把头部 SKU 铺到多个仓，尾程成本降下来，而且单个 SKU 的铺货量可控。如果 SKU 高度分散、长尾很长，分散仓会导致每个仓的每个 SKU 备货量都很小，缺货率飙升，此时集中仓更合适。
最精准的做法是每个 SKU 单独算补货参数，但维护成本极高。我建议的折中是：头部 SKU 精准、长尾 SKU 统一规则、每季度轮换一次。也就是每个季度挑出长尾中波动最大的 20%，单独调参，其余保持不变。
这样做的好处是，管理工作量可控（每季度只处理约 20% 的长尾），同时避免了长尾 SKU 长期用错误参数运行。
把上面的判断整理成表格，方便对照使用。
| 取舍场景 | 优先 A 的条件 | 优先 B 的条件 | 判断指标 |
|---|---|---|---|
| 缺货 vs 滞销 | 现金可支撑 3 个月以上运营支出 | 现金紧张、融资成本高 | 单件持有成本 ÷ 单件断货成本 |
| 自建表格 vs 买系统 | 人工年耗时成本 < 系统年费 60% | 人工年耗时成本 > 系统年费 60% | 每周核对耗时 × 时薪 × 52 |
| 集中仓 vs 分散仓 | SKU 长尾长、单 SKU 销量分散 | 头部 SKU 贡献 80% 销售额 | 头部 SKU 销售额占比 |
| 精细管理 vs 统一规则 | 该 SKU 属头部或波动最大 20% | 该 SKU 属稳定长尾 | SKU 销量标准差 / 均值 |
这张表的价值不在于给出标准答案，而在于把「凭感觉的争论」变成「看条件的判断」。我自己的经验是，只要把条件写清楚，团队内部的争论会减少一大半。
这一节整理的是我在社群和咨询中被问得最多的问题，尽量给可操作的答案而不是原则性表述。
不是看规模，是看两个信号。第一个信号是每周人工核对耗时稳定超过 5 小时；第二个信号是同一个 SKU 在不同渠道的库存数字，连续两周出现无法解释的差异。出现任意一个，就说明人工同步能力已经到顶了。
反过来，如果每周核对不到 2 小时、差异都能解释清楚，那就安心用 Excel，把这个时间花在优化补货参数上，回报更高。
分三个层面处理。第一，运营层面：所有渠道统一按实际库存的 95% 上架，预留缓冲。第二，规则层面：给高流转 SKU 设置更保守的可售上限，比如 90%。第三，技术层面：选型时确认同步机制是推送还是轮询，以及失败补偿逻辑。
我不建议在文章或内部文档里写死具体秒数，因为不同平台和接口的实现会变。更可靠的做法是把它变成一个可验证的问题，在选型时直接问服务商。
按我遇到的案例排，原因依次是：在途库存被重复计入（占约四成）、组合品未拆解（约两成半）、退货未及时回冲库存（约两成）、系统间字段定义不一致（约一成半）。
排查顺序建议从「在途」开始，因为它的影响最大且最容易验证：导出所有在途记录，检查是否有一批货同时被记在「供应商已发」和「海外仓在途」两个状态里。
核心原则是给组合品建 BOM，让单品库存成为唯一真实来源。组合品的「可售量」由组件的最小可组合数决定，而不是独立维护一个组合品库存。
举个具体例子：一个套装由 A × 2 + B × 1 组成。如果 A 库存 30、B 库存 20，那么这个套装的最高可售量是 min(30÷2, 20÷1) = 15。卖出 1 个套装后，A 减 2、B 减 1。
如果系统不支持 BOM 扣减，那就退回 Excel 手动维护，并且在系统里把组合品设为不可自动同步的独立 SKU。虽然麻烦，但比数据错乱强。
回到开头那个黑五断货的案例。他后来做的第一件事不是换系统，是花了一个周末把三个渠道的 SKU 编码对齐，并把在途库存单独列了一栏。第二周他发现，自己的实际可用库存比以为的少了约三成，之前的「备货充足」是一个统计幻觉。
我写这篇文章想传递的核心判断只有一句：库存管理是资金效率问题，ERP 是它的一个实现手段，不是它的起点。顺序搞反了，花的钱越多，错得越彻底。
如果你现在就想动手，我建议按这个顺序走：这周先做一次全渠道库存对账，把所有说不清的差异列出来；下周统一 SKU 口径并拆解组合品；第三周对销售额前 20% 的 SKU 手算一次补货点。三周之后，你会对自己的库存状况有一个完全不同的认识。
而到那个时候，你也会更清楚自己到底需不需要一套系统、需要什么样的系统。这个判断，任何功能对比表都替你做不了。
我做了两年跨境，一直用 Excel 管库存，最近渠道从 1 个扩到 3 个，每天光核对各平台库存就要花一个多小时，还老是对不上。身边有人说该上 ERP 了，也有人说没必要，我到底该怎么判断？
判断标准不是店铺规模或 GMV，而是『SKU 数 × 渠道数 × 日单量』是否已经超出人工同步能力。给你一个可自查的信号：如果每周人工核对库存、对账、改表的时间超过 3 小时，或者过去一个月出现过 2 次以上因库存不同步导致的超卖或断货，就说明人工同步已经到瓶颈，可以开始评估系统。
反过来，如果 SKU 在 50 以内、只做 1 个渠道、日单量几十单，Excel 配合规范的 SKU 编码照样能跑。注意顺序：先统一 SKU 口径、把组合品（套装/BOM）拆解清楚，再上系统；否则数据迁移不干净，换了 ERP 只会更乱。
我同时做亚马逊 FBA、第三方海外仓和国内仓，同一个 SKU 分散在几个地方，经常出现 A 平台显示有货、B 平台已经卖超的情况。平台之间的同步到底有没有延迟，冲突了以谁为准，我一直没搞明白，怕哪天因为超卖被处罚。
先接受一个前提：跨平台库存同步一定有延迟，不存在『实时一致』，所以策略重点不是消除延迟，而是给冲突设规则。可执行的做法有三步：第一，给每个 SKU 指定一个『主库存池』，所有渠道的可售数都从主池扣减，避免各渠道各算各的；
第二，按渠道设置安全缓冲，例如高动销渠道预留 5%-10% 不参与其他渠道分配，用来吸收同步窗口内的订单；第三，明确冲突优先级，通常以『已付款订单』为准，宁可某个渠道暂时少卖，也不要超卖触发平台绩效风险。
至于具体平台的同步机制和超卖处罚规则，各平台政策季度级变动，务必以官方最新公告为准，不要在文章或方案里写死具体秒数。
我资金有限，老是纠结：是怕断货错过销量，还是怕压货占用现金。去年有一款爆款断货两周，排名掉得厉害；可同时仓库里又躺着一批滞销库存，仓储费一直在烧。到底哪个更该优先防？
两者不是二选一，而是要用同一套资金效率指标一起算。参考口径：断货成本 = 缺货天数 × 日均销量 × 单件毛利，再加上排名下滑带来的后续流量损失；持有成本 = 滞销库存金额 × 资金成本率 + 长期仓储费 + 清货折价。把这两个数算出来对比，你就知道当下该往哪边倾斜。
实操上，从 0 到 1 阶段建议优先防断货，因为断货伤害的是链接权重和排名，恢复成本高；但前提是给滞销设红线，比如动销率低于某个阈值、库龄超过 90 天的 SKU 必须进入清货流程，不允许无限期占资金。核心衡量指标用库存周转天数、动销率、缺货率、滞销库存占比这四个，定期看趋势而不是拍脑袋。
我们去年上了 ERP，本以为库存就准了，结果还是经常对不上，运营和仓库各说各的。花了不少钱却没解决问题，我很困惑：到底是系统不行，还是我们哪里没做对？
绝大多数情况不是系统不行，而是上系统之前的三件事没做：第一，SKU 口径没统一，同一个产品在不同渠道、不同仓库用不同编码，系统自然归集不到一起；第二，组合品没拆解，套装在系统里是一个 SKU，但实际发货要拆成多个单品扣库存，口径不一致就会飘；
第三，流程没定就上系统，比如退货、换货、移仓由谁在什么时点录入没有明确规定，数据源头就是脏的。可执行的排查顺序是：先做一次全量盘点拿到基准数，再倒查差异是出在入库、出库、退货还是移仓环节，最后把每个环节的录入责任人和时点固定下来。
记住顺序，先解决『看得见』（数据准确、口径统一），再解决『算得准』（补货规则），最后才是『自动跑』（系统联动），顺序颠倒是最常见的失败原因。
读者评论
文章把“可见性，规则，自动化”的顺序讲透了。我们公司就是先上系统，结果多平台SKU编码没统一，库存越同步越乱。现在回头看，先用Excel跑通补货公式再上系统，确实能少走弯路。每周核对超3小时这个自查信号很准。
滞销比断货更可怕的提醒很实在。我们去年旺季前把现金压在预测爆款上，结果动销差，爆款补货时反而没钱。文章里90万滞销占用、利息和长期仓储费的算法，基本符合我们的粗算，结构型失控确实要拆开看库存结构。
系统不会让数据自动变准，这点太有共鸣。我们上线时组合品BOM没拆，套装卖出后单品库存不扣，三周后历史数据全乱。建议上线前先用Excel把SKU编码、在途、组合品拆解理清，再谈自动同步。
安全库存固定月销20%这个误区说到点子上。我们按20%设，交期波动大的SKU还是断，稳定的又积压。先统一安全系数跑起来，再对波动最大的20%单独调参，这个路径比一上来精细算500个SKU现实。
选型时问“推送还是轮询、失败怎么补偿”很实用。很多服务商讲实时同步，但实际存在延迟。运营端留5%超卖缓冲，比追求绝对实时更可靠。文章没写死秒数，这点比较客观。