去年十一月，一位做家居类目的跨境卖家把三张表摊在我面前：ERP 里的库存明细、平台后台的可用余额、财务做的现金流预测。三张表单独看都对，拼在一起就是不对，ERP 说在库库存成本 680 万，平台说可提现余额 41 万，财务说下个月要付出 190 万采购款。他问我一句话：货明明在，钱到底去哪了？
这个问题我被问过至少二十次。它看起来是财务问题，本质上是口径问题：大多数卖家嘴里的"库存"，指的是仓库里的数量；而真正决定你能不能活下去的"库存"，指的是被货物占用的那笔现金，以及这笔现金会在什么时间点、以什么比例回到你的账户。
这篇文章不列 ERP 的功能模块。我按自己给卖家做资金复盘时的实际顺序来讲：先把钱被卡住的四个环节拆开，再定一套能同时衡量库存和回款的口径，然后落到具体动作、系统承接和阶段化落地顺序，最后讲清楚不同情况下必须做的取舍。
文中出现的金额、天数、比例，凡是标注"示例"的，都是我用来说明计算逻辑的模拟数据，不是行业统计；凡是涉及平台规则的地方，我只给查询路径不给死数字，因为这类规则近年调整频繁，写死就是误导。
跨境电商的库存问题，本质是回款问题，只是它发生在了更早的时间点。你为一批货付出去的钱，会在"在途、在库、待结算、预留"四个环节里被分段占用，每一段的时长和金额都不一样，而你能做的所有优化，本质上都是在缩短某一段的时长、或者降低某一段的金额。
所以"库存周转天数"这个指标单独看是危险的。它衡量的是货走得多快，但完全不衡量钱回来得多快。一个卖家可以把库存周转压到 45 天，同时现金转换周期还是 100 天以上，因为他在采购端被供应商要求预付、在平台端又被结算周期和预留拖住。货转得快，不等于钱回得快。
下面这四个环节，是我做复盘时一定会逐项核对的。它们的分界线不是仓库位置，而是"这笔钱现在能不能被调用"。
| 环节 | 典型持续时长（示例） | 钱的状态 | 能否被其他环节调用 |
|---|---|---|---|
| 在途与头程 | 25，45 天 | 已出账，货未上架 | 完全不能 |
| 在库（可售/不可售/待处理） | 15，90 天 | 已出账，货可卖但未卖出 | 不能，且持续产生仓储成本 |
| 待结算余额 | 7，21 天 | 已售出，平台未放款 | 不能 |
| 平台预留与冻结 | 7，30 天不等 | 账面可见，不可提现 | 完全不能 |
请注意最后两行的区别。很多卖家把"平台后台显示的余额"当成自己的钱，实际上那个数字里通常包含一部分处于预留或冻结状态、暂时不可提现的金额。具体预留规则和释放节奏，各平台差异很大，且和店铺绩效、账户状态挂钩，正确做法是到平台官方帮助中心搜索"结算"或"付款"相关说明，以当期官方口径为准，不要把别人文章里的天数当成自己的。
我给卖家做诊断时，会用三个问题来判断他的库存管理到底有没有在管钱：
三个问题里有一个答不上来，你的 ERP 大概只是当了一个更贵的 Excel 在用。
我先给你一条完整的资金链路。假设一批货的采购付款是 42 万元，走海运头程，上架后 40 天卖完，然后进入平台结算周期。中间会发生的扣减名目大致如下，这不是某一家的真实账，是我用来解释口径的示例。
这张图里最值得注意的不是损耗率 37%，而是时间跨度。42 万出去，26.5 万回来，中间隔了大约四个月。如果你的采购是每月滚动下单的，就意味着你同时在为四批货垫资，这才是压死现金流的真正原因。
把上一段的金额摊到时间轴上，你会看到更清楚的东西：在途阶段，钱是"沉没"的，既不能卖也不能提；在库阶段，钱是"可救"的，可以通过降价、调拨、清货回收；待结算阶段，钱是"确定"的，只是时间问题；预留阶段，钱是"名义上属于你"的。
这是我踩过最深的坑。早年我看库存只看"在库数量"和"库存金额"，直到有一次盘库才发现，一批货里有近三成是客户退货待处理品和瑕疵品，它们躺在仓库里照样计费，却几乎不可能按原价卖出。
库龄越长，与仓储相关的费用通常越高，部分平台还会对长期滞销库存收取附加费用，具体的库龄门槛和计费阶梯请务必核对平台官方当期的费率说明页面，不同站点差异很大。但从资金角度看，三者的成本结构差异是确定的：
单店卖家的问题还只是"看不清"。多平台多店之后，问题会变成两种损失同时发生：热销品在 A 平台断货、在 B 平台压仓；同一个 SKU 在三家店铺里各有一份库存，谁也不敢调，因为调了另一家就断货。
我服务过的一个卖家，在四个平台开了十一个店铺，SKU 约 900 个。上线统一库存视图之前，他们的断货 SKU 占比长期在 10% 以上，同时滞销库存占比超过 20%。这两个数字听起来矛盾，实际完全自洽：该补的没补、不该补的压了一堆，是同一个根因的两个结果，补货决策没有数据支撑。
仓库管理关心的是数量对不对、位置对不对、能不能找到。库存的资金管理关心的是这笔钱压了多久、还有没有回收可能、机会成本是多少。
很多卖家的 ERP 上线验收标准是"库存准确率达到 99%"。这个目标本身没错，但它只是基础。我见过库存准确率 99.5% 却现金流断裂的卖家，他每一件货都数得很清楚，只是那 99.5% 的准确库存里有四成是滞销品。
库存准确率解决的是"看得见"，不解决"划不划算"。
"这个月做了 300 万销售额，毛利 22%"，这句话在跨境语境下几乎不构成有效信息，因为你不知道这 300 万里有多少已经变成可提现现金，有多少还在待结算，有多少会被退款吃掉。
我给客户做月度复盘时，要求同时看四个数字：本月成交额、本月可提现回款、本月资金净流出、月末资金占用总额。四个数字放在一起，才能判断这个月的增长是"健康的增长"还是"用现金换来的增长"。
这是最常见也最贵的一个误区。ERP 是一个执行工具，它能按你定义的口径算数，但它不会替你定义什么叫"动销"、什么叫"呆滞"、库存成本用哪种计价方式、退款算在哪个月。
我见过的一个真实场景：运营认为"90 天没出单算滞销"，财务认为"180 天没出单才算"，采购按自己的经验用"60 天"。三套口径并存，导致每次开会都在吵数据，而不是在解决问题。系统只能执行口径，口径必须由人来定。
大多数卖家的补货逻辑是：看过去 30 天日均销量 × 预计销售天数 × 安全系数 = 补货量。这个公式本身没错，但它漏掉了最重要的一项，这批货卖完后，钱什么时候能回来。
正确顺序应该是：先算出这笔货的回款预计到账时间，再反推你能承受的采
购金额和下单时点。举个例子，如果你的资金转换周期是 95 天，那么今天下单的这批货，要到 95 天后才真正把钱还给你。你在同一天能承受多少笔这样的采购，是由你的可用现金除以单笔占用决定的，而不是由销量预测决定的。
销量预测决定的是"要不要补"，回款节奏决定的是"能补多少"。
平台结算单和 ERP 订单金额天然对不上，这是结构性的。佣金、物流仓储费、广告费、退款、促销补贴、汇兑差异、平台赔付，每一项都会造成差额。如果运营不参与对账，后果是：财务只能看到总额差异，无法定位到具体 SKU 或具体费用类型，最终差额被当成"损耗"月份月份吞掉。
我对客户的要求是：差额超过一定金额或比例时，必须有业务侧的解释，而不是财务侧的调账。常见的差额类型和业务归因我整理成了下面这张对照表。
| 差额类型 | 常见业务原因 | 谁应该解释 |
|---|---|---|
| 订单金额 vs 结算金额 | 佣金比例、促销折扣分摊、平台代扣 | 运营（确认活动规则是否与预期一致） |
| 物流仓储费差额 | 尺寸重量重测、超期仓储、退货处理费 | 供应链（核对发货参数与计费标准） |
| 退款与拒付 | 产品质量、描述不符、物流延误 | 运营 + 品控（归因到具体 SKU） |
| 广告费分摊 | 跨店铺共用广告账户、归因窗口差异 | 投放负责人 |
| 汇兑差异 | 结算币种与记账本位币不同、汇率取值时点不同 | 财务（统一汇率取值口径） |
| 预留与释放 | 账户绩效波动导致的临时冻结 | 运营（关注账户健康指标） |
前面提过，库存准确率是基础，不是目标。真正需要被考核的是一组组合指标：动销率、售罄率、呆滞占比、库存周转天数、现金转换周期。其中任何一个单独拿出来都可以被"优化"到很好看，但组合起来才是真实的。
比如把库存周转天数压到很低，只要疯狂降价清货就能做到，但你的毛利会被吃掉；把呆滞占比压到很低，只要不计成本销毁就行，但你会损失残值回收。这些都不是真优化。
下面四个定义，是我建议在系统上线前就先书面定下来、并由运营和财务共同签字确认的。不定下来就上系统，后面的报表一定会打架。
这里我要给一个反直觉的建议：口径不必一开始就追求最精细，但必须全公司统一。一个统一的粗糙口径，比三套各自精确的口径有用得多。
回款侧的核心不是"到账了多少钱"，而是三个时间节点的对齐：订单成交时间、平台放款时间、银行入账时间。
很多卖家只盯第三个节点，因为那是唯一出现在银行流水里的。但真正决定你资金压力的是第一个到第二个之间的间隔，那段时间钱在平台手里，你既不能提也不能用。
标准的现金转换周期公式是：存货周转天数 + 应收账款周转天数 − 应付账款周转天数。放到跨境多平台场景下，它需要做三处变形。
第一处，应收账款的对手方不是客户，是平台。你的"应收"实际上是待结算余额加预留，回款周期取决于平台规则而不是你的催收能力。
第二处，应付账款对中国卖家常常是负的，很多供应商要求预付或货到付款，你不但没有账期，还在为供应商融资。
第三处，广告费和头程费是前置支出的，它们会提前扩大资金占用峰值。
把这三处补进去，我常用的简化口径是这样的：
跨境现金转换周期（简化口径）
= 头程在途天数
+ 在库天数（按动销库存加权）
+ 平台结算周期天数
+ 平台预留释放天数
+ 收款机构结汇到账天数
− 供应商账期天数
其中：
头程在途天数 = 从采购付款日到首次可售日
在库天数 = 期间平均库存成本 ÷ 期间日均销售成本
平台结算周期 = 订单成交日到转为可提现日
预留释放天数 = 取近 90 天实际释放天数的中位数（不要取平均值）
结汇到账天数 = 发起提现日到银行入账日
注意最后一行我用的是中位数而不是平均值。实际数据里，个别异常订单的释放时间会很长，用平均值会把整体天数拉偏，中位数更能反映你正常经营下的真实节奏。
我必须说清楚边界，否则这套方法会被误用。
如果你做的是纯铺货型、单 SKU 生命周期只有两三个月、毛利极低的模式，建这套精细口径的投入产出比是负的，你更适合用"月度资金占用总额 + 月度回款总额"两个粗指标来控制节奏。
如果你的核心痛点是断货而不是压货，那么优先级应该放在需求预测和补货触发规则上，而不是资金口径上，口径再准也不解决缺货问题。
如果你的团队只有三五个
人，没人能专职做数据，那么强行上多维度口径只会导致数据没人维护、最后全部失真。这时候应该先做"最少必要口径"：库存周转天数 + 回款到账金额，两个数字先跑起来。
这个卖家就是我开头提到的那位，主营家居软装，在做四个平台、七个店铺，SKU 约 640 个，年 GMV 约 4000 万。他当时的状态是：库存成本约 680 万，平台可提现余额 41 万，下月应付采购款 190 万。
我们先把三张表拉到一起对了三天，发现问题集中在三处：一是库存里没有区分可售、不可售和滞销，全按成本价混在一起算；二是平台待结算和预留金额从未进入过资金预测；三是补货决策完全依赖运营个人经验，没有任何数据记录。
我们没有先动系统，而是先用两周时间把现有库存按四个状态打标：可售动销、可售滞销、不可售、在途。打标规则就是前面说的那套口径，由运营和财务共同确认。
打标完成之后的结果让所有人都吃了一惊：640 个 SKU 里，真正处于健康动销状态的库存成本只有约 380 万，占 56%；滞销库存约 156 万，占 23%；不可售（退货待处理加瑕疵）约 68 万，占 10%；在途约 76 万，占 11%。
换句话说，他引以为傲的"680 万库存资产"里，有三分之一以上是低效甚至无效占用。
接下来我们做了一件很朴素的事：把每个 SKU 的回款预计到账时间算出来，然后画在一条时间轴上。这个动作直接改变了他们的补货会议，以前会上讨论的是"这个品要不要加量"，后来变成"下个月 15 号前我有多少可提现现金，能支撑几笔下单"。
具体规则我们定得很简单：单月新采购金额不得超过未来 60 天预计可提现回款总额的 70%。剩下 30% 用于应对滞销清理、突发补货和费用波动。这条规则执行下来，他们在第二个月就主动砍掉了两笔原计划的大额备货。
对账频率的改变带来的收益，是我在这次项目里最意外的发现。原本他们是每月做一次结算单核对，差异发现时已经过去 30 天，很多解释不了了之。改成按周核对后，差异能追溯到具体订单和具体费用类型。
三个月下来，他们挽回了大约 12 万的差异金额，不是靠谈判，而是靠及时发现计费异常并向平台提出申诉。
下面这组数字是这个项目的实际观察结果，样本只有一个卖家，不能推广成行业规律，但可以说明这套方法的量级。
项目进入第三个月，我们开始考虑系统化的问题。在此之前，他们用的是"ERP + 多平台后台 + 财务 Excel"三套东西手工拼接，每次做月度复盘都要有人专门导数据、拼表格。
我们评估了几个方向，最后选择用数跨境来承接这条链路里最耗人力的四件事。需要说明的是，这不是唯一选择，我下面也会讲什么时候不该选它。
第一件事是多平台多店铺的库存归集。把七个店铺的库存拉到同一个视图里，按 SKU 维度合并展示在途、在库、待结算的状态，这是解决"看不见"的第一步。
第二件事是库存分层与周转指标的自动计算。前面我们手工打标花了两周，系统化之后这套分层可以按固定口径自动刷新，滞销 SKU 会自己浮出来，不需要每个月人工筛一遍。
第三件事是平台结算单与订单的对账核销。这是跨境场景下最刚需的一项，佣金、物流费、广告费、退款、补贴都会造成差额，手工核对到 SKU 级别几乎不可能可持续。
第四件事是资金预测与缺口预警。把待结算、预留、预计回款、应付采购放在同一条时间轴上，输出未来 60 天的资金缺口预警，把"几个月后可能缺钱"提前变成可量化的信号。
我必须说清楚边界，否则这就变成软文了。
第一，口径定义它替不了你。动销、呆滞、库存成本计价方式，这些必须由你和财务先定，系统只能执行。我们花在定口径上的时间，比花在配置系统上的时间还多。
第二，滞销库存的处置决策它替不了你。系统能告诉你哪些 SKU 是滞销的，但要不要降价、降多少、要不要直接销毁回收残值，这需要结合品类生命周期、品牌定位和清货渠道来定。
第三，供应商账期谈判它替不了你。跨境卖家在应付端常常是负账期，这是资金转换周期里最大的一块可优化空间，但它是一个商务谈判问题，不是系统问题。
这个阶段不要上复杂系统，你的问题通常不是数据不够，而是数据没看。建议按下面的顺序做，一个月内可以全部完成：
如果只能做一件事，先做第一件。库存不分层，后面所有数字都是错的。
这个阶段的核心矛盾从"看不清"变成"对不齐"。你的重点应该放在统一 SKU 主数据和库存口径上，而不是急着上更多功能。
如果只能做一件事，先做第一件。SKU 不统一，你永远拼不出一张完整的多平台库存表。
到了这个体量，人工处理多仓调拨的组合复杂度已经不可行了。你的重点会转向三件事：调拨规则、回款预测模型、多币种核算。
这个阶段，像数跨境这类把库存、平台结算、资金预测打通的工具，价值才开始真正显现。它解决的不是"有没有功能"的问题，而是"人工已经算不动了"的问题。
这类卖家的资金结构很不一样：你在生产端有账期或预售款，在成品端有更长的生产周期，回款链路会更长但中间可能有定金收入可以缓冲。
核心建议是：把生产周期当成头程在途的一部分纳入现金转换周期，同时把客户定金作为资金来源项单独列示。不要用"已收定金"去抵扣采购支出，因为它对应的是未来的履约义务，不是可用现金。
口径越精细，能解释的问题越多，但维护成本也越高。我的经验分界线是：当某个口径维度每个月的维护成本超过它带来的决策价值时，就该砍掉。
比如按 SKU 维度算回款周期，在 SKU 少于 300 个时可行，超过 800 个之后维护成本会急剧上升，这时候按品类或用"SKU 分层抽样"更实际。
这个问题我被问得最多。我的判断标准不是公司规模，而是这件事是不是你的核心竞争力。
| 维度 | 适合自建 | 适合采购 SaaS |
|---|---|---|
| 业务独特性 | 业务模式高度独特，市面产品无法覆盖 | 业务模式属于行业通用形态 |
| 团队能力 | 有稳定的数据或研发团队能做长期维护 | 没有专职技术团队，或技术人员流动大 |
| 迭代速度要求 | 需要按自己的节奏快速调整 | 需要跟随平台规则变化快速适配 |
| 成本结构 | 能承受前期投入和长期维护成本 | 希望用订阅制把成本摊平 |
| 数据敏感度 | 数据合规要求极高，必须本地化 | 核心是业务数据，不涉及强合规约束 |
以跨境库存与回款这个场景来说，我的判断是倾向于采购：平台规则变化频繁，自建团队很难持续跟进各家平台的接口和结算规则变化。但如果你的核心壁垒就在供应链金融或资金调度上，那另说。
这是一个纯粹的现金流承受力问题，不是判断问题。判断标准很简单：算出你的现金转换周期，乘以你的月均采购金额，看看这个数字是不是超过了你的可动用资金。
如果超过了，任何激进补货都是危险的，无论你的销量预测多乐观。
如果没超过，并且你还有 20% 以上的安全边际，可以适度激进，因为断货的机会成本往往比轻微压货更高。但这个"20%"必须是你自己算出来的，不是抄别人的。
多平台的本质是用管理复杂度的上升，换取流量和风险的分散。它的隐性成本常常被低估：库存归集、对账、多币种、多套结算规则，每一项都会消耗管理带宽。
我的建议是：在库存口径和对账流程跑顺之前，不要新增平台。带着混乱去扩张，只会把混乱复制一份。等你已经能做到每周出一张完整的多平台库存与回款表，再扩张才是有杠杆的扩张。
我做过这么多复盘，最大的体会是：把库存和回款分开管，是跨境卖家最普遍也最贵的结构性错误。库存是回款的上游，回款是库存的下游，它们之间隔着四个可以被量化的环节。你只要不把它们放在同一套口径里，就永远在救火。
而一旦放进去，很多原本看起来无解的问题会突然变得清晰，比如"销售额涨了但现金更紧"，答案往往就藏在待结算余额和滞销占比这两个数字的组合里。
我见过太多卖家花了几十万上系统，最终还是在用 Excel 做决策，因为系统里的口径和业务现实对不上。也见过用最简单工具、但口径全公司统一的卖家，把资金周转做得比同行精细得多。
系统解决的是效率和数据量的问题，口径解决的是方向问题。方向错了，效率越高越危险。
如果你读完觉得有道理但不知道从哪下手，我建议就做下面这三件，不需要任何工具，今天就能动：
这三件事做完，你已经比大多数同行更接近真实的资金状况了。至于要不要上系统、上哪一类系统，等你把这三件事跑顺之后，答案会自己浮出来，因为那时候你会清楚地知道，自己卡在哪一段、缺的是哪一块能力，而不是被一堆功能清单牵着走。
库存管理的终点从来不是仓库里整整齐齐的货架，而是账户里可以随时调用的现金。这句话我用了很多年才真正理解，希望你能比我早一点。
我自己做跨境三年多，一直有个别扭的地方，库存这块运营盯着，回款那块财务盯着，两边报表各说各话。上个月盘账时发现账上还挂着一大笔待结算款，而仓库里那批货又压了快两个月，我就想知道这两件事能不能用一个数说出来，而不是每次开会各拿各的表。
能，用现金转换周期（CCC）的简化版：从采购付款到资金实际到账的平均天数。拆成四段相加，头程在途天数（付款日到入仓可售日）、在库天数（入仓到出库）、在售到结算天数（买家付款到平台生成结算单）、结算到账天数（结算单到收款账户可提现）。四段相加就是你的资金占用天数。
判断依据是这个数和账期承受能力的对比：如果供应商给你 30 天账期，而你的占用天数是 90 天，缺口是结构性存在的，靠卖得更多只会把缺口放大。计算时有三个容易踩的坑：在库天数用期末库存金额除以日均出库成本，别用件数，单价差异大的类目里件数会严重失真；
在库天数要按每个 SKU 的库存金额加权，不能用算术平均，否则平均值会被滞销品拉高、掩盖爆款的真实占用；头部 20% 的 SKU 建议单独再算一遍。频率上每月一次足够，每周只看在途和待结算两段的变动即可。
我一开始以为是对账没做好，换过系统，结果还是差。后来才发现差额里有佣金、物流仓储费、广告费、退款、促销补贴一大堆科目混在结算单里，根本不是一个数能对上的。我现在最想知道的是，这个差额到底该不该追平到零。
不该追到零，应该追到可解释。做法是把差额拆成固定几类科目：平台佣金、物流与仓储费、广告费、退款与退货、促销折扣与补贴、汇兑差、预留金变动。每一类在结算单里都有对应条目，逐条挂到订单或费用单上，最后剩下的未解释差额才是真正要查的东西。
判断依据是未解释差额占结算总额的比例，我给的经验阈值是千分之一量级，超过 1% 基本说明口径漏了科目，最常见的两个漏项是跨期结算（本月结算单里含上月订单）和部分退款，你可以用自己过去三个月的历史数据校准这个阈值，不用照搬。
执行顺序上先做月度总额对平，公式是结算单总额等于订单收入减各项费用减预留金变动，平了再往下钻订单级。订单级全量对账在多平台多店铺场景下成本极高、性价比很低，按月抽头部 SKU 加异常订单核对就够了。
我们一直用销量预测做补货，结果旺季压了一批、淡季又断货。财务提醒我账上现金只够撑两个月，我才意识到补货其实是在花未来的钱。但真到下单那一刻，我又不知道该怎么把回款这个变量掺进决策里。
两个都要用，但顺序是先定现金上限，再用销量预测做分配。第一步算可动用现金：当前可用余额，加上未来 60 天可到账的结算款，减掉未来 60 天固定支出（广告、仓储、物流、工资），这才是备货预算的硬上限。
第二步才轮到分配，按 SKU 的库存周转天数和毛利率排序，优先保障周转天数低于目标值、毛利率高的 SKU。判断依据可以用一个很简单的比值：备货金额除以该 SKU 预计 60 天的回款金额（已扣佣金和各项费用），大于 1 就说明这批货占用的钱要跨过它自己的回款周期，必须谨慎。
举个例子（假设数据）：某 SKU 成本 30 元，备 2000 件占用 6 万，预计 60 天卖 1500 件、扣费后回款 4.5 万，比值 1.33，那备货量应该砍到 1000 件左右。
不适用的情况也要说清楚：有明显季节性、且采购提前期长的类目，硬砍备货会直接错过销售窗口，这时正确的做法是拆成两到三批下单，而不是一次性压量或一次性砍量。
我们同时开着几个平台、十几个店，还有一个海外仓，每天的库存报表看得我头大。试过直接上系统，结果发现系统里跑出来的数还是错的。我现在特别想知道，在花钱之前，我到底该先动手做哪件事。
先做看得见，别急着做调得动，顺序是三步。第一步统一 SKU 口径，把同一件实物在不同平台、不同店铺的编码映射到一个主 SKU，映射表维护在表格里也完全可以，不必等系统。
第二步给库存分状态，至少要分出可售、在途、待处理（质检、退货、残次）三类，因为只有可售那部分才对应未来的回款，混在一起看就没有决策价值。第三步才是跨仓分配和调拨规则。
判断依据很直白：如果你现在没法在十分钟内回答出某个 SKU 的全渠道可售库存多少、在途多少、压了多久，那前面的基础就没打好，这时候上任何系统都只是把混乱电子化。还有一句要提醒，系统只能执行你已经定义好的口径，口径没定义清楚时上系统，结果往往是两套错误口径并存，对账时更痛苦。
可落地的节奏是：第 1 周拉齐 SKU 映射，第 2 周统一库存状态定义，第 3 周做一次全渠道盘点对平，第 4 周才开始设定补货和调拨参数，一个月内可以完成，不需要额外采购任何工具。
读者评论
把库存问题还原成回款问题，这个切入点比讲ERP功能有用。四个环节里最容易忽略的是待结算到预留那段，钱看着在账上其实提不出来。不过文中金额全是示例，中小卖家要自己套的话得先把本店实际的结算和预留天数查清楚，否则算出来的资金缺口会失真。
库存分状态核算成本这部分很实用，滞销和动销差四倍这个结论值得记。我自己的经验是退货待处理品一定要在系统里单独打标并设处理时限，不然趴三个月都没人管。另外多平台多店确实是指数级放大问题，统一库存视图之前先统一口径，顺序反了会白折腾。
作者说ERP不能替你定义口径，这点我认同但也想提醒一句：口径定下来之后还得有人维护，否则半年后运营和财务又会各说各话。三个判断题里第二题最狠，能不能算出钱什么时候回来，大多数团队其实答不上来，回款预测基本靠感觉，这个得靠系统按账期和预留规则自动算。