去年 11 月，我帮一家做家居品类的卖家做库存诊断。他们月销大概 180 万美元，ERP 上了两年，团队 6 个人，但每周还是要有 3 个人花整整两天时间，把亚马逊后台、独立站后台、两个海外仓的库存导出来，手工拼成一张 Excel，再跟 ERP 里的库存数对一遍。对的不是数量，是"为什么不一样"。我当时问了一句：你们的 ERP 里，"可售库存"这四个字到底是怎么定义的？会议室里安静了大概十秒，运营说按平台可售算，仓库说按实物在架算，财务说按已付款未出库扣减后的数算。
三个答案，三个口径。
这就是我今天想聊的问题。不是"跨境电商 ERP 有哪些功能"，而是标准化管理到底要覆盖哪些库存管理事项。因为功能是可以对着销售 PPT 一个个打勾的，但口径定义不了，勾打得再满，账还是对不上。下面这份清单，来自我这两年做过的十几家跨境卖家的库存诊断记录，也来自我自己动手拆解和测试过的一些 ERP、数据类工具。数据部分我会标明是样本观察还是情景推演，你可以按自己的业务去验证。
如果只能记一句话，我希望是这句：跨境库存管理的标准化，本质不是把功能堆满，而是把"同一个东西、同一种状态、同一件事、谁负责、怎么算"这五件事统一掉。我把它叫做"五统一"。功能是"五统一"落地之后的结果，不是起点。
为什么我要把结论放这么前？因为我在诊断里见过太多反过来的做法：先买系统，再上功能，最后发现每个功能都在按自己的逻辑算数。库存模块算一个数，采购模块算一个数，财务模块再算一个数，三个数都"对"，但合不起来。
统一主数据，是指 SKU、条码、仓位、店铺、站点、供应商、物流商这些基础对象，在系统里只有一套编码和一套属性，不允许各模块各写各的。
统一库存状态，是指库存不是"一个数字"，而是一组状态：在途、待检、可售、锁定、占用、不良、退货在途、待处理、报废。每个状态之间怎么流转、由谁触发、多久更新，必须写死。
统一业务事件，是指采购、入库、上架、调拨、订单占用、出库、退货入库、盘点、手工调整，每一个动作都要对应一个明确的事件记录，而不是某个人直接改数字。
统一责任边界，是指运营改什么、采购改什么、仓库改什么、财务改什么、谁能绕过流程，必须写清楚。这条最容易被忽略，但它决定了系统上线三个月后会不会退化回 Excel。
统一报表口径，是指库存、周转、缺货、滞销、成本、对账这些报表，分子分母怎么定义、统计时点怎么取、跨币种怎么折，必须在一份文档里定死。
第一张是库存状态清单，解决"这个数到底代表什么"。第二张是业务事件清单，解决"这个数是被谁、被哪个动作改的"。第三张是验收问题清单，解决"我怎么知道候选 ERP 真的能做到"。
很多人只做第三张，拿着一张功能对照表去问供应商"你们支持不支持多仓"。供应商说支持，然后就没有然后了。因为"支持多仓"和"支持你的多仓业务"之间，隔着状态定义、异常处理和财务口径三道沟。
我给客户做初筛时，通常只问三个问题：能不能在不导出数据的前提下，回答"某个 SKU 当前在哪个仓、什么状态、值多少钱"；能不能解释清楚"这个数字和昨天不一样，是因为哪一笔业务事件"；能不能在不写代码的情况下，把库存和已出库成本对上。三个都能答，基本盘就稳；答不上任何一个，后面的功能清单基本都是空谈。
先把情绪性的说法放一边。跨境库存失控，主要是四个结构性原因造成的，跟团队水平关系不大。
国内电商的典型情况是，一个 SKU 主要在一个平台卖，库存池相对单一。跨境不一样：同一个 SKU 可能在亚马逊美国站、亚马逊欧洲站、独立站、TikTok Shop 同时上架，每个平台还有自己的库存规则。
这里有个特别容易踩的坑：平台库存和实物库存不是一回事。亚马逊后台显示的可售数量，和你在海外仓实际有多少货，中间隔着"正在入仓""已被预留""正在移除"这些中间态。运营看到平台可售是 200，仓库看到货架上是 180，两个人都是对的，但拼不到一起。
我遇到过一个真实的超卖事故：卖家在会员日前把库存按平台可售数量做了补货决策，结果其中 60 件正处在 FBA 移除过程中，系统里既不算在库也不算可售，硬生生少算了 60 件，会员日当天断了货。
国内电商的货基本在自有仓，货在哪、账在哪，基本一致。跨境的货，可能同时存在于：国内仓待发、头程海运在途、目的国清关暂存、海外仓在架、FBA 在途中、FBA 在库、FBA 移除在途、退货在途。
这些位置里，只有一部分是"看得见摸得着"的。剩下的全靠单据和数据流转。单据不完整、状态不明确，账就会在这些缝隙里漏掉。
平台 API 的同步是有延迟的，不同平台延迟不同；海外仓的库存更新可能是准实时的，也可能是每天定时同步；财务结算周期又是另一个节奏。三个节奏叠在一起，就会出现"运营看到的是三小时前的数，财务看到的是上月结算后的数"。
这不是技术缺陷，是业务现实。标准化要做的不是消灭时间差，而是把时间差显性化，让每个人知道自己看到的数是哪个时点的。可惜很多 ERP 在界面上并不告诉你数据更新时间，只有一个数字放在那里。
库存最终要变成钱。采购成本、头程运费、仓储费、尾程派送费、平台佣金、VAT、关税，这些费用有的按件摊、有的按重量摊、有的按货值摊。汇率还在变。同一批货，采购说成本是 12 万，财务算完可能是 13.4 万，中间那 1.4 万就是各种没有明确分摊规则的费用。
我见过最典型的场景是：运营算出来某个 SKU 毛利 22%，财务算出来是 9%。不是因为谁算错了，是因为运营的成本里没含头程分摊和滞销跌价，财务的成本里含了。库存管理事项如果不覆盖到成本口径，库存数字再准也是半成品。
在给出具体的模块清单之前，我想先把几个高频误区说清楚。这几个误区不纠正，后面看得越细，方向越偏。
库存不准，很多老板的第一反应是仓库没管好。于是加人、加盘点频率、加罚款。效果通常有限，因为真正的原因在规则层面。
我做过一次归因：把某卖家一个月的库存差异逐笔拆开，发现超过六成的差异不是"盘错了"，而是"状态没定义清楚"。比如退货商品没有质检环节，直接按可售入库；比如头程到港后单据延迟三天才录入，这三天系统里一直是虚的。
判断方法很简单：如果同一个差异连续三个月重复出现，基本就不是执行问题，是规则问题。
实时同步解决的是"数据传得快不快"，超卖解决的是"多平台之间怎么分配有限的货"。这是两件事。
极端情况是这样的：两个平台同时来了订单，系统在 200 毫秒内把两个订单都写进了队列，然后发现库存只够一个。同步再快也拦不住，因为缺少的是分布式占用和缓冲库存机制。
所以我很少问供应商"同步是不是实时"，我更关心三件事：库存扣减是下单扣还是付款扣、失败重试期间库存是锁定还是释放、多个平台共享同一批货时缓冲值设在哪里。
这是选型时最常见的边界模糊。ERP 管的是"账"，WMS 管的是"活"。ERP 要知道某个 SKU 有多少货、值多少钱；WMS 要知道这批货在 A 区 3 号货架的哪个箱子里。
有些 ERP 自带轻量仓储功能，对于日单量几百、单仓运营的卖家够用；但一旦上到多仓、多批次、有保质期或者序列号管理，就必须考虑专业 WMS。强行用 ERP 做仓储执行，最后往往是既要人工核对，又失去了 WMS 的作业效率。
很多卖家觉得财务模块最能直接看到钱，优先上。但财务模块的准确性完全依赖库存和采购的数据质量。主数据没统一、状态没定义，财务模块算出来的成本就是一个精确的错误。
我的建议是反过来的顺序：先统一主数据和库存状态，再打通订单和库存，最后才是采购补货和财务核算。这条路径慢，但返工少。
前面说了五统一是什么，这一节说怎么落地。我的经验是，五件事不能并列推进，要有先后，而且每一件都有具体的产出物。
主数据的核心是 SKU 编码。我见过太多卖家的 SKU 是运营自己起的，今天叫 ABC-01，下个月叫 ABC01-new，同一个产品在系统里存在三条记录。这种状态下谈库存准确率没有意义。
落地动作分三步：先定编码规则（品类+规格+变体+版本），再定唯一性校验（系统层面禁止重复创建），最后做历史数据清洗（把重复的、废弃的标记出来）。
除了 SKU，还要统一仓位编码、店铺标识、站点标识、供应商编码、物流商编码。这些对象如果每个模块各写一套，后面所有报表都要重做。
我通常会要求客户在一张白纸上，把货物从下单采购到最终卖出的全过程画一遍，每一个可以停留的位置标一个状态。画完之后，你会发现状态数量远超过你原来的想象。
下面是一份相对完整的跨境库存状态定义，可以直接拿去对照你的系统：
关键在于，每个状态都要回答四个问题：谁可以触发进入、谁可以触发离开、进入/离开时是否影响可售库存、是否影响财务成本。
我的判断标准是：如果系统里任何一个库存数字变化，找不到一条对应的业务事件记录，这个系统就不具备标准化管理的基础。
事件清单至少要覆盖：采购下单、采购到货、质检、上架、订单创建、订单付款、订单审核、出库、发货确认、平台签收、退货申请、退货入库、质检分级、翻新换标、报废、调拨发起、调拨到货、盘点开启、盘点确认、手工调整。
其中手工调整是重点。不是不允许调整，而是调整必须带原因码、带审批、带留痕。我见过一个团队，手工调整的原因码只有"其他"一个选项，等于没有。
责任边界这件事，写下来和没写下来，差别巨大。下面这张表是我常用的一版，你可以按自己团队调整：
| 事项 | 主责 | 协同 | 常见冲突点 |
|---|---|---|---|
| 库存状态定义与调整 | 供应链 | 运营、财务 | 运营希望可售数越大越好，财务希望风险尽量暴露 |
| 多平台库存分配规则 | 运营 | 供应链 | 促销期间是否临时提高某平台缓冲值 |
| 采购在途录入与更新 | 采购 | 财务 | 到港但单据未到，是否先估录入账 |
| 头程费用分摊规则 | 财务 | 采购 | 按件摊还是按货值摊，不同品类结果差异大 |
| 退货质检与分级 | 仓储 | 运营、财务 | 降级标准不统一，运营认为还能卖，仓储认为只能报废 |
| 手工调整权限 | 供应链负责人 | 财务 | 大促期间是否开放临时权限 |
| 盘点点差异处理 | 仓储 | 财务、供应链 | 差异金额在什么范围内可免审批 |
库存周转率是最容易扯皮的指标。分子用出库成本还是销售额，分母用期初库存还是平均库存，按件算还是按金额算，跨币种怎么折，不同算法出来的结果可以差一倍。
我的建议是在系统里给每个核心指标做一页"口径卡"，写清楚：定义、公式、数据来源、统计时点、币种处理、更新频率、责任人。这张卡不写，报表就永远在开会时吵架。
这部分是清单主体。我给每个模块都配了"必须覆盖的事项"和"验收问题"，因为光知道要覆盖什么，不代表你会验证。
平台与站点的库存映射关系、共享库存池的划分规则、缓冲库存设置、同步频率与延迟容忍度、同步失败的重试与告警、负库存拦截、重复订单的幂等处理、平台侧手动改库存的回写。
我不建议把"实时同步"当成核心卖点来选型。真正决定防超卖效果的，是占用规则和缓冲机制，而不是同步速度。同步从 5 分钟变成 30 秒，对超卖率的改善通常远小于把下单扣减改成付款扣减。
状态定义与流转规则、订单占用时点（下单/付款/审核）、占用释放条件、部分发货处理、多包裹订单处理、换货场景、预订单和预售商品的库存处理。
我遇到过最麻烦的场景是"换货"。客户退了一个 A 商品，换了 B 商品发出。库存上，A 要回到可售或不良，B 要正常出库，财务上还涉及差额结算。如果系统不支持换货单据，运营就会用"退货单 + 新订单"来拼，导致库存数据里多出一笔莫名其妙的出入库。
采购单全流程、到货预约、头程在途跟踪、在途库存是否计入可用、安全库存、补货点、销售预测、MOQ（最小起订量）、供应商交期、平台仓的入仓限制。
补货这件事，我不建议完全交给系统自动跑。补货建议的价值在于提供一个基准线，而不是替代采购判断。好的做法是系统给出建议量，采购必须填写调整原因，系统记录这个偏离，半年后回看这些偏离是正的还是负的，用来校准模型。
国内仓、海外仓、FBA、第三方仓、虚拟仓的库存归属；调拨单全流程；头程、尾程的费用归集；FBA 移除、换标、贴标、重新入仓；跨仓库存的统一视图。
FBA 相关的政策、库存分类规则、移除费用标准，必须以亚马逊官方文档为准，且会随时间和站点变化。我不建议把任何第三方文章里的规则描述当成固定结论，包括我这篇。
入库、上架、拣货、复核、打包、出库、移库、循环盘点、全盘、批次管理、效期管理、序列号管理、库位管理。
我的经验分界线大约是：单仓、日单量 500 以下、无批次/效期管理需求，ERP 自带仓储功能基本够用；一旦出现多仓协同、批次效期、序列号追溯中的任意两项，就应该认真评估专业 WMS，而不是指望 ERP 硬扛。
退货申请、退货在途、退货入库、质检分级（可再售/降级/报废）、翻新换标、二次上架、平台退款关联、退货费用归集、退货率统计。
早期我建议一个客户把退货直接计入可售，理由是"大部分能再卖"。三个月后发现，退货商品的动销率明显低于正常库存，而且有几批商品因为外观问题反复被投诉。后来改成"退货必须质检后才能转可售"，短期内可售数下降了，但整体准确率和客诉率都改善了。库存数字好看，不等于库存数字有用。
采购成本、头程费用分摊、仓储费、尾程派送费、平台佣金、汇率处理、VAT 与关税、库存跌价准备、毛利核算、平台结算单与 ERP 差异处理。
成本核算方法、汇率规则、税务处理，都需要财务和税务专业人士根据企业实际情况确认，不能照搬任何一篇文章的做法，包括这篇。我这里给的是"要覆盖哪些事项"，不是"应该用哪种方法"。
缺货预警、滞销预警、超卖预警、负库存预警、库龄预警；库存周转率、动销率、库存天数、呆滞占比；权限粒度、操作日志、审批流、审计轨迹。
如果要在八大模块里选一个"性价比最高"的，我会选审计和权限。它不产生直接收益，但它决定了前面所有规则会不会在三个月内被绕过。我见过太多系统被架空，起点都是某个大促期间，负责人临时开放了所有人的修改权限，然后就再也没收回来。
前面提到的模块，很多 ERP 都能覆盖到"功能层面"。但我在实际诊断中发现，真正卡住大部分卖家的，是数据口径的统一，也就是第五个统一。功能都有，数对不上。
因为我发现一个规律：库存对不上的团队，问题很少出在"没有功能"，而是出在"每个功能背后是一套独立算出来的数"。ERP 里的库存报表算一套，平台后台算一套，财务系统算一套，海外仓对账单又是一套。四套数字摆在一张桌子上，谁都不肯说自己错。
解决这个问题，光靠 ERP 是有限的，因为 ERP 的数据以业务单据为核心，而跨平台、跨系统的口径统一，更依赖一层专门做数据整合和分析的能力。这也是我前段时间去研究数跨境的原因。
我按一个虚构但贴近真实的中型卖家场景做了测试：4 个亚马逊站点、1 个独立站、2 个海外仓、1 个国内仓，SKU 约 800 个，月订单量 3 万单左右。测试环境不是生产环境，所以下面说的是我观察到的"能力方向"，不是性能承诺。
我的观察是，它更偏向把不同平台、不同店铺、不同仓的库存数据归集到统一的分析口径下。这个能力的价值不在于展示，而在于你能用同一套口径去看"同一个 SKU 在所有渠道的总可售"，而不用人工把四张报表拼起来。
我把采购成本、头程费用、平台佣金这几项放进去，主要看的是它能不能把库存金额和已出库成本放在同一个分析框架里。这一步很关键，因为库存数字要变成决策依据，必须带上金额。
我设置了几类异常：某个 SKU 连续 7 天动销为零但库存大于 200、某个平台的库存同步连续失败、某个 SKU 的库存差异超过阈值。观察下来，这类基于数据规则的预警，比人盯报表更容易持续。
如果你也想自己验证，可以直接去看它的实际界面和数据接入列表，链接是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys。我建议带着自己真实的三个库存问题去看，而不是看演示。
这一点我必须强调，避免误导。数据分析和口径统一层，不替代 WMS 的作业执行，也不替代 ERP 的业务单据管理。它解决的是"数对不上"，不解决"货找不到"。
我的判断是，这类工具适合已经有一定数据量、正在被"多套口径"困扰的卖家，尤其是同时跑多平台多站点的团队。如果你是单平台、单仓、SKU 不到 100 个的起步阶段，优先把 ERP 的库存状态定义清楚，收益更大。
清单是通用的，但行动必须分情况。我按三个维度给建议：规模、模式、以及当前最痛的问题。
不要碰复杂方案。优先做三件事：把 SKU 编码规则定死、把"可售库存"这一件事的定义在团队内统一、把所有手工改库存的动作加上理由记录。这三件事不需要买新系统，但能解决大部分账实不符。
这是最需要补齐规则的阶段。重点做库存状态定义、责任边界文档、以及各平台库存分配规则。系统上，优先保证 ERP 的库存模块和订单模块打通，此时可以考虑引入数据层工具解决多平台口径问题。
这个阶段不要再指望单一系统解决全部问题。合理的架构是：ERP 管单据和账、WMS 管作业、数据层管口径和分析、财务系统管合规。四者之间的数据接口和字段映射，要有专人负责，并且文档化。
铺货型卖家的核心是 SKU 数量大、单 SKU 生命周期短，库存管理的重点应该放在快速清仓和滞销预警上，库存周转天数比准确率更关键。
精品型卖家的核心是单 SKU 备货深，重点应该放在补货节奏和断货防护上，因为一次断货可能直接掉排名。
品牌型卖家通常有线下和线上多渠道，重点应该放在全渠道库存的统一视图上，避免不同渠道之间互相抢货。
资源永远有限，所以取舍比清单更重要。我按"必须做、可以买、可以忍"三类来说。
库存状态定义、责任边界、成本分摊规则这三件事，必须由企业自己定。原因很简单：它们取决于你的业务模式、财务要求和团队结构，任何供应商都只能给模板，不能给答案。
我见过最糟糕的情况是，卖家直接把 ERP 供应商的默认状态定义当成自己的定义用了，运行一年后发现系统里的"在途"包含了三种完全不同的业务场景，报表怎么拆都拆不出来。
多平台数据同步、汇率获取、平台结算单解析、库存预警引擎，这些属于通用能力，自己开发成本极高且维护麻烦。尤其是平台接口，各平台会不定期调整，自研方案很容易在某个平台更新后失效。
选这类工具的判断标准，我更看重它对异常的处理能力，而不是它支持多少平台。支持 20 个平台但同步失败没有告警，不如支持 5 个平台但每次失败都能明确告诉你。
如果某个环节每月发生次数少于 20 次，且金额不大，用表格加人工处理往往比上系统划算。比如小规模的换标处理、偶发的跨境调拨。
我的经验门槛是：当一件事每月超过 50 次、或者涉及两个人以上协作、或者错一次的成本超过五位数，就该考虑系统化。低于这个门槛，先优化流程比先买工具更有效。
如果预算有限，我的建议顺序是：先把钱花在"减少损失"的地方（防超卖、断货预警），再花在"提高效率"的地方（自动化作业、报表自动化），最后花在"财务精细化"上。因为前者的投入产出比更容易被量化，也更容易拿到团队支持。
清单和取舍都清楚之后，剩下的是顺序问题。顺序错了，同样的事情会做两遍。
这个顺序的核心逻辑是：先保证数据的"真"，再保证数据的"快"，最后才追求数据的"全"。反过来做，往往在第三步就卡住，因为基础数据本身不可信。
为了应对大促，临时放开库存修改权限、临时忽略审批流。大促结束后，这些临时规则往往不会收回来。我的建议是：如果一定要破例，就在破例之前写清楚恢复时间和责任人，并在系统里设置自动失效。
系统上线那天所有人都在，一个月后没人管参数。补货参数、预警阈值、缓冲库存值，都是上线时设的，之后没变过。这些参数需要按季度复盘，尤其是季节性品类。
认为换了系统问题就解决了。实际上，我诊断过的项目里，有相当一部分的问题是"规则缺失"，换任何系统都会重现。工具能放大正确的规则，也能放大错误的规则。
上线三个月后，做一次盲测：随机抽 20 个 SKU，让运营、仓库、财务分别报出这个 SKU 当前的库存数量和金额，看三个答案是否一致。一致率高，说明标准化落地了；不一致的地方，逐个查是哪个环节的口径出了问题。
回到开头那家卖家。他们最后没有换 ERP，而是花了三周时间做了一件事：把库存状态从 5 种重新定义为 11 种，并给每一种状态配了责任人、触发条件和财务影响。改完之后，那三个人的两天对账时间，降到了半天。
我想说的是，库存管理标准化的最大杠杆，往往不在工具，而在定义。工具负责执行定义，定义负责让工具产生价值。顺序反过来，投入会翻倍，效果会打折。
如果要给一份可直接用的收尾清单，我会留这八个问题：
这八个问题里，如果有三个以上答不上来，我的建议是先不要着急选型或换系统，把定义补齐再说。如果你的答案是"我们有系统，但没人能说清楚"，那正好说明问题不在系统里。
下一步可以这么做：挑一个你最近遇到的库存异常，从原始单据开始往上追，一直追到报表。追的过程中你会自然发现，缺口到底在状态定义、在事件记录、在责任边界，还是在报表口径。找到缺口，再决定要不要花钱，钱花在哪里，会踏实很多。
我们公司做亚马逊和独立站，国内仓、FBA、海外仓都有货。以前觉得库存就是一个数字，结果大促时经常出现“系统里有货但发不出去”，财务又说库存金额对不上。我一直搞不清是ERP不行，还是我们自己状态定义没做清楚。
至少要把在途、待检、可售、订单占用、不良、退货在途、待报废这几类分开，而且每一类都要有明确的“谁能改、什么时候自动流转”规则。判断方法不是看ERP有没有这些字段，而是拿三个真实场景跑一遍：采购在途货到仓前算不算可用库存；客户下单未付款时库存是否锁定、多久释放；退货入库后经过质检到变成可售要几步。
很多系统把在途和可用混在一个数字里，运营看总数、仓库看实物，两边永远对不上。建议口径是：可售库存等于实物可用减订单占用再减安全库存缓冲，在途单独列一行不参与可售计算，否则补货和防超卖都会失真。状态粒度不必追求几十种，但要保证每个状态都能回答三件事：这批货现在能不能卖、在哪、值多少钱。
我们同时运营亚马逊、eBay、TikTok Shop和独立站，最怕超卖。销售跟我说是实时同步，可大促时还是有两个平台同时卖出最后一件。我不知道该问厂商什么问题，也不清楚“实时”到底是几秒。
不要问是不是实时同步，要问四个可验证的点：同步是事件驱动还是定时轮询；单次同步的最小间隔是多少秒；API失败或被限流后有没有重试队列和告警；同步失败期间该SKU是否自动暂停售卖或降级为安全库存。
判断依据可以用一次大促的真实数据来算：把订单高峰期的平台库存与ERP库存做逐分钟比对，看最大偏差值和恢复时间。常见做法是保留1到3件的缓冲库存，但缓冲值应按SKU动销和平台特性分别配置，不能全局一个数。
还要确认是共享库存还是独立库存模式，多平台共享一个SKU池时占用逻辑必须先到先得且带锁，否则并发下单照样超卖。落地建议是选10个高动销SKU做两周压测，记录超卖率和同步延迟，再决定是否全量上线。
我们在深圳有国内仓，美国有FBA和第三方海外仓，货经常要在几个仓之间调拨，还有FBA移除、换标、重新入仓这些操作。每次盘点都对不上，运营看到的可售数量和仓库实际数量总差一截。我想知道ERP到底能不能把这些仓统一起来看。
多仓管理的核心不是看到一个总数，而是每一笔货的归属、状态和成本都能追溯到具体仓库和批次。要覆盖三件事：调拨单能表达头程在途这个中间态，也就是发出仓已扣减、目的仓未入库；FBA移除和换标能生成对应的库存变动单据，而不是手工调数；第三方海外仓能通过API或对账单做差异核对并留痕。
验收方法是挑一次真实的跨仓调拨，从创建调拨单到目的仓上架，看ERP里能不能查到每个节点的数量、时间和责任人。如果差异只能靠人工调整库存来抹平，说明系统缺少在途仓或虚拟仓的概念。
补货侧也要注意，不同仓的逻辑不一样：FBA要看平台仓容限制和入库时效，海外仓看头程时效和MOQ，国内仓看生产周期，所以补货建议必须按仓分别计算，用一个统一的安全库存去套一定会出问题。
读者评论
可售库存”三个口径不一致这个场景太真实了，我们公司也是运营、仓库、财务各算各的，每个月对账都要吵一轮，最后发现是定义问题不是执行问题。
库存准确率六成是规则问题这个判断很扎心。我们去年加了两个人专门盘点，差异率没降多少，现在回头看确实是状态流转没定义清楚。
实时同步不等于不会超卖，这句话应该打印出来贴在选型会议室。我们之前就是被‘实时’两个字忽悠了，多平台共享库存时缓冲机制才是关键。
先统一主数据和库存状态、再上财务模块这个顺序建议很有价值。我们就是先上了财务，结果成本算出来全是精确的错误，返工成本太高了。
跨境比国内多出那么多库存状态和费用类型，这个对比图很直观。以前总觉得是团队能力问题，其实是管理对象的维度本身就多了一截。