上个月我陪一个做家居收纳的卖家做补货复盘，他的公司在亚马逊美国站、Shopee 马来站和 TikTok Shop 印尼站同时卖货，美国用海外仓、东南亚用本地仓、国内还有两个备货仓。过去 12 个月，他们在美国站断货 11 次，其中 3 次断货超过两周，与此同时英国海外仓压了将近 4 个柜的滞销库存，占用资金约 180 万元。
他问我的第一个问题是：是不是该换个 ERP？我的回答是，换 ERP 解决不了这个问题，因为在你公司内部，"可售库存"这四个字到底指什么都没统一。运营看到的可售库存，是平台后台数字；仓管看到的可售库存，是仓库实际能拣的数；采购看到的可售库存，是加上在途之后能用多少。三张表放在一起，同一款 SKU 能差出 40% 以上。
这篇文章想聊的，就是跨境 ERP 采购补货这件事到底应该从哪里开始。我会先给结论，再讲为什么这两年这个问题突然变难，然后拆开最常见的五个误区，接着给出我自己在项目里用的判断逻辑和一张真实的改造案例，最后按卖家不同阶段给出行动建议和取舍。文中会以我自己用得比较多的"数跨境"（官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;
_plan=est&utm;_unit=gys）作为数据侧的一个具体样本，说明数据口径这件事应该落在什么地方。
先说结论，可能会让一些正准备采购系统的卖家不太舒服：采购补货的起点不是任何 ERP 里的"一键补货"按钮，而是五组能够被反复对齐的数据口径。这五组口径是：可售库存、在途与交期、销量速度、安全库存、补货约束。
为什么这么说？因为 ERP 本质上是一个记录和执行系统。它记录订单、库存、采购单、出入库流水，然后按你设定的规则去算、去提醒、去生成单据。规则是你给的，口径是你定的。如果口径本身是错的，ERP 只会把错误算得更快、更整齐、更有说服力。
我用过、也帮人评估过多套跨境 ERP。有一个规律很稳定：凡是"补货算不准"的抱怨，追到最后几乎都不是系统算错了，而是输入系统的数字本身就不一致。比如平台后台显示可售 320 件，海外仓实际可拣 280 件，另外 60 件是在途但货代还没给入仓预约号。这三组数字背后是三套口径，系统拿哪一套去算，结果都不一样。
所以我在做任何补货项目时，第一步从来不是打开 ERP 的补货模块，而是先把"库存"这个词拆成六个状态：平台可售、仓库可拣、已锁定未发、在途未到仓、到仓未上架、不可售（质检/损坏/退货待处理）。这六个状态分清楚之后，补货这件事才有讨论的基础。
把这五组口径拆开看，每一组都对应一个具体的业务问题，而不是一个系统功能：
这五个问题任何一个没答案，补货就只能靠感觉。而感觉在小规模时是有效的，因为老板一个人脑子里装得下所有 SKU；一旦 SKU 过千、平台过三个、仓库过两个，感觉就会失灵。
很多卖家在选型时会问"你们的智能补货算法准不准"。我的判断是，在 SKU 数超过 300 的跨境卖家里，补货准确率的上限通常由数据口径的一致性决定，而不是由预测算法的先进程度决定。口径统一但用简单移动平均，效果往往好过口径混乱但用机器学习。
原因很直接：算法是在修正残差，口径错误带来的是系统性偏差。系统性偏差不会因为模型复杂而消失，只会被模型学进去。
如果只是"库存算不准"，这个问题十年前就存在，不至于到今天还被反复讨论。真正让补货变难的，是 2023 年之后跨境行业的三个结构性变化：渠道碎片化、物流时效波动、以及平台模式对补货主体的重新划分。
过去的跨境卖家大多是单平台单站点，库存就是一个池子。现在一个中型卖家同时跑亚马逊、Shopee、TikTok Shop、Temu、独立站是很常见的组合，每个平台对库存的定义还不一样：亚马逊有可售、预留、FC Transfer 中；Shopee 有可售、锁定、调拨中；TikTok Shop 有可售与待发货。这些状态如果在系统里被压成"库存"两个字，补货必然出错。
我见过最典型的案例是，一款宠物饮水机在四个平台上同时售卖，运营各自按平台后台库存做补货，结果同一批货被两次计入可用库存，导致超卖 200 多单，最后只能从海外仓紧急调拨，单件物流成本增加了 3.7 美元。
2020 年之前，很多卖家把供应商交期和头程时效当成固定值：生产 15 天、头程 30 天、清关 5 天，加起来 50 天，写死进 Excel。现在这套算法已经很不靠谱。红海绕行、港口拥堵、旺季舱位紧张，都会让头程从 30 天变成 45 天甚至 60 天。
我的判断是，交期必须被当成一个分布而不是一个数字。至少要记录"最快到仓天数"和"最慢到仓天数"，并用最慢值或者 P90 值去算补货点，而不是用平均值。用平均值算补货点的卖家，遇到旺季就会集体断货。
半托管和全托管模式兴起之后，一部分补货决策权转移到了平台侧，但卖家并没有因此轻松。因为平台给到的备货建议通常只覆盖平台仓，不覆盖卖家自己的海外仓和国内仓，也不考虑卖家在多个平台之间的货权分配。结果是卖家要同时管理"平台建议"和"自己判断"两套逻辑。
我接触过的卖家里，有相当一部分在这一步出现新问题：按平台建议备货，结果其他渠道断货；按自己判断备货，又踩了平台的履约考核线。
我在做补货诊断时，通常会先看卖家的补货表是怎么算的。看多了会发现，出问题的动作高度重复。下面这五个误区，几乎每个"补货不准"的卖家都能对上两三个。
这是一个看起来很合理、实际很危险的做法。运营在平台后台看到可售 320 件，按日均 40 件估算还能卖 8 天，觉得还早，于是不着急下单。但他不知道的是，这批货的补货周期是 55 天，等货到手时已经断货 47 天了。
只看可售库存的卖家，本质上是在用"剩余天数"代替"补货提前期"做判断。这两个概念完全不同。正确做法是用可售库存加可靠在途，再除以销速，看这个覆盖天数是否小于补货提前期加安全天数。
这是我最常见到的错误。卖家在 11 月做了一次爆单，日均销量冲到 200 件，于是把 200 件写进补货公式，结果 12 月到 2 月日均只有 60 件，库存直接压死。
我的处理方式是把销速拆成三层：自然销速、促销增量和趋势项。日常补货只用自然销速加趋势项，促销增量单独按活动周期备货，并且活动结束后立即回收。这三层不分开，补货数字一定会被大促污染。
很多卖家在 ERP 里设了补货点，然后就再也不动了。但交期在变、销速在变、供应商在换，补货点必须跟着变。我一般建议至少每月重算一次，交期波动大的品类每两周一次。
这里有个容易忽略的点：补货点不是一次性参数，而是一个随季节和物流环境漂移的动态值。把它当成固定资产来管理，是补货失控的常见起点。
采购在填交期时，往往填的是"上次最快用了 18 天"。但上次是淡季、供应商产能空、船期正好赶上。旺季的真实交期可能是 35 天。
我在给卖家做交期评审时，会要求供应商交期至少记录三个值：承诺交期、最近三次实际交期、历史最差交期。补货计算用哪一档，取决于这个 SKU 的断货成本和毛利率，而不是统一用一个数。
这是上了 ERP 之后反而更容易犯的错误。系统算了建议补货 500 件，采购直接转单，结果忽略了这款产品下个月要换代，或者供应商下个月涨价 8%，或者平台要调整仓储限制。
我的原则是：系统建议只负责把 90% 的常规 SKU 变成可执行草稿，剩下 10% 的异常必须人工过一遍。这 10% 通常是新品、清库存品、大促品、换供应商的品，以及高单价低周转的品。
讲完误区，接下来是我自己在项目里用的推演顺序。这套逻辑不依赖某一家 ERP，也不依赖某个算法，它是一套可以手算、也可以系统实现的判断框架。顺序很重要，跳步就会出错。
这一步不涉及任何计算，只做定义。我会拉一张表，把每个仓库、每个平台的库存状态列出来，然后映射到六个标准状态上。做完之后，同一款 SKU 在任何人的报表里，可售库存都应该是同一个数。
这一步通常要花一到两周，是这个项目里最不性感但收益最高的部分。口径统一之后，很多"补货不准"的问题会自动消失一半，因为争议的根源被消除了。
销速我一般算三个窗口：近 7 天、近 14 天、近 30 天。日常补货用 14 天为主、30 天做趋势校验；波动大的品类用 7 天做修正。同时把促销天数从窗口里剔除，避免大促污染。
这里要强调一个细节：新品和历史款不能用同一套销速逻辑。新品没有历史数据，只能用同类目成熟款的爬坡曲线做类比；老款要额外考虑生命周期衰减。
交期我建议按供应商、按品类、按运输方式分别维护，每个组合记录承诺值、近期实际值和历史最差值。补货计算时，常规品用近期实际值的 P90，高毛利品可以用中位值，低毛利高库存成本的品要用最差值。
举个例子：某供应商承诺交期 20 天，近三次实际是 24、27、31 天，历史最差 45 天。那么常规补货我按 31 天算，旺季前按 45 天算。
安全库存最容易被误解成"套个公式就行"。我的看法是，安全库存本质上是一个商业决策，反映的是你愿意为断货风险付多少钱。公式只是把这个决策翻译成天数或件数。
判断依据至少有三条：断货的机会成本（排名下滑、广告浪费、客户流失）、资金成本（库存占用的钱）、以及产品特性（是否易过期、是否易贬值）。这三条不同，安全天数就该不同。全店用一个安全系数，是典型的偷懒做法。
补货量的核心公式并不复杂，可以写成这样一段伪代码：
目标覆盖天数 = 补货提前期(P90) + 安全天数
目标库存 = 日均销速(自然+趋势) * 目标覆盖天数
可用量 = 仓库可拣 + 可靠在途 + 平台可售 – 已锁定
建议补货量 = 目标库存 – 可用量
约束修正
建议补货量 = max(建议补货量, MOQ)
建议补货量 = ceil(建议补货量 / 装箱数) * 装箱数
建议补货量 = min(建议补货量, 供应商产能上限, 资金上限)
建议补货量 = 成本更低时的替代方案? 拆单 : 整单
这段逻辑很短，但每一步都对应一个真实的业务约束。很多 ERP 的补货模块能做到前三行，后三行的约束修正往往需要人工介入或者二次开发。这就是为什么我不建议把系统建议直接当采购单。
下面这个案例来自我参与过的一个真实项目，为了保护商业信息，部分数字做了区间处理。这家公司做户外用品，SKU 约 1200 个，在 6 个平台销售，使用 4 个仓库（美国海外仓、英国海外仓、义乌仓、深圳仓），年 GMV 在 3000 万到 5000 万元之间。
改造前，他们每周一上午由运营、采购、仓管三个人对表，运营出平台库存表，仓管出仓库库存表，采购出在途表，然后手工合并。一次完整的补货测算要花将近三天，中间还要反复确认口径。更麻烦的是，因为对表周期长，很多 SKU 在等待期间就已经断货了。
他们当时的断货率大约在 9% 左右，滞销库存占比约 23%，库存周转天数在 78 天。这三个数字放在一起，说明问题不在"备货多少"，而在"备对没备对"。
我们做的第一件事不是上 ERP，而是把这些分散的数据统一到一个可以做计算的地方。这里我用的是数跨境。它的定位不是交易型 ERP，不负责下单、发货、打单，它的价值在于把多个平台、多个店铺、多个仓库的数据汇成一张可自定义指标的数据集。
具体做法是：把亚马逊、Shopee、TikTok Shop 的订单与库存数据，通过接口或报表导入；把两个自有仓的库存表通过固定模板上传；把采购在途表单独作为一张维表维护。三张数据源在数跨境里按 SKU 加仓库做主键合并，形成一张"可用量事实表"。
这一步的价值在于，过去需要三个人对表三天的工作，变成了每天早上自动刷新一次的同一张表，所有角色看的是同一个数字。口径统一之后，运营和采购之间关于"到底还有多少货"的争论基本消失了。
数据统一之后，我在数跨境里搭了几层看板。第一层是库存健康度总览，按 SKU 分类展示可售天数、在途覆盖、滞销天数；第二层是补货建议清单，按前面讲的五步推演逻辑计算建议补货量和建议下单日；第三层是异常预警，把"可售天数小于交期"和"滞销天数大于 90 天"两类 SKU 分别标红。
这里我要强调一个判断：补货看板的核心价值不是告诉你该补多少，而是告诉你哪些 SKU 现在就必须做决定。建议数量可以人工调，但"哪些 SKU 进入了决策窗口"这件事必须由系统自动筛出来，因为人工筛一定会漏。
我们设置了三级预警，逻辑是按"可售天数 / 交期"这个比值来分：比值小于 0.8 为红色，立即处理；0.8 到 1.2 为黄色，本周内决定；大于 1.2 为绿色，正常监控。
红色预警由采购直接处理，黄色预警由运营确认是否需要参加促销调整销速，绿色只做周度复盘。这样做的结果是，采购的注意力被集中到了真正紧急的 15% 左右的 SKU 上，而不是平均分配到全部 1200 个 SKU。
改造运行六个月后，他们的一次完整补货测算时间从接近 72 小时降到约 4 小时；断货率从约 9% 降到 3.5% 左右；滞销库存占比从 23% 降到 11%；库存周转天数从 78 天降到 56 天。库存的绝对金额没有大幅下降，但结构明显改善了。
需要说明的是，这些改善并不全是数据平台的功劳，其中也包含他们同步调整了供应商结构和促销策略。数据统一解决的是"看不见"的问题，不能解决"看见之后不敢决策"的问题。这两件事要分开看。
上一节讲的是数据侧。当口径统一之后，接下来才是 ERP 承担的部分。我通常把完整的补货流程拆成五层，每一层解决不同的问题，也对应不同的失败模式。
这一层负责把平台订单、平台库存、仓库库存、在途、采购单、物流轨迹接进来。评估一个 ERP 是否适合做补货，第一个要看的就是它的数据接入粒度：是只接订单汇总，还是能接到 SKU 加仓库加批次的粒度。
粒度决定上限。如果系统只支持到 SKU 汇总层级，你就永远做不了分仓补货和调拨。
这一层要能配置补货点、覆盖天数、安全天数、供应商交期、MOQ、装箱数、分配置优先级。规则越细，系统建议越接近可用；规则越粗，人工干预越多。
我的经验是，规则配置要分品类而不是全店统一。家居和 3C 的安全天数不该一样，服装和电子的交期逻辑也不该一样。
这一层负责把规则跑出来的结果呈现出来，通常包括建议补货量、建议下单日、优先级排序。好的实现会同时给出"如果按建议下单，预计到仓日是哪天"。
如果系统只给一个数字不给日期，采购就无法判断这份建议是否可行。
这一层包括请购、询价、比价、下单、跟单。很多 ERP 在补货建议和采购单之间存在断点，需要人工重新录入，这个断点是最容易丢信息的地方。
我在选型时会专门测这一步：从补货建议到采购单，需要点几下、会不会丢字段、能不能带出上次成交价。
这一层包括入仓、质检、上架、异常处理，以及最重要的，实际到仓日回写。如果实际到仓日不回写到交期记录里，下个月的补货计算还是用旧数据。
补货系统的自我进化能力，取决于实际结果能不能回流成新的参数。这一层做不好，系统会越用越不准。
补货方法论不能一刀切。SKU 只有 50 个的卖家和 SKU 有 2000 个的卖家，起点完全不同。下面按四个典型阶段给出建议，每个阶段的重点不是"用不用系统"，而是"先解决哪个瓶颈"。
这个阶段不需要上复杂系统。用 Excel 或在线表格管住三件事就够了：每个 SKU 的日均销速、供应商实际交期、当前可用库存。补货公式用最简单的一版：可用天数是否小于交期加安全天数。
这个阶段最容易犯的错是过早采购功能繁多的 ERP，结果大量功能闲置，还增加了学习成本。SKU 少于 100 个时，管理效率的瓶颈通常在人，不在工具。
到这个阶段，最先出问题的不是补货计算，而是超卖。因为同一批货可能被多个平台同时算作可用。这个阶段的重点是把六个库存状态定义清楚，并且让所有人看同一张表。
建议做法是先把订单和库存数据集中到一个可以做计算的地方，把可用量事实表建起来，再考虑要不要上 ERP 的补货模块。顺序反了，ERP 会被当成口径错误的放大器。
这个阶段的核心问题从"补多少"变成了"补到哪里"。同样的总量，放在美国仓还是英国仓，结果完全不同。这时候需要引入分配逻辑，考虑各站点的销速、各仓的仓储成本、以及站点间的调拨时效。
调拨决策往往比采购决策更影响利润，因为它涉及库存的二次转运成本。很多卖家只优化采购，不优化调拨，结果库存结构始终不对。
旺季补货的关键不是算得多准，而是下单得多早。我的建议是旺季前把交期从 P90 换成历史最差值，把安全天数上浮 30% 到 50%，并且提前锁定供应商产能。
旺季最典型的失败模式是：数量算对了，但下单晚了，货到的时候活动已经结束。在旺季，时间维度的误差比数量维度的误差更致命。
讲完建议，必须讲取舍。因为在真实决策里，卖家面对的从来不是"哪个方案最好"，而是"我现在该花多少钱解决哪个问题"。我把常见方案分成三类，分别说清适用边界。
Excel 的优势是灵活、零成本、改起来快。劣势是多人协作容易出错、数据量大了会卡、没有权限控制、公式容易被误改。
我的判断是，Excel 能撑到大约 200 到 300 个 SKU、每天 300 单以内的规模，再往上就会频繁出错。不是 Excel 不行，而是维护它的人力成本开始超过工具成本。
轻量 ERP 通常强在订单处理、打单发货、基础库存管理，弱在数据口径的灵活定义和多源整合。它的优势是便宜、上手快。
如果你的主要痛点是订单处理效率，轻量 ERP 是合理的。但如果你的痛点是补货算不准，轻量 ERP 往往解决不了，因为它通常不允许你自定义库存状态和补货公式。
这套组合的逻辑是：数据平台负责统一口径、计算指标、生成判断；ERP 负责执行落地、记录流水、生成单据。前者回答"该不该补、补多少"，后者回答"怎么补、补完怎么记"。
这也是我在第五节案例里的做法。数跨境这类数据平台的价值在于可以按业务自定义指标和口径，不受 ERP 预设字段的限制；ERP 的价值在于把决定变成可追踪的单据和流程。两者不是替代关系，而是上下游关系。
这套方案的代价是需要有人能定义指标、维护数据源。如果团队里没有这样一个人，再好的工具也会被用成另一个 Excel。
如果你是采购决策者，下面这份清单可以直接拿去做评估。它不涉及具体报价，只解决"我该问什么、该验什么"的问题，避免被演示效果带偏。
免费版本通常限制最多的是店铺数、订单量和历史数据保留期，这三项恰好是补货计算最依赖的输入。所以评估免费版时，不要只看能不能用，要看能不能算出准确的补货建议。
第一类是实施与配置成本，包括字段映射、规则设置、历史数据导入。第二类是培训成本，尤其是让运营和采购改变原有习惯。第三类是数据迁移与并行期成本，新旧系统并行期间往往需要双份人工。第四类是错误成本，包括超卖赔付、错单、以及错误补货造成的滞销。
我的经验是，隐性成本通常是显性订阅成本的 1 到 3 倍，规模越大倍数越高。做预算时如果只算订阅费，落地阶段一定会超支。
不要只看演示，演示数据永远是干净的。我建议做三个动作：用你自己的真实数据跑一次补货计算，看结果是否可解释；让采购同事亲自从建议走到采购单，看要几步；以及在系统里制造一个异常场景，比如在途数量缺失，看系统如何提示。
这三个动作做完，大部分不合适的产品会被筛掉。
最后这部分是可以直接执行的。我把补货能力建设拆成三个时间尺度，每个尺度只做少量但关键的事。顺序不要打乱，因为后一步依赖前一步的产出。
这一步不需要任何系统，一天就能做完，但它能立刻暴露出一批即将断货的 SKU。
这个月最重要的一件事不是上工具，而是确定"谁对补货参数负责"。没有责任人的参数维护，三个月后一定烂掉。
做完这三步，你的补货就从"凭经验"变成了"有口径、有预警、有复盘"的循环。系统在这个过程中是配角，逻辑才是主角。
回到最开始那个问题：跨境 ERP 采购补货从哪里开始？我的答案是，从你愿意把"库存"这个词定义清楚那一刻开始。ERP 会记录你的决定，数据平台会帮你看清决定依据，但决定本身仍然由人做。在所有工具之前，先把五本账摆平，这是唯一不能跳过的一步。
如果你现在就想动手，最实际的起点是今天下班前做一件事：把可售库存、仓库可拣、在途未到仓这三个数字，对同一款主销 SKU 手动核对一遍。三个数字之间差多少，那个差额就是你补货失准的全部原因所在。
我去年同时做亚马逊和独立站，旺季前老板让我“把补货系统搞起来”，我第一反应就是去对比各家ERP的智能补货功能。结果开通之后系统给的补货建议跟我手工拍的数量差了快一倍，我反而不敢照着下单。后来复盘才发现，问题根本不在工具，而在我连“这个SKU一天到底卖多少”这个数都说不清楚。
先别碰工具，先把三本账的口径定死：销量口径、在途口径、交期口径。销量口径建议以近30天为主、近7天做修正，可以给30天0.7、7天0.3的权重，但必须剔除大促当天和断货日的失真，断货日要按“有货天数的日均”还原，否则你会把缺货造成的低销量误判成需求下降，越不敢补越缺货。
在途口径拆成三段：已下单未发货、已发货未到仓、已到仓未上架，只有能给出预计到仓日的那部分才进补货模型，剩下的只做参考。交期口径别用供应商承诺的最快值，取近半年实际到仓天数的P85，把清关、尾程、海外仓上架一起算进去。
口径定完再谈工具：拿TOP50 SKU手工跑两周补货表，你会发现大部分问题出在数据，不出在按钮。
我做家居类目的时候，安全库存是靠“感觉上一个月的量”拍的，旺季前备了三个月，结果一个改款直接变成滞销，仓储费烧了一整个季度。后来又矫枉过正，只备两周，海运一延误就断货掉排名。我一直想知道，到底有没有一个能跟着销量波动自动调整的口径，而不是每年靠赌。
用统计口径而不是拍脑袋：安全库存 SS = Z × σ_d × √L，补货点 = 日销 × 交期 + SS。其中σ_d是你日销量的标准差，L是交期天数，Z是服务水平系数，95%对应1.65，90%对应1.28。
举个例子：某SKU日销20件、日销标准差6件、交期45天，简化算法 SS ≈ 1.65×6×6.7 ≈ 66件，补货点 = 20×45 + 66 = 966件。
如果你还算上交期波动（比如交期标准差7天），用 σ_LTD = √(L×σ_d² + 日销²×σ_L²)，得到约146件，SS = 1.65×146 ≈ 240件，补货点抬到1140件。两个数差出来的174件，就是“海运晚一周”的保险费。
有两点必须提醒：新品没有历史σ，先按同品类老品代入或把Z降到1.28，等跑够一个完整周期再换成真实值；断货和清库存的SKU不要算进这个模型。
我同时在两个平台加一个独立站卖同一个SKU，后台看到的“可售库存”每个平台都不一样，有次大促两个平台同时出单，最后超卖了三十多件，赔了差价还被平台记了违规。从那以后我每次看到ERP首页那一排库存数字，都不知道哪一个才是真正能用来判断补货的。
只认一个定义：可用库存 = 实物库存 − 已售未发（锁定） − 活动或赠品预留 − 安全库存缓冲，在途库存单独一列、绝对不并进可用。三个最常见的坑：第一，把某个平台后台的“可售”当成真实库存，它不包含其他平台已经卖掉的量；
第二，同步频率太低，部分低价或免费版本的同步间隔在30分钟以上，签约前一定要问清是“按分钟同步”还是“按小时同步”，能走API或webhook就别用定时拉取；第三，大促期所有平台共享一个池子，应该按历史销量占比分配缓冲，比如A平台70%、B平台30%，做活动的平台单独锁量、不参与共享。
给你一个判断标准：如果过去一个月超卖或被处罚超过2次，先别急着加SKU，把同步频率和预留逻辑补上，收益远比多上几个新品高。
我们团队从两个人做到八个人，最开始全靠一张Excel表撑着，后来店铺越开越多，每天光同步库存和导订单就要一个多小时。我也试过几个免费版ERP，但总担心哪天突然被卡住或者数据导不出来，一直纠结到底该不该花钱换，什么时候换才不算早。
看三个触发信号，满足两个就该上：SKU超过200或平台数达到3个及以上；每天花在跨平台改库存、导订单上的时间超过30分钟；过去三个月因库存不同步导致的超卖或断货达到2次以上。
判断“免费版够不够用”要盯四个边界，而不是看价格：店铺数和订单量上限、采购与在途库存模块是否包含在免费范围内、同步频率、数据导出和API权限。隐性成本同样要算进去，包括字段与流程配置、历史数据迁移、错单和超卖赔付，这几项通常比订阅费更贵，一旦要换系统，迁移成本还会再付一次。
相对稳妥的过渡路径是：单平台、SKU少于100、没有海外仓调拨需求的阶段，用Excel完全撑得住；一旦需要按供应商交期和海外仓库存算补货点，或者出现多仓调拨，就说明Excel的维护成本已经超过工具成本，这时候再上，钱花得才值。
读者评论
文章把补货问题归到数据口径而不是算法，这点很真实。多平台卖家常见的痛点就是平台后台、仓库可拣和运营手工表各说各话，先统一库存六状态确实比急着换ERP更有效。
从ERP实施角度看，系统只能执行规则，不能替企业定义业务。口径没统一，换系统也只是把错误算得更快。关键还是先把在途交期、补货点更新和异常校准机制梳理清楚。
采购和供应链视角很认同交期不能按最好情况算。旺季头程从30天拉到50天很常见，用平均值算补货点必然断货，记录承诺、实际、最差交期并按品类设置安全库存更稳妥。
补货准确率上限由数据口径决定这个判断有一定前提，但对多数多平台卖家成立。先做基础数据治理，再谈智能补货；系统建议只处理常规SKU，剩下异常必须人工过一遍，否则容易积压。